MVP vs. Throwaway Prototype: Technical Differences

What's really being asked

This question probes your understanding of strategic technical planning, specifically the concept of Minimum Viable Architecture (MVA). The interviewer wants to see if you can balance the speed required for an MVP with the long-term sustainability that makes it "viable." They are testing if you can avoid the twin traps of over-engineering (Big Design Up Front) and under-engineering (a throwaway prototype masquerading as an MVP), which leads to immense technical debt.

The full answer

First, clearly define the difference based on intent. A prototype is a "throw-away" tool to evaluate a concept, often with a sacrificial architecture. An MVP is the first version of a real product that users can expect to continue using, implying a promise of sustainability.

Second, introduce Minimum Viable Architecture (MVA) as the key technical differentiator. An MVP is built on an MVA, which is "just enough architecture" to meet current needs while being adaptable for the future. This prevents user disillusionment from poor performance and protects against competitors if the product succeeds.

Third, provide examples of MVA decisions. This isn't about choosing microservices from day one. It's about principles. For instance, building a well-structured monolith with clear separation of concerns (e.g., distinct modules for auth, billing, and core logic with well-defined internal APIs). This allows future extraction of a module into a microservice without a full rewrite. Other MVA choices include establishing CI/CD pipelines, logging, and monitoring from the start.

The mistakes people make

One major red flag is describing a "tactical" or "sacrificial" architecture for an MVP. This is the correct approach for a prototype, not a viable product. It demonstrates a misunderstanding of the "V" in MVP and sets the stage for a costly rewrite if the product gains traction.

Another wrong answer is advocating for a purely "emergent" architecture with zero upfront design. While agile, this approach often leads to chaos and technical debt. A good MVA requires some initial design to create a shared vision and agree on constraints.

Finally, proposing a complex, over-engineered solution (Big Design Up Front) with multiple microservices, event queues, and different database types for a simple product. This shows a failure to understand the "Minimum" in MVP and wastes valuable time and resources.

What usually comes next

"You chose a monolith for your MVP. How exactly would you structure it to allow a future migration to microservices without a rewrite?" "How do you and your team decide what constitutes 'just enough' architecture? What does that meeting look like?" "When might a sacrificial, prototype-style architecture actually be the right choice, even if it's risky?"

A concrete example

Imagine building a new paid newsletter platform. A throwaway prototype might involve using an off-the-shelf tool like Substack to validate if authors will join and readers will pay. The architecture is whatever Substack provides; it's entirely sacrificial.

An MVP with an MVA, however, would be a custom application. You might build a simple monolith using a framework the team knows well (e.g., Rails or Django). The key MVA decision is to logically separate user management, subscription processing, and email sending into distinct internal modules with clear interfaces. Even though they run in the same process, this separation means that if subscription logic becomes highly complex, you can extract just that module into its own service later. This is "just enough" upfront design to ensure future flexibility.