Prototype to production: a checklist
A prototype answers whether anyone wants this. Production answers different questions: what happens at a hundred users, when someone tries to read other people's data, when payments fail, and when something that worked yesterday breaks.
In short
Fifteen items in three groups. Before the first real user: the code is in your repository, secrets are on the server, the server checks data access, production data is separate from test data, and a backup actually restores. In the first month: you see errors before a customer reports them, schema changes are versioned, payment notifications have their signature checked, AI spending is capped. As you grow: load, dependencies, documentation and a person who knows the system. Anything in the first group that is not done is better closed before launch, not after.
Before the first real user
| # | Item | How to check |
|---|
| 1 | The code is in your repository, not only inside the platform | There is a GitHub or other repository in your name, and it builds the same version that runs on the site |
| 2 | No secrets in browser code | F12, search for key, secret, token. Anything found, except the Supabase public key, moves to the server and gets revoked |
| 3 | The server checks data access | A second user tries to open someone else's record by changing the number in the URL. In Supabase, RLS is enabled on every table |
| 4 | Production database separate from test | Experiments and test data never end up in the database where customers live |
| 5 | A backup restores | Not that backups are taken, but that one was actually restored once and the data checked |
Item 5 is the one checked least often. A backup that has never been restored is an assumption, not a backup.
In the first month
| # | Item | How to check |
|---|
| 6 | You see errors before customers do | Error tracking is connected (for example Sentry) and alerts reach a living person |
| 7 | Schema changes are versioned | Every table change is a migration file in the repository, not a manual edit in the production console |
| 8 | Payment notifications are verified | The webhook checks the payment provider's signature, and a repeated notification does not create a second payment |
| 9 | AI spending is capped | If the app calls models: a per-user limit, an overall budget, and an alert when it is exceeded |
| 10 | Email arrives | The domain has SPF and DKIM, and signup and password reset emails do not land in spam |
As you grow
| # | Item | How to check |
|---|
| 11 | Abuse protection | Rate limits on signup, login, and expensive operations |
| 12 | Load | The most frequent database queries use indexes; a list does not load the whole table |
| 13 | Dependencies | Every package exists and is maintained, the lock file is in the repository, and known vulnerabilities are fixed |
| 14 | Law and privacy | The privacy policy matches what the system really collects; in Israel that means Amendment 13 |
| 15 | A person who knows the system | Someone other than the AI assistant can explain how the system works and how to ship a fix at night |
Why in this order
What sets the first group apart is that its mistakes cannot be fixed after the fact. A leaked key has leaked. Other people's data, once read, has been read. A lost database without a tested backup does not come back. Everything else is unpleasant but fixable after launch.
The second group becomes urgent together with money and users: before there are payments, item 8 is not burning, but the first double charge costs more than the check would have.
The third group is about the system outliving its author. Item 15 is the most underrated in AI projects: the code was written fast, and often nobody, including the owner, can explain why it was built this way.
If items are missing
That is normal: a prototype was never supposed to have all of this. The question is what comes next. Usually the answer is one of three: close the gaps in the existing code, rewrite specific parts, or, less often, rewrite the system on the same data model. Which of the three becomes clear after the review, not before.
Frequently asked questions
Can an app built with Lovable or Bolt go to production?
Yes, if the first group is done: code in your repository, secrets on the server, the server checks access, production data separated, backup tested. The platform does not prevent production, but it does not do it for you either.
What is the most dangerous thing in an AI prototype before launch?
Permissions checked only in the interface. The app looks right, but the server runs any user's request against any data. It does not show up in a demo, only in a deliberate attempt.
Do I need to rewrite the prototype from scratch?
Usually not. Most checklist items are closed in the existing code. A rewrite is justified when the data model does not fit the problem or when fixes cost more than a new version.
How long does production readiness take?
It depends on how many items are missing and how many tables and places trust the interface. After a review against this list the time is known item by item.
What if the app already has customers?
Start with items 2, 3 and 5, in that order: secrets, access, backup. They close what cannot be fixed after the fact.
SLAtech LTD