Your AI-built prototype works. Here is what it needs before real users.

Lovable, Bolt and Cursor can get a founder to a clickable product in a weekend. The gap between that and something people pay for is smaller than a rewrite, and bigger than most people expect.

More founders now show up with a working app instead of a slide deck. That is good news. A prototype you built yourself answers questions a deck never could, and it proves you understand your own product better than anyone you are about to hire.

Andrej Karpathy coined "vibe coding" in February 2025. By November, Collins had made it word of the year. A year after coining it, Karpathy was already calling it passé and describing what comes next as "agentic engineering": agents write most of the code, and people own the architecture, the review and the quality. This note is about that second half.

What the prototype is good for

Keep it. A working prototype shows which screens matter, what the data looks like and where people get stuck. It is also the clearest spec you will ever hand an engineer. We read prototypes the way we read a requirements document, only faster.

Where AI-built prototypes usually break

The failures are predictable, and none of them show up in a demo. A demo is one person, on good Wi-Fi, doing the expected thing.

• Data access. Rules that look right in the interface but are not enforced on the server, so any signed-in user can read someone else's records.
• Secrets in the browser. Keys for payments, email or the model provider shipped to every visitor.
• No migrations. The database schema was edited by hand many times and nobody can rebuild it from scratch.
• The happy path only. Nothing handles a timeout, a retry, a duplicate payment or a user who double-clicks.
• No tests and no error tracking, so the first sign of a bug is an angry message.
• Model calls without limits: no timeout, no cost ceiling, no plan for when the answer is wrong.

Most of this can be fixed in place. The useful question is not "rewrite or not". It is which parts can hurt someone if they fail in front of real users and real money.

A short audit, then a decision

Before we change a line, we spend a few days on four questions. The answers decide whether we harden what is there or rebuild one layer of it.

• Can one user see another user's data? Check every query that reads user data and every storage bucket.
• What breaks when two things happen at once? Payments, stock and bookings: anywhere a race condition costs money.
• Can we deploy it twice and get the same result? If the setup only exists on one laptop, that is the first fix.
• What does one more user cost? This matters most when every request calls a model.

The frontend often survives mostly intact. The real work tends to sit in the backend, the data model and the access rules. That is also why "just rewrite it" is usually the wrong call. You throw away the parts that already work and lose the speed that got you this far.

Keep using the tools

We use them every day. Coding agents are good at boilerplate, migrations, test scaffolding and the tenth form screen. The difference in production is that a person decides the structure first and reads what comes back. You keep the speed and lose most of the surprises.

If you are at this stage

• Write down the three things a paying user must be able to do without errors. Protect those first.
• Move every secret to the server today. It takes about an hour.
• Put the database schema under version control.
• Add error tracking before you add another feature.
• Do not take payments on code nobody has read.

A prototype real people have clicked through is worth a lot. Treat it as a first draft: keep what it taught you, fix what could hurt someone, and ship the next version on purpose.