How do you differentiate an MVP from a throwaway prototype architecturally?

WHAT THIS TESTS: This question probes your ability to practice Minimum Viable Architecture rather than treating an MVP as a hackathon project. Interviewers want to see that you understand the implicit promise of an MVP: real users will continue using it, which means the system must be operationally sustainable, secure enough for production data, and adaptable to the next two to three pivots. They are looking for judgment about where to invest upfront design without sliding into Big Design Up Front.

A GOOD ANSWER COVERS: First, the conceptual distinction: a throwaway prototype validates an idea and is disposable, while an MVP validates value delivery and must be supportable. Second, lightweight upfront boundaries such as bounded contexts, module interfaces, or API contracts that let you swap crude implementations later without rewriting callers. Third, reversible versus irreversible decisions: defer database sharding but abstract payment provider integration; avoid deep framework magic that couples business logic to infrastructure. Fourth, day-one operability including structured logging, basic metrics, and automated deployment, because user trust erodes quickly if you cannot detect or fix failures. Fifth, a team alignment mechanism like a one-page architecture decision record or constraint list so the shared vision persists beyond the first sprint.

COMMON WRONG ANSWERS: Claiming that agile means architecture should fully emerge with zero upfront thinking; this leads to brittle monoliths that collapse under first-scale pressure. Proposing a sacrificial architecture by default, where the team knowingly plans to throw away the entire stack after validation; this burns user trust and is rarely executed cleanly. Over-engineering for hypothetical millions of users with distributed microservices, multi-region active-active setups, or complex event sourcing before a single paying customer exists.

LIKELY FOLLOW-UPS: How would you change your approach if the MVP suddenly needs to support ten times the user base in thirty days? Which specific technology choices would you refuse to make reversible, and why? How do you convince a product manager that spending two days on observability is part of the MVP and not gold-plating?

ONE CONCRETE EXAMPLE: Imagine a team building a marketplace MVP. Instead of a throwaway script that scrapes supplier inventory, they build a small ingestion service behind an internal API. The first implementation polls a CSV file, but the interface accepts a standard product catalog payload. When validation succeeds, they replace the CSV poller with a webhook receiver and later a message queue without touching the pricing or checkout modules. They run on a single managed database with automated backups, not a serverless experiment that cannot be queried for support tickets.

Source: multiplayer.app