Differentiating an MVP from a throwaway prototype
Tests your grasp of strategic technical investment. Differentiate by intent: an MVP is the first version, a prototype is disposable. A great answer introduces Minimum Viable Architecture (MVA) to support future needs.
What's really being asked
This question tests your ability to think strategically about technical debt and architecture. The interviewer wants to see if you can balance the need for speed (MVP) with the need for a sustainable future (viability). They are testing your understanding of Minimum Viable Architecture (MVA) versus a purely tactical, throwaway build. It separates candidates who just build fast from those who build smart.
The full answer
Four key points in order. First, define the difference by its core intent: a prototype is built to be thrown away to test a concept, while an MVP is the first version of a product intended to be iterated upon and kept. Second, introduce the concept of Minimum Viable Architecture (MVA) as the key technical differentiator. An MVP has an MVA; a prototype does not. Third, describe what "just enough" architecture means in practice: focusing on stable API contracts, a flexible data model, and clear module boundaries, while deferring decisions on premature scaling or complex features. Fourth, explain that this MVA approach avoids both the "emergent architecture" trap (no design) and the "Big Design Up Front" trap (too much design).
The mistakes people make
A major red flag is conflating the two concepts, suggesting an MVP is just a prototype you ship to users. Another is advocating for a "sacrificial architecture" without acknowledging the extreme risks and costs. Many successful MVPs built this way (like early eBay) created massive technical debt that required years and millions of dollars to fix. A candidate who presents this as a default strategy without discussing the trade-offs is showing inexperience. Simply saying "architecture will just emerge" is also a weak answer, as it ignores the need for a shared technical vision.
What usually comes next
"Give an example of a tactical decision you might make for an MVP that you know you'll have to pay back later." "How do you communicate the MVA and its constraints to the team and stakeholders?" "At what point does the 'Minimum' Viable Architecture need to be revisited and expanded? What are the triggers?"
A concrete example
For an MVP, you might choose a monolithic architecture for speed of development and deployment. A good MVA decision within that monolith would be to enforce strict modularity with clear internal API boundaries between domains (e.g., User Management, Order Processing). A prototype, in contrast, might just hardcode user data or mix all logic together. The MVP's MVA plans for a future where those modules could be broken out into microservices by respecting those boundaries from day one, even if they live in the same codebase initially.
Interview question
From a technical strategy perspective, what is the fundamental difference between an MVP and a throwaway prototype?
- a.An MVP incorporates a Minimum Viable Architecture (MVA) to enable future iteration, while a prototype lacks such architectural consideration.Correct
- b.An MVP focuses on immediate user value with minimal code, while a prototype explores complex technical challenges.
- c.An MVP prioritizes a fully scalable and robust architecture from inception, while a prototype uses a quick-and-dirty, non-scalable approach.
- d.A prototype is built to be completely discarded and rebuilt, whereas an MVP is designed for continuous, unplanned architectural evolution.
Why? this is the answer
The card explicitly states that an MVP includes a Minimum Viable Architecture (MVA) to support future needs and iteration, whereas a prototype is built to be thrown away and lacks such architectural consideration. Option D describes the 'emergent architecture' trap, and option C describes the 'Big Design Up Front' trap, both of which MVA aims to avoid for an MVP.
Just read this? Test yourself on what you have been reading.
Read the original → multiplayer.app
- #architecture
- #agile
- #mvp
- #technical-debt
- #strategy
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on architecture — each one lists the topics its interview covers.
See open roles