If You Throw Away Your MVP Code, It Wasn't an MVP
6-day "MVPs" are prototypes disguised as products. Real MVPs use foundation-first architecture for extension, not throwaway code.
"Got my booking app MVP built on Upwork in 6 days and was super happy with it. Basic stuff - customers book appointments, staff see shared calendar, Instagram link works great. Proved the concept, got some salons using it.
But now trying to add features and every developer says the whole thing needs rebuilding?? Like why can't you just add staff availability settings or service variations to something that already works?
Anyone else deal with this? So frustrating to hear 'rewrite everything' when I just want to improve my working MVP. What am I missing here?"
— Jane
Jane wanted "a booking app" but received software real customers shouldn't use—and a developer called it "MVP."
What Jane is missing is that 6 days isn't enough to build an MVP. In 6 days you build a prototype, and I see a lot of gurus disguise prototypes as MVPs.
Prototypes are meant to be thrown away. MVPs are meant to be the first iteration of working software — half a product, not a half-ass product — that allows building on top of it.
Software Idea Evolution Stages
Every software idea goes through predictable stages. Understanding these stages prevents confusion about what you're actually building.
Proof of Concept (days): Can we technically build this? Tests if booking systems can integrate with payments and calendars. Outcome: Technical validation.
Prototype (days): Does this solve the user problem? Jane's Upwork build falls here — functional demo that proves market demand. Outcome: Throwaway code.
MVP (weeks): Foundation that becomes your product. Built with architecture that handles real business complexity. Outcome: First version you extend.
Full Product (months): Complete feature set with all business requirements. Built by extending the MVP foundation.
PoCs and prototypes are meant to be thrown away after they do their work — validating technical feasibility or proving market demand. Only at the MVP level should we build something that lasts and allows future extension.
But why does this confusion happen so often?
Disguising Prototypes as MVPs
Jane's problem isn't unique. The market is full of developers and agencies disguising prototypes as MVPs.
Why does this happen? Because "MVP" sounds more valuable than "prototype." Clients want to hear they're getting a product foundation, not throwaway code.
But calling a prototype an MVP doesn't change what it is. Jane's 6-day build proved market demand — successful prototype. But it can't evolve into a real product — failed MVP.
This confusion leads to another misconception about MVPs themselves.
MVP Doesn't Mean Dirty
When I say Jane's prototype wasn't an MVP, I'm not suggesting MVPs should be perfect. MVPs are intentionally limited in scope — that's the "minimum" part.
But limited scope doesn't mean poor architecture. You can build half a product with solid foundations.
Jane's booking app had the right scope: appointments, calendar, payments. The problem wasn't what it did — it was how it was built. Hardcoded business rules, no flexibility for growth, no consideration for real salon complexity.
A real MVP would handle the same core features but with architecture that adapts to business needs.
MVP doesn't mean solving all problems or having polished UI. But it definitely should allow future development: extending existing features, adding new features, changing providers smoothly. When Jane wanted staff availability settings, that should be configuration, not rebuilding.
So what does proper MVP architecture actually look like?
Foundation-First Architecture
So what would a real MVP look like for Jane's booking app? The answer lies in foundation-first architecture.
I call it LEGO-style development because components snap together cleanly and can be swapped without breaking everything else.
Jane's booking app core logic: Match available staff with requested services at acceptable times.
The adapters: How you display calendars, process payments, send notifications, and store data. These can change without touching the core logic.
This is ports and adapters architecture — your core business logic stays separate from specific implementations. The database is a LEGO brick: PostgreSQL today, maybe MongoDB tomorrow. The payment processor is a LEGO brick: Stripe initially, maybe custom solution at scale.
Real example: When I switched a client from OpenAI to Gemini for document analysis, it took 2 hours because the AI integration was built as a replaceable adapter, not hardcoded API calls.
When Jane needs staff availability rules, you configure the existing scheduling system instead of rewriting the entire application.
Why Simple Features Require Rebuilds
Jane's frustration is understandable: "Why can't you just add staff availability settings?" seems like a simple request.
But her prototype treats all staff as interchangeable. The database probably has a single "staff" table with basic info. The scheduling logic assumes everyone works the same hours and can do any service.
Adding individual availability means restructuring how the system thinks about appointments. Instead of "find any available staff," it becomes "find staff who work these hours AND can do this service AND have the right skills."
This touches the scheduling engine, database structure, user interface, and business logic. When everything is hardcoded together, changing one piece breaks everything else.
The funny thing is that making it work from the beginning doesn't require more work — it requires more thinking. You need to find what are the core parts, what are the moving parts, and what potential changes might be required later but aren't needed now.
Nine pregnant women cannot give birth in one month. Some things require proper thinking and architecture time upfront, but enable rapid development later.
What Jane Should Do Now
Jane's prototype served its purpose—it validated that salons want booking software. Now she faces a choice:
Option 1: Rebuild with foundation-first architecture. Use everything learned from the prototype to build modular systems that can handle salon complexity. This is what most developers recommend.
Option 2: Extend the prototype carefully. Add features incrementally while documenting what breaks, then rebuild when the technical debt becomes unmanageable.
What I’d recommend:
Document all the requirements that emerged during scaling attempts
Find a developer who understands foundation-first architecture
Build the real MVP with modular systems designed for salon complexity
Use the working prototype to keep current salons happy during the rebuild
The prototype validated market demand. Now invest in the foundation that can become the actual product.