Key takeaway: Most agencies told this founder her Replit-built marketplace had to be rebuilt from scratch. It didn't. We read the code, hardened the four things that break under real users and money (payments, auth, the data layer, and infrastructure), and launched in about two weeks. Six months on it has 600 paying members.
A founder came to us last year with a marketplace she'd already announced to her industry.
She'd built it fast on Replit, with no technical background, because she had a real market gap and a waitlist she'd publicly committed to. The app demoed well. Behind the scenes it was held together with hope. She knew it, which is why she went looking for help before opening the doors.
She took it to several developers and agencies. Most told her the same thing: it's impossible to save, you'll have to start from scratch. A rebuild she didn't have time for, on a deadline she'd already announced.
Where we started
We read the codebase asking one thing, what breaks when real users and real money arrive at once, and found payout edge cases, client-trusted auth, unindexed tables, and no real production line.
We didn't rebuild. We read the codebase with one question in front of everything else: what breaks when real users and real money arrive at the same time.
The Stripe Connect Express setup handled the happy path but not the payout edge cases. The split worked when one baker sold one cake to one customer with no refund and no retry. It got vague past that. A few endpoints trusted the client to say who the current user was, instead of deciding that on the server, which meant a curious user with devtools could reach things they shouldn't. The most-queried tables had no indexes, which is invisible at a hundred rows and slow at ten thousand. And the whole thing ran on Replit, with no real line between experimenting and production. A typo at the wrong moment could take the live app down.
None of that was bad work. The founder had shipped something real, which is the hard part. It was a sign the app had never been read with scale and safety in mind. That's a different job than building the demo, and it's the job most fast-built MVPs skip because the demo is what gets you to the waitlist in the first place.
What we actually did
We hardened it in sequence: payments first, then auth on the server, then the data layer, then a migration off Replit to production infrastructure.
We worked in sequence, not in parallel, because the risky changes had to land on a base we trusted.
- Payments first. The Stripe Connect Express flow got rebuilt around the cases nobody had tested by hand: the refund, the partial payout, the retried webhook. Idempotency on the event id, signature verification on every call in, and reconciliation between our records and Stripe's. The split now does the right thing on the unhappy path, not just the demo path.
- Auth next. The decision of who you are moved entirely onto the server. The client tells us what it wants to do, the server decides whether that's allowed. Boring, well-understood, and the only model that survives contact with real users.
- Then the data layer. Indexes on the columns the app actually queries. Query patterns that hold up past demo-sized data. Migrations under version control instead of changes made in a Replit shell and forgotten.
- Finally, infrastructure. We migrated off Replit onto production hosting on Vercel with managed Postgres behind it, with proper environment separation, backups, and error monitoring. A real line between staging and production, so a mistake in development doesn't reach a paying customer.
What happened next
The app launched about two weeks after the rebuild verdict and had 600 paying members six months later.
The app launched in the real world about two weeks after the rebuild verdict. That app is BakeGenie, a marketplace for Australian women who bake from home and sell to their local community, live at https://app.bakegenie.co/.
Six months on, it has 600 paying members. We still maintain it. The founder's own words: she has peace of mind that the technology is looked after so she can focus on sales, and if a critical issue ever comes up the team is on it straight away, any day, any hour.
The takeaway
Most vibe-coded apps are closer to production than the "start over" verdict suggests; the missing piece is reading the code with real users in mind and hardening what breaks first.
A lot of vibe-coded apps get the same verdict from the same agencies: start over. Sometimes that's right. Often it isn't. The codebase is usually closer to production than it looks, because the founder did the work of figuring out what the product should be. The missing piece is someone reading the code with real users in mind and hardening the parts that will break first.
If you've shipped something fast and you're staring at a waitlist wondering whether it'll hold, that read is the whole point of an audit. It's the fastest way to find out whether you're two weeks from launch or genuinely better off starting again.
Frequently Asked Questions
Does a vibe-coded or Replit app always need a full rebuild?
Often not. The codebase is usually closer to production than it looks, because the founder already figured out what the product should be. The missing piece is reading the code with real users in mind and hardening the parts that break first, which can take weeks rather than a rebuild.
What breaks first when a fast-built marketplace gets real users?
Payment edge cases (refunds, partial payouts, retried webhooks), auth that trusts the client for identity, unindexed hot tables that are fast at a hundred rows and slow at ten thousand, and running on a platform with no line between experimenting and production.
How long does an MVP rescue take?
For the marketplace in this story, about two weeks from the rebuild verdict to launching in the real world, with payments, auth, the data layer, and infrastructure hardened in sequence.
Related Services
Need help with what you just read? These services are directly relevant.
