Building for scale from day one vs. moving fast: the real MVP tradeoffs

Founders get conflicting advice on this constantly, and both sides are usually right about something real, they're just answering different questions. "Move fast, don't over-engineer" is right about product-market fit risk. "Build it properly" is right about the cost of certain kinds of rework. The trick is knowing which risk is actually bigger for what you're building.

What's genuinely cheap to fix later

• UI polish and visual design: easy to iterate once you know what users actually respond to
• Feature completeness: adding a missing feature to a validated product is normal, expected work
• Infrastructure scaling: moving from a single server to a load-balanced cluster is a well-understood, mechanical migration when the time comes
• Non-critical performance: a slow admin page nobody uses daily can wait

What's genuinely expensive to fix later

• Core data models: a poorly designed schema for your central entities (orders, users, the thing your product actually revolves around) touches everything downstream
• Security and auth architecture: retrofitting proper authorization onto a system that assumed a single trusted user is a rewrite, not a patch
• Payment and money-handling logic: errors here have real financial and legal consequences from day one, MVP or not
• Anything that becomes a contractual or compliance commitment once customers depend on it

The actual rule we use

Move fast and stay deliberately unpolished on anything you're still validating: feature scope, UI direction, even which user segment you're building for. Be deliberate and get it right the first time on anything that's expensive to change later: core data models, money handling, and security fundamentals, even in an MVP. These aren't in tension; they're two different lists, and conflating them is where teams either over-build a feature nobody wanted or under-build the one thing that was always going to matter.

A concrete example

On a recent PG accommodation platform build, the guest-facing search and browse UI went through several fast iterations post-launch based on real usage, genuinely an MVP, refined live. The payment and subscription state machine underneath it, by contrast, was designed carefully up front, because retrofitting correct payment-state handling after real money is moving through a system is a materially harder and riskier job than getting the UI right the second time.