# What does production-ready mean? A checklist

Source: https://www.plutonapps.com/resources/what-does-production-ready-mean

Published 2026-09-30, updated 2026-10-24, sources checked 2026-10-24. By Milad Zarghani (https://www.plutonapps.com/authors/milad-zarghani).

**Production-ready:** Production-ready describes software that is safe to put in front of real users because access is enforced, changes are tested, releases can be rolled back, failures raise alerts and data can be restored. It is a checkable state of the system, not a judgment about how finished the app looks.

Also known as: Production-grade, Launch-ready.

Everyone says it; few define it. Here it is as a list you can check, not a feeling.

## What must a production-ready app handle when nobody is watching?

A prototype only has to work when you are watching. A production system has to keep working when nobody is: at 3am, under a traffic spike, when a payment provider retries a webhook, when a user tries something the screens never offered. Production-ready is the list of things that make that true.

## Which checks make an app production-ready?

Six areas cover it: access, secrets, testing, releases, running and recovery. Each one is a property of the system that an engineer can demonstrate, not a matter of taste. The table puts each area next to what it means in practice, so you can tick them off one by one.

| Area | Production-ready means |
| --- | --- |
| Access | Rules enforced by the database and the server, not only hidden in the interface |
| Secrets | Keys kept on the server, rotated, never in the browser |
| Testing | Automated tests run on every change before it ships |
| Releases | A staging environment, and a way to roll back |
| Running | Errors and slowdowns are noticed and someone is alerted |
| Recovery | Backups exist and a restore has been tried |

Each line is something an engineer can show you, which is the point: if nobody can show it, it is not done.

## Where do production-ready standards come from?

There is no single official standard, but two public references cover most of the list. The Twelve-Factor App describes how to build and run web software reliably. The OWASP Top 10 lists the most serious web application security risks. Together they explain why each row in the table exists.

- Twelve-Factor says to keep configuration in the environment, separate from code, which is where secrets belong.
- It says to keep development, staging and production as similar as possible, which is why a [staging environment](https://www.plutonapps.com/resources/what-is-a-staging-environment) matters.
- It treats logs as a stream of events, which is the raw material for alerts.
- OWASP's 2025 list puts broken access control first, and includes security logging and alerting failures, and mishandling of exceptional conditions.

## How do you check a Lovable or Supabase app is production-ready?

Walk the six areas against the actual project, starting with the database. In a Supabase backend, that means confirming row-level security and policies on every table, the secret key only on the server, schema changes made through migration files, and a backup plan that matches how much data you can afford to lose.

1. **Access** Open every table and confirm security is on with a policy for each operation.
2. **Changes** Supabase's documentation says to make all schema changes through migration files, not directly on the live database, because direct changes break the migration history.
3. **Recovery** Supabase backs up Pro, Team and Enterprise projects daily. Point-in-time recovery is a paid add-on, and the project is unavailable while a restore runs, so know that before you need it.
4. **Files** Database backups do not include stored files, so files deleted after a backup are not brought back by restoring it.

The free [production readiness check](https://www.plutonapps.com/tools/production-readiness-check) runs a first pass over a live app. For the full walk-through, see [taking a Lovable app to production](https://www.plutonapps.com/guides/lovable-app-to-production).

## Frequently asked questions

### How long does it take to make an app production-ready?

It depends on how much the app does. Looph took 28 working days and is live in production. Bell reached a full staging build in 27 working days; Ripply was built in 36 and is being hardened for launch. Either way, the same six areas have to be done.

### Is production-ready the same as bug-free?

No. Every live app has bugs. Production-ready means the app is protected, tested and watched well enough that a bug is caught quickly, does limited damage and can be rolled back. It describes how the system copes with failure, not a promise that failure never happens.

### What is the most common gap in apps that are not production-ready?

Access control. OWASP ranks broken access control first in its 2025 Top 10. In AI-built apps on Supabase, it usually means a table reachable with the public key because row-level security is off or a policy lets everyone through, while the screens hide the data and look fine.

### Does production-ready mean I need a staging environment?

In practice, yes. You need somewhere to try a change with production-like settings before real users see it. The Twelve-Factor App recommends keeping development, staging and production as similar as possible, so a change that works in staging is likely to work in production too.

## Read next

- [The Ripply case study: a queue stress-tested with 25,000 entries](https://www.plutonapps.com/work/ripply)
- [Plans and pricing](https://www.plutonapps.com/pricing)

## Sources

- [The Twelve-Factor App](https://12factor.net/)
- [OWASP Top 10:2025](https://top10.owasp.org/2025)
- [Supabase documentation: Database backups](https://supabase.com/docs/guides/platform/backups)
- [Supabase documentation: Database migrations](https://supabase.com/docs/guides/deployment/database-migrations)