MVP software development when the prototype already exists

A field guide to finishing what Cursor, v0, and Claude Code started. How to take a half-working vibe-coded prototype and ship it as a real MVP without rewriting from scratch.

KEY TAKEAWAYS

• ↳A working Cursor prototype is worth maybe 30% of an MVP. The other 70% is auth, billing, deploys, error handling, and the bug you'll find on day three.
• ↳Don't rewrite. Audit, freeze the scope, and replace pieces in order: data layer, auth, payments, deploy, then polish.
• ↳The most expensive bug in a vibe-coded MVP is almost always silent API key leakage or a database with no migrations.
• ↳Plan for the second deploy before the first. If you can't ship a hotfix in 20 minutes, you don't have an MVP, you have a demo.

A founder messaged me last month with a Next.js repo, a Vercel deploy that mostly worked, and a Stripe test key checked into the public GitHub. The product was a niche CRM for dog trainers. Cursor had written about 80% of the code over a weekend. It looked great. It did not work.

This is the job now. Not building from zero. Finishing what Cursor, v0, and Claude Code started.

The prototype is not the MVP

A prototype proves the idea is buildable. An MVP proves people will use it without you sitting next to them. The gap between those two things is where most vibe-coded projects die.

When I open a half-finished Cursor project, the same things are always broken or missing:

• Auth that works for one user but breaks the moment two people log in at once
• A Supabase or Firebase setup with no row-level security
• API keys in .env.local that also somehow ended up in a commit from three days ago
• No migrations, just whatever schema the AI happened to write last
• Error handling that is try { ... } catch (e) { console.log(e) }
• A landing page that looks like a SaaS template because it is a SaaS template
• Zero analytics, zero logging, zero way to know if anything is working in production

The code is not bad. It is just unfinished in the specific ways that matter for shipping. That is what custom MVP development actually is when you start from an AI prototype: a triage job, not a greenfield build.

Step one: audit before you touch anything

The instinct is to start fixing. Don’t. Spend half a day reading.

I keep a checklist open in a scratch file:

- [ ] What does this actually do? (write it in one sentence)
- [ ] What framework, what versions, what package manager?
- [ ] Where does data live? Is the schema in the repo?
- [ ] Auth: which provider, where is session state, who can read what?
- [ ] Payments: present? test mode? webhooks?
- [ ] Secrets: how many .env files, are any committed, are any rotated?
- [ ] Deploy: where, who has access, how do rollbacks work?
- [ ] Tests: any? (the answer is almost always no)
- [ ] What does the README actually say vs what the code does?

This takes two to four hours and saves you a week. If the founder says “it’s almost done,” the audit is how you find out it isn’t.

On the dog trainer CRM, the audit turned up: Stripe live key in a public repo (rotated in the first ten minutes), a Supabase database with RLS off so any logged-in user could read any other user’s clients, and a vercel.json that was overriding the Next.js build in a way that broke server actions intermittently. None of this would have shown up in a demo.

Freeze the scope, then cut it

The second mistake after “rewrite from scratch” is “finish everything the founder imagined.” Cursor is generous. It will happily scaffold seventeen features in a weekend. The founder now thinks the product has seventeen features. It has one and a half.

I list every feature in the prototype, mark each as one of:

• Works. Ship as-is.
• Works but unsafe. Needs hardening before launch.
• Half-built. Finish or cut.
• Decoration. Cut.

The goal is to find the smallest version of the product that someone would pay for. Usually that is two or three real features, well-finished, plus auth and payments. Everything else is decoration, even if it looks impressive in the demo.

This is the conversation founders hate and need. “You shipped a beautiful settings page with 14 toggles. None of them are wired up. We are cutting 12 of them. Pick the two that matter.”

The order of operations that actually works

For mvp web development on top of an existing prototype, the order I follow is boring and specific:

1. Lock secrets. Rotate every key. Move to a real secret store (Vercel env vars, Cloudflare Workers secrets, whatever the deploy target uses). Add a pre-commit hook with gitleaks so this does not happen again.
2. Fix the data layer. Write the migrations the AI didn’t. If it’s Supabase, turn on RLS and write policies. If it’s Firebase, write security rules. Test them with two real test accounts.
3. Real auth. Replace whatever toy auth is there with something that handles password reset, email verification, and session expiry. Clerk or Supabase Auth for most projects. Don’t roll your own.
4. Payments, if relevant. Stripe with webhook handling and idempotency keys. RevenueCat if it’s mobile. Test the failure paths: declined card, webhook retry, refund.
5. Deploy pipeline. Production branch, preview branches, a rollback you can do from your phone. I usually go Cloudflare Pages or Vercel for web, Hetzner for anything that needs a real server.
6. Observability. Sentry for errors. A logger that does more than console.log. One dashboard you check on Mondays.
7. Then, and only then, polish.

The order matters. Polishing UI on top of broken auth is how you ship a product that loses customer data on day four.

A concrete example

The dog trainer CRM, from “Cursor weekend project” to paying users, took eleven working days. Rough breakdown:

• Day 1: audit, secret rotation, scope cut from 17 features to 4
• Days 2-3: Supabase schema cleanup, migrations, RLS policies
• Day 4: replaced ad-hoc auth with Supabase Auth, added email verification via Resend
• Days 5-6: Stripe subscriptions with webhook handler, Turnstile on signup to kill bots
• Day 7: Cloudflare Pages deploy with preview branches, Sentry wired in
• Days 8-9: actually finished the two half-built features (client notes, session scheduling)
• Day 10: landing page rewrite, replaced the generic template with something that mentioned dogs
• Day 11: first three paying users, one production bug, 18-minute hotfix

Nothing exotic. No rewrites. About 40% of the original Cursor code is still in the repo, mostly the UI components and the route structure, both of which were fine.

What I tell founders who ask if they should just keep going alone

Sometimes yes. If you’re technical enough to do the audit yourself and patient enough to fix the boring stuff before adding features, keep going. Cursor and Claude Code will get you further than you think.

If you’ve been “two weeks from launch” for three months, that’s the signal. The prototype is done. The MVP is a different job. That is the gap our mvp software development services exist to close, and it’s also the gap most solo founders underestimate by about 4x.

If you want a second pair of eyes on a half-finished prototype before you commit to another month alone, send it over and I’ll tell you honestly what’s left.

FREQUENTLY ASKED

Common questions

▸What does MVP actually mean when I already have a Cursor prototype?

The MVP is the smallest version of your product that a stranger will pay for and use without you helping them. A Cursor prototype proves the idea works on your machine. The MVP work is everything between that and a stranger swiping a credit card: real auth, payments, a database that doesn't leak, a deploy you can roll back, error tracking, and finishing the two or three features that actually matter. Usually 60-70% of the total effort.

▸Should I rewrite the AI-generated code or build on top of it?

Build on top of it, almost always. AI-generated code from Cursor or Claude Code is usually structurally fine, especially the UI and routing. The problems are concentrated in specific places: auth, data access policies, secret management, and error handling. Rewriting throws away the parts that work to fix the parts that don't. Audit, identify the broken layers, replace those, leave the rest. A rewrite adds weeks and rarely produces a better product.

▸How long does it take to finish a vibe-coded prototype into a real MVP?

For a typical web app with one main feature, auth, and payments: two to four weeks of focused work. Longer if the prototype has serious data model problems or if the scope hasn't been cut. The variable that matters most is not the code, it's whether the founder will agree to ship a smaller product. Projects that stay on schedule are the ones where someone cut the feature list in half on day one.

▸What's an example of a finishing job that went well?

A dog trainer CRM built over a weekend in Cursor. 17 half-built features, Stripe live key in a public repo, no row-level security on the database. Eleven working days later it had four real features, paying customers, and a hotfix pipeline. About 40% of the original AI code shipped unchanged, mostly the UI components. The work was auth, payments, data security, deploy, and cutting 13 features that didn't matter.

▸What should I look for in an MVP development company or agency?

Someone who will audit your existing code before quoting, not pitch you a rewrite. Ask them to name the specific things they'd change in the first week, with specific tools and reasons. If the answer is generic ("we'll modernize the stack"), keep looking. The right partner reads your repo, finds the three things that will break in production, and tells you what to cut. Also: time zones and communication cadence matter more than headcount.

▸How do I keep my AI tools useful during the finishing phase?

Use Cursor and Claude Code for the boring stuff: writing migrations, generating type-safe API clients, writing test cases for the auth flows, scaffolding webhook handlers. They're great at this. Where they struggle is decisions: which auth provider, what to cut from scope, how to structure the database for the next six months. Treat them as a fast junior engineer, not an architect. The architecture decisions are still yours.

Related posts

5/20/2026

Pair-build mode: how we work with vibe coders without taking over their project

Most agencies eat the codebase. We don't. Here's how EdsDev runs pair-build engagements with vibe coders shipping in Cursor and Claude Code — without hijacking the keyboard or the vision.

collabvibe-codingpair-programming

5/14/2026

The vibe coder pre-launch checklist: what actually breaks in production

You shipped it in a weekend with Cursor. Now it has users. Here's the unglamorous list of things that break when AI-generated code meets real traffic, real money, and real people.

vibe-codingproductionai-tools

6/2/2026

Building an AI chatbot for small business that actually knows your products

The RAG stack we ship for small business chatbots: ingestion, embeddings, retrieval, guardrails, and the boring parts that decide whether it answers correctly or hallucinates a refund policy.

ragai agentschatbots