We audit vibe-coded marketplaces. Here's what the rebuild actually costs.
A founder came to us last year with a working marketplace. Two sides, listings, search, sign-up, a functioning checkout. Built almost entirely by prompting, over about six weeks, by someone who had never written production code. Live, with real users on it.
It's genuinely impressive, and this article isn't going to pretend otherwise. Something that would have cost €40,000 and four months in 2022 now takes a determined non-engineer a month and a half. That's a real change and anyone telling you it isn't has an interest in you believing them.
But that founder came to us because the platform had started taking money, and everything that happens after a platform starts taking money is a different kind of problem. So this is the specific version: what we find when we audit these builds, why the gap appears where it does, and what it costs to close.
What AI-assisted building genuinely does well
Let's mark this clearly, because the rest only makes sense against it.
Validation artefacts. If the question is "will anyone care", a clickable thing that mostly works answers it faster and cheaper than any other method. Build it, put it in front of thirty people, learn. We recommend this regularly, including to people who came to us for a quote.
Internal tools. Something your own team uses, where the users are five people who can be told about the quirks and no stranger's money is involved. The tolerance for rough edges is enormous, and the value is immediate.
The first 60% of a straightforward product. Standard patterns – auth, CRUD, forms, a dashboard – are the most heavily represented code on the internet, and generation quality tracks representation. This part works well and it works fast.
Speed of iteration in the exploratory phase. Trying five versions of a flow in a week is a real advantage, and it beats what a traditional process delivers in that window.
If your project is one of these, this article isn't about you. The problem is specific and it starts at a specific moment.
Where the gap opens
The pattern is consistent enough that we can now predict it from a two-sentence description.
The first 60% goes fast. The remaining 40% doesn't converge.
Not "goes slower". Doesn't converge – meaning each fix produces a new break somewhere else, and the founder spends four weeks in a loop that isn't visibly ending. The reason is structural rather than technical: generated code is generated locally. Each prompt produces a solution to the thing you asked about, and it's a good solution to that thing. What no sequence of prompts produces is a coherent system where those solutions relate to each other consistently.
For a to-do app that's fine, because there's almost nothing to relate. For a marketplace it's the whole problem, because a marketplace is defined by things that have to be consistent across the entire application:
Permissions. Who can see and do what, checked in every single place, forever. Generated code tends to check on the screens where you thought to ask. The one you didn't think of is the one that leaks. We have found, more than once, a marketplace where changing an ID in a URL showed you another user's transaction history – because that check was implemented on the four pages that got discussed and not on the fifth.
Money. Payment flows fail partway. A charge succeeds and the webhook doesn't arrive. A refund is issued twice because a button was double-clicked. A payout is released before a hold expires. Handling this correctly means idempotency, reconciliation and state machines that account for every partial failure – and you don't know to prompt for it, because it never happens while you're testing with a test card.
Data integrity under concurrency. Two people booking the same slot at the same second. Generated code is written and tested by one person clicking one thing at a time, so the class of bug that only appears with simultaneous users is invisible until you have simultaneous users. On a marketplace, that's launch day.
State across the whole transaction lifecycle. A booking that's requested, accepted, paid, held, disputed, partially refunded and closed touches a dozen places in the codebase. Each was generated in a separate conversation, and each has a slightly different idea of what those states mean.
None of these are things you can prompt your way out of, because you have to know they exist to ask. That's the actual asymmetry – not that the AI can't write the code, but that nobody is telling you what to request.
What the audit finds
We audit existing codebases regularly and give an honest verdict, including "keep your current team". Here's what shows up in the vibe-coded ones, roughly in order of how often:
Authorisation checks on some endpoints and not others. Nearly universal. The most common serious finding.
Business logic in the frontend. Prices, fees, discounts and eligibility calculated client-side, therefore editable by anyone who opens dev tools. On a platform that moves money, this is not a code quality issue.
No handling of partial payment failure. The happy path works. The seven ways it can fail halfway aren't there.
Secrets and keys in the wrong place. Committed, or exposed in the client bundle.
No admin layer at all. No moderation, no dispute handling, no refunds, no impersonation. All of it happening manually in the database, by the founder, at eleven at night.
Personal data with no deletion path. Relevant if you have EU users, and you do.
No tests. Which means nothing can be changed with confidence, which is why the last 40% doesn't converge.
Individually, each is fixable. The reason the rewrite question comes up is that they share a cause. The data model was never designed – it accreted, one prompt at a time. Fixing authorisation properly means knowing who owns what, which means the ownership model has to exist, which means touching everything built on top of it.
The actual cost
This is the part founders want a number for, so: it depends, and here's what it depends on.
When the platform is pre-revenue and the data model is sound, a partial rebuild is usually enough. Keep the frontend and the product decisions, rebuild the backend around a proper model. This is the good case and it's more common than the internet suggests. We've told clients their build was fine and to keep going.
When the platform has users and money moving, the cost is no longer measured in engineering hours. It's the migration – you're rebuilding under a live system with real balances, real bookings and real people who notice. That's what turns a €25k rebuild into a €60k one. The engineering is a fraction of it.
When there's a security finding with users on the platform, it stops being a budget conversation. You are notifying people. In the EU, depending on what leaked, you may be notifying a regulator. The cost of the rewrite is now the smaller number on the page.
The pattern in all three: the price is set by when you look, not by what you built. The same codebase audited pre-launch is a redesign. Audited eight months in, it's a migration. Audited after an incident, it's an incident.
What we'd actually tell you to do
Not "hire a studio". Specifically:
Build the validation version however you like. Prompt the whole thing. Prove someone wants it. This is the right call and we'll say so on a first call even though it means no project for us.
Draw the line at money and other people's data. That's the transition point – not a user count, not a funding round. The moment real payments or real personal data are involved, the failure modes change from embarrassing to expensive. That's when the build needs someone who knows what to ask for.
Get the data model reviewed early, even if you build the rest yourself. This is the cheapest intervention available and almost nobody does it. A few days of a senior engineer designing ownership, roles and transaction states, and then you carry on prompting inside a structure that holds. It's a fraction of a rebuild and it prevents most of one.
Don't wait for the thing that forces the decision. The founders who come to us after an incident pay several times what the ones who came in month two paid, for the same outcome.
Why we're not worried about it
There's a version of this article written by an agency that feels threatened, and it's a worse article.
The truth is that AI-assisted building has removed exactly the work we were least interested in selling – the standard screens, the boilerplate, the fourth version of a signup form. What's left is what was always the hard part and what we already say on the front page: the cold start, the trust model, the money, the operational tooling nobody demos. None of that got easier. If anything the demand went up, because far more people now get far enough to encounter it.
So we're not arguing you shouldn't have built it. Most of the time we're arguing you should have got it looked at three months earlier.