Every Feature You Build Before Launch Costs You Twice

There's a version of this mistake every founder is at risk of making, and it doesn't look like a mistake while it's happening. It looks like diligence.

I over-engineered a product for a scale it never reached. Multi-tenancy designed in from day one. A domain model built to extend cleanly in every direction the business might someday need. Infrastructure that would have handled real growth competently, the day real growth arrived. It never arrived. The product never launched. Today the whole thing quietly serves two or three internal users, running infrastructure sized for thousands.

If you're a founder reading a status update that describes work like that, it will sound responsible. That's exactly the problem, and it's worth understanding precisely why.

I've written the engineer's half of this before — why over-engineering is a confession that you didn't understand the problem. This is the other half: what that instinct costs the person paying for it.

The spend you don't see happening

Nobody puts "build for a scale we don't have yet" on a roadmap you'd approve. What you actually see is a stream of individually reasonable asks: "we should design the data model properly now, it's expensive to change later." "Let's build this the right way so we're not stuck redoing it." "This will save us time when we scale." Each one, taken alone, sounds like the kind of thing a careful team should be saying to you.

What you don't see, because nobody frames it this way, is the running total. Every one of those asks is buying insurance against a future that hasn't been proven to exist yet — customer number 100, load you haven't seen, requirements you're guessing at. Insurance has a cost, and before you've validated that you need it, that cost comes entirely out of the one thing a pre-launch startup can't get back: the runway you had to find out whether anyone wants what you're building.

The product didn't fail because the engineering was bad. It failed to launch because the engineering effort had somewhere else to be — pointed at problems that were real in theory and absent in practice — while the actual open question, whether anyone wanted the thing at all, sat unanswered the entire time.

Why the sunk cost makes it worse, not better

Here's the part that makes this specifically a founder problem, not just an engineering one. Once the elaborate version exists, throwing it away feels like waste — even after it's obviously the wrong size for what you have. Good engineering is persuasive. It's hard to walk away from something well-built, even when "well-built for a problem you don't have" is the actual diagnosis.

That's the trap closing. Having spent months on multi-tenancy and a fully general domain model, we were never going to casually rip it out once the real, much smaller user base showed up — the sunk cost argument writes itself: "we already built it, might as well use it." So the product kept carrying architecture sized for an audience that was still hypothetical, long after the actual audience turned out to be three people down the hall. The over-engineering doesn't just cost you once, at build time. It costs you again every time you decide not to simplify, because simplifying now means admitting the first spend didn't need to happen.

The question that would have caught it

The one question that would have stopped this early wasn't technical, and it's one you're fully equipped to ask: "What does this feature or decision prove, and could we find that out with something smaller?"

Applied to the actual case: did we need full multi-tenant isolation to find out if anyone wanted the product, or did we need one working version and five real users willing to tell us the truth? The honest answer, in hindsight, was obvious. It wasn't obvious at the time, because the engineering reasoning for building it "right" was sound on its own terms — it just wasn't in service of the actual open question.

You don't need to evaluate whether multi-tenancy is well-implemented to ask this question. You need to ask what it's proving, before it gets built, every time a "let's build this properly now" request reaches you. If the honest answer is "it doesn't prove anything yet, it just avoids rework later," that's not automatically a no — but it's a deliberate trade-off against your runway, and it should be made as one, out loud, not waved through as ordinary diligence.

What to actually approve before launch

A useful split for anything on the pre-launch roadmap:

• Build: anything that's required to test the core question — will someone actually use or pay for this. Nothing more.
• Fake: anything that looks real to a user but is manual or hardcoded behind the scenes. A "recommendation engine" can be you manually picking recommendations for the first fifty users. Nobody needs to know.
• Cut, for now: anything justified by a scale, a use case, or a customer segment you haven't validated yet. Multi-tenancy for a product with zero tenants. An admin dashboard for a team of two. A permissions system for users who don't exist.

The uncomfortable part of this split is that "build it properly" almost always sorts into the third bucket before you have real users, because "properly" is a bet on a future you haven't confirmed yet. That's not a reason to never build properly. It's a reason to build properly for the audience you actually have, and treat everything sized for the audience you're hoping for as a decision to revisit once that audience is real.

Two things change the arithmetic of that split. First, generation got cheap: AI can build the thing now, which makes building the wrong thing faster rather than less likely. Second, the corners you do cut to stay in the first bucket are a real obligation — priced, not ignored.

Your next step

Look at your current roadmap and find the item most often described as "the right way to build it." Ask what it proves, right now, with the users or customers you actually have today. If the honest answer is "nothing yet," that's worth a direct conversation before more of your runway goes into it. If you want an outside, disinterested read on whether your MVP scope matches the size of what you've actually validated, I do a few free second opinions a month for founders in exactly this spot. No pitch, nothing to buy afterward. hello@ruchitsuthar.com.

Frequently asked questions

How do I know if my MVP has scope creep?

A useful test: for every feature or architectural decision, ask what it proves right now, with the users you actually have. If the honest answer is "it protects us against a scale or use case we haven't validated yet," that's scope built for a hoped-for future, not the question your MVP is supposed to be answering.

Why is over-engineering expensive for a pre-launch startup specifically?

Because the resource a pre-launch startup can least afford to lose is runway, and every feature built for unvalidated scale spends runway on insurance instead of on finding out whether anyone wants the product. Worse, once the elaborate version exists, sunk cost makes it harder to walk away from — so the cost compounds instead of stopping at the build.

What should I build before launch versus what should I fake or cut?

Build only what's needed to test your core question — will someone use or pay for this. Fake anything that can look real to a user while being manual behind the scenes (a hand-picked recommendation list instead of a real engine). Cut anything justified by scale or a use case you haven't validated, like multi-tenancy with zero tenants.

Isn't it cheaper to build things properly the first time instead of redoing them later?

Sometimes — but only for things you've already validated you need. For anything sized to a hoped-for future rather than a confirmed one, "build it properly now" is a bet against your own runway, not a guaranteed saving. The honest version of that advice is: build properly for the audience you actually have.

How do I stop my engineers from over-building before launch?

Ask what each significant technical decision proves, before it's approved, and require an answer that references your actual current users or customers — not a hypothetical future scale. This doesn't require judging the engineering itself, only whether the work is aimed at your validated open question or at a future nobody has confirmed yet.