Look at the usage numbers for Lovable, Replit, Base44, Bolt and v0 and then look at how many businesses have come out of them. The first number is enormous. The second one is not. That gap is the most interesting thing in software right now, and the usual explanations for it are wrong.
It is not that the code is bad. We read this code every week and it is genuinely fine - better, on average, than the code in most Series A startups we have worked inside. It is not that the founders are not technical enough, either. Plenty of the stalled projects belong to people who can read every line.
What actually happens is that four things sit between a working prototype and a product people pay for. All four are invisible on screen. None of them are what the founder was hired by the market to know. And a generation of tools has become extraordinarily good at the part before them while doing almost nothing about the part after.
One: the idea never became a specification
You know your business. The model knows how to write code. In between there is a set of rules nobody wrote down: who may see which records, what happens when a refund exceeds the original charge, which of two conflicting edits wins, whether a cancelled subscription keeps access until the period ends.
A generative tool cannot leave those blank. It has to emit something, so it picks an answer for each one - quietly, plausibly, and without telling you a decision was made. The app works. Every decision it guessed at is now a rule in your business that you have never seen.
This is the single most common root cause behind the findings we file. A permissive access rule is not a security bug in the normal sense; it is an unwritten specification, filled in with the answer that made the demo work.
Two: interface design is a skill, not a preference
Generated interfaces look good. That is precisely the trap. They use a modern component library, the spacing is consistent, the colours are coherent, and none of that is the same thing as being usable.
What we see instead, over and over: forms with every field the database has rather than the ones the user can answer; no empty state, so a new user's first screen is a blank table; destructive actions rendered identically to routine ones; flows that assume the reader already knows the thing the product exists to tell them; and error messages that report what the code did rather than what the person should do next.
Founders without a design background cannot see these, because the screen looks like the software they admire. The failure shows up as a metric instead: people sign up, look once, and never return. It gets attributed to marketing.
A working app that nobody comes back to is indistinguishable, from the outside, from an app that does not work.
The fix is not a redesign. It is usually five specific changes - an empty state that teaches, a form cut to the fields that matter, a confirmation on the one action that destroys data, a first-run path, and error text written for a person. That is days of work and it is the highest-return work available on most of these products.
Three: nobody has asked whether it holds at ten thousand users
Not as a worry - as a measurement. "Will it scale" is unanswerable. "How many concurrent users does this configuration serve at a p95 under 400ms, and what breaks first after that" is a number, and getting it takes an afternoon.
Ten thousand monthly users is a small number for a database and a large one for an app that was never measured. It is roughly a few hundred daily actives, tens of concurrent sessions, and a peak of perhaps twenty to fifty requests a second. Any managed Postgres handles that without noticing. What does not handle it is a query with no index, a connection opened per request, or an email sent inside the request that is supposed to return a page.
Which is why the honest version of the question is not about capacity at all. It is about four specific bottlenecks that arrive in a predictable order, and we wrote them up separately because they deserve their own numbers.
Four: the infrastructure was sized by guessing
Two failure modes, opposite in shape and identical in cause. Either the founder over-provisions out of fear and gets a bill they cannot explain to a co-founder, or they stay on builder hosting until the first traffic spike and get an outage they cannot fix at speed. Both come from nobody having modelled the actual traffic.
| Scale | What it actually needs | What people buy |
|---|---|---|
| Pre-launch | One small instance, one managed database, backups on | A Kubernetes cluster, because it seemed responsible |
| 1k users | The same, plus indexes and a pooler | Nothing - still on the builder's free tier |
| 10k users | Two instances, a pooler, a CDN, background jobs | A bigger database, which does not help |
| 100k users | Read replica, caching, queue, and a real cost model | An emergency migration, at the worst possible time |
The middle column is not expensive. For ten thousand users it is a few hundred dollars a month. The reason people do not buy it is not cost - it is that nobody has told them which of those things they actually need, so they choose between doing nothing and doing everything.
Why the tools do not close this
Not because they are bad. Because of what they are optimised for, which is producing an application that works. Every one of these four gaps is invisible to that objective.
- An unwritten business rule cannot be inferred from a prompt, and a permissive guess makes the demo work.
- A usable interface and a good-looking interface are indistinguishable in a screenshot, and screenshots are the feedback signal.
- Load behaviour does not appear until there is load, and there is never load during generation.
- Infrastructure sizing requires traffic data that does not exist yet.
None of that is a criticism. These are extraordinary tools and we use them daily. But they compress the first eighty per cent of building software from months into days, which does not shrink the last twenty per cent at all - it just makes it a much larger share of what is left, and much more surprising when you arrive at it.
What actually closes it
Ranked by return, from the projects we have run:
- Write the ten rules down and check them against the code. A day. It finds the things that would cost you a customer or a lawsuit.
- Fix the five interface problems, not the design. Days. It is what turns a first session into a second one.
- Measure the ceiling, then move it once. An afternoon to measure, a week to fix. Now "will it scale" is a number with a date on it.
- Size the infrastructure against that number, not against fear. Days. Usually it costs less than what you are paying now.
- Put a pipeline around all of it so the next change is safe. A week, and it is the one that compounds.
That is roughly four to six weeks to make a typical AI-built app production ready. It is not a rewrite and it is not glamorous. It is the difference between the enormous first number and the small second one.
Written by Kato Chojiro
Takes AI-built MVPs to production: security, data, and the infrastructure underneath.
Connect on LinkedIn