You built the thing. Cursor, Claude Code, Lovable, whichever tool, it works and people are using it. Now someone technical has looked at it and used the word “production,” and you are trying to work out whether that means a weekend of cleanup or a second mortgage.
The honest answer is that most founders are asking the wrong question. It is not “rebuild or ship as is.” There is a middle path, and pricing it starts with knowing what the work actually contains.
Hardening is not one job, it is six
“Make it production ready” sounds like a single vague task, which is why it feels expensive and open-ended. Broken into its real parts, it becomes something you can scope and stage.
Authorization. Confirming that every user can touch only their own data, on the server, on every request. If your app has clear ownership of records, this is fast. If ownership is tangled, it takes longer. This is the piece you never skip.
Secrets management. Moving API keys and database credentials out of the code and out of the frontend into proper environment configuration or a secret manager. Usually quick, and usually urgent, because a leaked key is a live liability.
Rate limiting and abuse control. Putting ceilings on logins, signups, password resets, and anything that sends or spends. Small in effort, large in what it prevents.
Database access rules. Correct row-level rules so the public API key cannot read the whole table. Scales with the number of tables holding user data.
Error handling and observability. So that when something breaks in production, you find out from a log or an alert, not from a customer. This is what turns a black box into something you can operate.
Deployment. A repeatable way to ship, a staging environment to test in, and a rollback when a release goes wrong.
What moves the price
Two apps with identical features can cost very different amounts to harden, and the difference is rarely the features. It is the shape of what is underneath.
The cost goes down when the data model has clear ownership, when the app uses a mainstream stack the way it was intended, and when the generated code is boring and repetitive rather than clever. Boring is cheap to fix.
The cost goes up with tangled data ownership, with secrets already committed to a public repository, with heavy custom logic bolted onto the generated base, and with an app already carrying real users whose data cannot be reset while you work.
When a rebuild is genuinely the cheaper option
Sometimes the right advice is to start over, and any honest engineer will tell you when. If the same fix has to be applied in dozens of scattered places because there is no shared structure, patching each one can cost more than rewriting on a clean foundation. If the data model cannot represent what the business actually needs, no amount of hardening changes that.
A rebuild is not failure. The AI-generated version did its real job: it proved people want the thing. That is the expensive question in any startup, and you answered it cheaply. Treat the first build as a paid prototype that earned its keep.
Scope it as an audit first
The reason “production ready” feels frightening is that it sounds like an open cheque. The fix for that fear is to not sign one.
Start with a fixed-scope audit. Someone reviews the code and tells you which of the six areas above are fine, which need work, and roughly how much. You come out of it with a prioritized list and a real number, and you decide what to do with it. The audit is small, defined, and enough on its own to end the uncertainty.
From there you can stage the work. Close the security gaps first, because those are liabilities. Add observability next, because you cannot operate what you cannot see. Leave the polish for when traffic justifies it.
The decision underneath the decision
What you are really deciding is when to spend, not whether. Every app that gets real users eventually pays for production quality. Paying now, while the user count is small and the surface is simple, is cheaper than paying after an incident, when the same work happens under pressure and in public.
If you want that audit and a real number to plan around, NukyLabs runs exactly this kind of scoped review, and the deliverable is a decision you can act on rather than an open-ended contract.
Facing this in your own build?
NukyLabs helps founders take AI-generated apps, agents, and automations from a working demo to something that survives real users. If any of the above hit close to home, we can scope it with you.
Get a free consultation →or message us to talk through your project.