# Build Less Than You Think > Scope for technical founders: why over-engineering is procrastination you can defend, and the one test for what to cut before you build the whole thing. The feature you're proudest of is probably the one you should have cut. Not because it's bad. Because you built it before you had any evidence anyone needed it, and the pride is the problem. The thing you most enjoyed making is the thing you'll most resist removing, long after the market has gone quiet on it. Technical founders don't ship too little. They ship too late, carrying too much, most of it added for reasons that felt like quality and were actually fear. ## Over-engineering is procrastination you can defend Procrastination usually feels bad. This kind feels excellent. You're not avoiding the work, you're doing more of it. You're adding the settings panel, the second integration, the abstraction that'll make the next ten features easy. Every addition has a reason, and every reason is real in isolation. But "this will be useful later" is the most expensive sentence in software, because later may never come, and you're spending today's only resource, the time before you learn whether this should exist, buying options on a future that isn't promised. The retry queue you built for scale you don't have. A plugin system for integrations nobody's asked for. Admin tooling for the team of one. All of it defensible. All of it the long way round to finding out if anyone cares. The deeper tell: building more is the part you're good at, so when you're unsure whether the thing is working, you reach for more of it. Scope creep and the editor-as-hiding-place are the same instinct wearing different clothes. And the pressure is rising. When building was slow, the cost of over-building was obvious: you could feel the weeks. Now that a working feature is an afternoon, the brakes are gone. You can add the unnecessary thing before lunch, which means the only thing stopping you is a decision you have to make on purpose. ## The test: what makes the bet true? Every product is a bet on one thing being true: that a specific person has a specific problem worth paying to solve. Ask of every feature: *does this make that bet true, or does it just make the bet prettier?* The version you should build is the smallest one that lets a real person hit the actual problem and tell you whether you solved it. Everything on the critical path to that moment stays. Everything else waits: the polish, the edge cases, the someday-features, the architecture for scale you haven't earned. Not forever. Until the bet pays and you know which parts deserve the investment. A sharper way to run it: for each thing you're about to build, ask *would I put it in front of a customer without this?* If the honest answer is yes, you've found something you can cut, at least for now. Most of the backlog fails this test. That's not a sign you're being sloppy. It's a sign you were about to spend a month making a wrong guess more elaborate. ## What this looks like Imagine an engineer building a tool for independent bookkeepers. Before a single bookkeeper has used it, there's SSO, granular permissions, an audit trail, and a half-built API "because agencies will want to integrate". Four months in. Zero users. Every one of those features is something a real bookkeeping product eventually needs, which is exactly why they felt safe to build, and exactly why they were the wrong thing to build first. The bet was: *a solo bookkeeper will switch tools to save two hours a week on reconciliation.* The smallest test of that bet is reconciliation that works for one person, ugly and manual everywhere else. That could have been in front of someone in three weeks. The other three months were spent making an untested bet look like a finished company, and if the bet was wrong, all of it was waste built on a clean architecture. This bites harder on a tight runway. With less capital around you, the normal Australian case, you don't get the eighteen-month seed round that lets you over-build and discover the mistake later. You get fewer months and fewer second chances. Building less isn't a purity preference here. It's how you stay alive long enough to be right. ## What to do Monday Open your backlog and your current branch. For every item, ask the one question: does this make the bet true, or just prettier? Move everything in the second pile to a "later" list, not deleted, just deferred until you've earned it. Then look at what's left. That short, ugly list is your actual product. Ship that, to a real person, before you let yourself touch anything you parked. You can always add more. You almost never can get back the months you spent adding it too early. Next: the moment you put it in front of someone, the question becomes whether they'll pay, so charge before you feel ready. --- Source: https://kads.au/writing/build-less-than-you-think/ Author: Kads Aziz