The short answer
it's about what happens when something goes wrong at 2am and you're not there to fix it. it's about whether your app can survive a TechCrunch mention. it's about whether the next engineer you hire can actually read the codebase or has to start over.
The short version
the founder sent me a loom at 11pm. his developer had handed over the "finished" MVP three weeks earlier. it worked, kind of. auth broke under load. the stripe webhook failed silently. there was no error logging, no deploy pipeline, and the database schema was one bad migration away from losing user data.
it wasn't an MVP. it was a prototype wearing an MVP's clothes.
this is the gap nobody talks about honestly. the one that lives between "it works on my machine" and "it works for your first 500 users." and it's the gap that costs founders months of delay, second rebuilds, and sometimes the whole company.
the prototype vs. production gap is real and it's expensive
i used to think the gap was about code quality. it's not, not entirely.
it's about what happens when something goes wrong at 2am and you're not there to fix it. it's about whether your app can survive a TechCrunch mention. it's about whether the next engineer you hire can actually read the codebase or has to start over.
a prototype answers the question: does this idea work?
a production-ready MVP answers a different question entirely: can this idea survive contact with real users?
the difference isn't always visible in a demo. it shows up in the first week of real usage: when a user tries to reset their password at midnight, when two users edit the same record simultaneously, when your payment provider sends a duplicate webhook and your order system charges someone twice.
what "production-ready" actually means, no jargon
every studio claims to build production-ready products. most mean "it's deployed somewhere." that's not the same thing.
here's what i look for when i'm evaluating whether an MVP is actually production-ready:
Frequently asked questions
- error handling that doesn't embarrass you
- production-ready means your app fails gracefully. when an API call times out, the user sees a useful message, not a blank screen or a raw 500 error. when something breaks in the background, you know about it before your user emails you about it.
- authentication that won't haunt you
- i've inherited codebases where passwords were stored in plain text. i've seen JWT tokens with no expiry. i've seen "auth" that was really just a hardcoded password in the frontend.
- a database schema someone else can understand
- this is where most prototype builds fall apart. tables named "data1" and "temp_users." foreign keys that don't exist. no indexes on the columns being queried in every API call.
- a deploy pipeline that isn't "i'll FTP it manually"
- production-ready means you can ship a bug fix in under 10 minutes without fear. CI/CD, environment variables handled properly, staging and production separated, rollback possible if something breaks.
- observability from day one
- analytics, uptime monitoring, basic performance tracking. not because you'll obsess over dashboards: because when something breaks, you need to know what happened and when.
- "what does your handover include?"
- a production-ready build should hand over: codebase with documentation, environment setup instructions, deploy pipeline configuration, and a 30-minute walkthrough minimum. if the answer is "we'll push the code to a repo and you're good," that's a red flag.
- "what monitoring is set up at launch?"
- they should be able to name specific tools. Sentry or Datadog for errors. uptime monitoring. basic analytics. if they look confused by the question, you'll be flying blind on day one.
- "can you show me a codebase you've handed over before?"
- not a demo. not a live URL. the actual code. if it's readable, documented, and structured logically. That's a signal. if it's a tangle of spaghetti that "works". That's your future rebuild.
- "what happens if something breaks in week two after launch?"
- the answer should be specific. a retainer, a bug-fix window, a direct line. "we'll see" is not an answer.
Talking about mvp development?
The smallest build that answers a real question about your market — with the emphasis genuinely on minimum.