You vibe-coded your MVP. Now what?

The prototype did its job

Start by not apologising for it. Vibe coding turned weeks of wondering whether an idea was worth anything into days of watching people use it. If real people are signing in and coming back, the prototype has already answered the question it existed to answer. That is the hardest part of an MVP, and it is the part most projects get wrong.

The trouble is that the quality that made it fast is the same one that makes it fragile. The tool wrote code to make the screen you described work. It did not write code for the people you did not describe: the visitor who is not signed in, the user who pastes something strange into a form, the one who is quietly looking for a way into somebody else's account.

A prototype is judged by whether it works when you use it. A product is judged by what happens when someone else does.

Signs it has outgrown the prompt

There is no single moment when a prototype becomes a product. There are signals, and most founders notice them late because each one feels small on its own.

• Strangers are signing up, not just people you sent the link to.
• You store something a user would be upset to see leaked. Messages, documents, anything about health or money, or even just a list of email addresses.
• Money moves through it.
• Fixing one thing breaks two others, and you have stopped trusting the prompt to know why.
• You hesitate before deploying, or you only deploy late at night when fewer people are watching.
• Nobody can explain how a feature works without opening the code and asking the AI.

One of these is a note for the backlog. Two or more means the product is carrying more weight than its foundations were designed for.

What to check first, in order

Most vibe-coded products do not need to be rewritten. They need an afternoon of uncomfortable questions and a few weeks of focused fixes. This is the order we look in, because it is the order in which things tend to hurt.

1. Who can read whose data. Many AI app tools connect the front end straight to the database, and the only thing standing between one user and another user's records is a set of access rules. If those rules were generated, or switched off to make an error go away, find out now. The test is simple: sign in as one user and try to load another user's data.
2. Secrets in the browser. Keys for payments, email or AI providers that live in front-end code can be read by anyone who opens the developer tools. Move them to the server, then replace them, because you cannot know who has already copied them.
3. The edges of sign-in. Password reset, changing an email address, deleted accounts, invited users. The happy path usually works. These edges are where accounts get taken over.
4. Payments and webhooks. Does the app believe the browser when it says a payment succeeded? What happens when the payment provider's confirmation arrives twice, late, or not at all?
5. Backups you have actually restored. A backup you have never restored is a hope, not a backup.
6. What people see when something fails. Generated interfaces are designed for the moment everything loads. Empty screens, slow connections, failed saves and vague error messages are where users decide whether to trust you. This is design work as much as code.
7. One test on the path that makes money. Not full coverage. One automated check that signing up, the core action and paying still work, run before every deploy.
8. A way to know it is down before your users tell you. Error tracking and an uptime check take an afternoon to set up and pay for themselves the first night something breaks.

Harden it or rewrite it?

Founders at this stage tend to hear two confident answers. The tool says everything is fine. A developer glances at the code and says it all has to be rewritten. Usually neither is right.

Hardening is the answer when the data model matches how the business really works, the platform can do what the next six months need, and the problems cluster in the list above. Fix them, add the missing checks, and keep going.

A rewrite, usually of one part rather than the whole, is the answer when:

• the data model is wrong, and the thing you stored as a single field has turned out to be the centre of the business;
• the next item on the roadmap is something the platform cannot do, such as real-time collaboration, offline use, a native app or a compliance requirement;
• every small change touches many unrelated files, and even the AI cannot make one without breaking something else.

Even then, the prototype is not wasted. It is the most accurate specification you will ever have: real screens, real flows and the recorded behaviour of real users. A rewrite that starts from a working prototype moves faster than one that starts from a document.

What not to do next

• Do not ask the tool to "make it secure". It will answer confidently and change something, and you will not know what.
• Do not keep prompting on the live product. Set up a separate copy where changes can break without users seeing it.
• Do not hand it to anyone who wants to rewrite it before reading it. Ask for written findings first, ranked by how much harm each one could do, and decide from there.
• Do not stop using AI. The goal is not less AI. It is a person who can read what it wrote and say no. We wrote about where that line sits in our own work.

If your vibe-coded product is starting to get real users, send us the link. We will go through it with you and tell you honestly whether it needs a few fixes, a focused hardening sprint or a partial rewrite, and in what order.