What it costs to make an AI-built app production-ready
The cost depends on four things: how much of the app is broken rather than merely insecure, whether the data model can stay as it is, how many external services it touches, and whether you need to keep editing it in the original tool. A review costs far less than a rebuild and tells you which of those apply.
Part of the guide to shipping an app built with an AI coding tool.
Why nobody can quote you from a description
Two apps that sound identical can be days apart in effort. "A marketplace with logins and payments" describes both a job that needs four access policies written and a job that needs the data model restructured before any policy can be written at all. From the outside these look the same.
This is why a fixed quote before anyone has read the code is either padded to cover the worst case or will turn into a change request later. Neither is good for you.
The four things that move the price
- How much is broken versus merely insecure. An app that runs but has no access rules is a smaller job than one that does not start. Insecure is a known, bounded fix. Broken has to be diagnosed first.
- Whether the data model survives. Adding access policies to sensible tables is quick. If ownership was never modelled — no user_id column to check against — the tables have to change first, and everything reading them changes with it.
- How many external services it touches. Every payment provider, auth provider, email service and third-party API is another integration to configure correctly, test, and handle failures for.
- Whether it must stay editable in the original tool. Keeping a project round-trippable back into Lovable or Bolt constrains what can be changed, and constraints cost time.
Fix or rebuild?
Fix, in most cases. The parts AI tools do well — screens, forms, layout, basic flows — are the parts that take longest to rebuild by hand. The parts they get wrong are concentrated in authentication, configuration and data access, which are a small share of the total code. Rebuilding usually means discarding the good work in order to redo the bad.
The exception is the data model. If ownership and permissions were never represented in the schema at all, you are not patching — you are rebuilding the foundation while keeping the interface. That is worth knowing before you start, not halfway through.
What you should refuse to pay for
- Hourly billing on a job nobody has scoped. You carry all the risk of a bad estimate.
- A rebuild recommended before anyone read your code. It is the highest-revenue recommendation available, which is reason enough to be sceptical.
- A quote with no fixed date attached.
- Being told the problem is your platform choice. Supabase, Firebase and the rest are all capable in production. The configuration is the problem, not the platform.
The cheapest useful first step
Get the app reviewed before committing to any fix. A written list of what is wrong and what each item costs turns an open-ended worry into a set of decisions you can make one at a time — including the decision to fix some of it yourself, or to hand the list to a developer you already know.
Vansh Chauhan
Co-founder — full-stack and infrastructure. Works across the whole stack and owns how things get deployed and stay up. If your app runs on your machine and dies on the host, he is the one who finds out why.
Want someone to look at yours?
Send us the repo or the live URL. You get a written list of what is broken, what each fix costs and what can wait — back within 24 hours, and yours to keep either way.
Get a $99 audit