Almost every first conversation with a founder starts with some version of "what would this cost?" — asked before we've talked about what the product actually needs to do. That's not a criticism; it's the natural question. But the honest answer is that MVP cost isn't a single number, it's a function of maybe five variables that most founders haven't separated out yet, and the spread between a lean MVP and an overbuilt one is easily 5-10x for what a user experiences as "basically the same product."
The biggest cost driver isn't features — it's how many systems the product has to talk to
A product with no external dependencies — no payments, no third-party auth, no external data source — is a fundamentally different build than one that has to integrate a payment processor, handle OAuth against three providers, and pull live data from an external API. Each integration isn't just the code to call it; it's the error handling for when it's slow, the fallback for when it's down, and the edge cases in its documentation that don't match its actual behavior. We've seen founders scope "add Stripe" as a footnote and watch it become a third of a sprint, because subscription billing, webhooks, and failed-payment handling are their own small system, not a checkbox.
Real-time and multiplayer features cost more than they look like they should
A feature that reads as simple in a product spec — "users can see each other's activity live," "two people can edit the same thing at once" — usually implies WebSocket infrastructure, state synchronization, and conflict resolution that a standard CRUD app never has to think about. This is the category of feature most likely to blow a founder's budget estimate, because it looks like a UI detail and is actually an architecture decision. If real-time isn't core to why your product exists, cutting it from v1 is usually the single highest-leverage cost reduction available.
Compliance and data-handling requirements are invisible until they're not
An MVP handling health data, financial data, or anything tied to a government ID inherits handling requirements that a generic SaaS tool doesn't — audit logging, access controls, data residency, retention policies. None of this shows up in a feature list, and all of it is dramatically cheaper to build in from the start than to retrofit after a security review flags it. We treat this as a scoping-phase question, not a launch-phase one, precisely because retrofitting compliance into a system that assumed none of it mattered is frequently a rebuild of the storage and auth layers, not a patch.
"MVP" and "prototype" are not the same budget, even though they're often quoted the same
A clickable prototype that demonstrates a flow to investors and a minimum viable product that real users can rely on for real tasks are different engineering problems with different acceptable failure rates. A prototype can fake data, skip error states, and break on the unhappy path — it exists to communicate an idea. An MVP that a paying user depends on needs real error handling, real data persistence, and enough reliability that a bad experience doesn't become the user's first and last impression. Founders sometimes ask for prototype pricing and MVP-grade reliability in the same sentence; naming that mismatch early saves everyone a bad surprise at delivery.
What actually keeps MVP cost down without cutting the product that matters
- Scope to the one workflow that proves your core hypothesis — not every feature on the eventual roadmap, just the one a user needs to get real value once.
- Cut real-time/multiplayer features from v1 unless they're the entire reason the product exists.
- Decide compliance and data-residency requirements during scoping, not after a security review — retrofitting them is the most expensive way to add them.
- Use proven managed infrastructure (auth providers, payment processors, hosting platforms) instead of building undifferentiated plumbing from scratch — that plumbing is never your product's actual value.
- Ask any vendor quoting a number to first ask you what systems the product talks to and what compliance requirements apply — a quote given before that conversation is a guess.
The founders who get the best outcome aren't the ones who found the cheapest quote — they're the ones who scoped tightly enough that the cheap quote and the right quote turned out to be the same number. That's the conversation we'd rather have in week one than the one where we explain, in week six, why the number changed.