Your MVP was vibe-coded. Here is what to check before you scale it
An MVP built with AI coding tools is not a problem in itself. The problem starts when a prototype becomes a product, with customers, money and personal data flowing through it, and nobody has checked what is underneath. Before you scale, hire or raise, seven checks tell you whether you need a cleanup, a partial rebuild or nothing at all. And you should get that answer from someone whose income does not depend on the answer being “rebuild”.
Why AI-built MVPs break in predictable ways
AI coding tools optimise for one thing: making the feature work in front of you. That is exactly what an MVP needs. It also leaves recurring patterns behind:
- The same business rule implemented in three places, slightly differently.
- Permission checks in the interface but not on the server.
- API keys pasted into code to get something working.
- Error handling that covers the happy path only.
- Dependencies added whenever a prompt suggested one.
- No tests, because nothing asked for them.
- No one who holds the full picture, because the context lived in chat sessions that are gone.
None of these are unique to AI-generated code. They can accumulate when nobody reviews how the generated pieces fit together.
Seven checks before you scale
An engineer can use these as an initial pass. Resolving a suspicious result may take longer, and passing one check does not clear the whole system.
- Who can access what? Using two test accounts in your own system, try to read one account’s data from the other by changing an ID in a request. If the server returns it, stop everything else.
- Where are the secrets? Search the code and the git history for API keys and passwords. Check that nothing sensitive ships to the browser or the mobile app.
- What happens when things fail? Look at payments, emails and anything that calls an outside service. Is a failed call retried? Can a customer be charged twice?
- Is the same rule in more than one place? Pick one rule that matters, such as pricing or permissions. Find every place it is implemented. More than one usually means they already disagree.
- Can you change it safely? Are there tests around the flows that make money? Can you deploy and roll back in minutes?
- What did the AI pull in? List the dependencies. Look for unmaintained packages, unexpected ones nobody remembers adding and names that look like typos of popular libraries.
- Does anyone understand it? Ask an engineer to explain, in an hour, how data moves from sign-up to invoice. If nobody can, that is your biggest risk.
Cleanup, partial rebuild or leave it
| What the checks show | What to do |
|---|---|
| Check 1 or 2 fails | Fix now, before any new feature. This is a security incident waiting to happen |
| Checks 3–5 fail, but the pain sits in a few modules | Clean up: tests around the money flows, then refactor those modules one by one |
| The data model cannot support the next 12 months of the roadmap | Rebuild that part incrementally, with the old system running alongside |
| Most checks pass and the plan does not need much scale yet | Leave it. Add tests as you go and revisit before the next round |
The last row matters. Plenty of AI-built MVPs are good enough for their stage, and a rebuild would only burn runway. If you are unsure which row you are in, this note on stabilising, rewriting or pausing walks through the decision.
What a checkable finding looks like
Whatever review you get, each finding should come with its evidence, so your own team can verify it. That means the file, the request or the chain of modules involved, and why it matters. My public evidence packs show the format on open-source code. A useful finding includes enough detail for the team to reproduce it and decide whether it matters.
Why the audit should be independent
Many of the companies offering “vibe coding audits” also sell the rescue. That is a real conflict of interest: the audit is how they find the project. Before you hire anyone to review your codebase, ask three questions:
- Will you bid for the fix? If yes, how is the audit kept separate from the sale?
- Is the price fixed before you start?
- Will each finding come with the evidence behind it, so my team can verify it?
For transparency: besides fixed-price reviews, I also offer ongoing fractional engineering work. The review is priced, scoped and delivered on its own, with evidence for every finding, so you can take it to any team you like.
FAQ
Is AI-generated code worse than human-written code? Not by nature. The difference is that it is produced faster than anyone reviews it. A team that reviews and tests AI-generated code gets most of the speed without most of the debt.
Should we stop using AI coding tools? No. Add what the tools skip: review, tests on critical flows and someone who owns the architecture.
When is the right time for an audit? Before you hire your first engineer, before a funding round and before signing an enterprise customer. Each of those makes the codebase someone else’s problem too.
What if the audit says we need a rewrite? Then you will have the evidence to plan it properly, piece by piece, while the current system keeps serving customers.
Before you scale, hire or raise
Start with the 10-minute scorecard: “Stabilise, rewrite or pause? 12 questions to know if you have enough evidence”. If a decision is close, the 3-Day Technical Risk Review ($3,500 fixed, excl. VAT) gives you a decision memo, a prioritised risk register and a 30-day stabilisation plan.