What Jobr, Fixie and Tinrate taught us about cutting scope on purpose instead of by accident.
Every product we have shipped went live with roughly half the features the first roadmap promised. Not because we ran out of time or money. Because somewhere between the first workshop and the first release, we cut the list in half on purpose. We now tell every founder to expect this, and most of them push back. This post is the argument we make in that meeting.
Nobody ever ships the full feature list. The only question is whether you choose what to drop or let the deadline choose for you. When the deadline chooses, it cuts the wrong things: the boring reliability work goes first, because it is invisible in a demo, and you launch with six half-finished features instead of three finished ones. Choosing early means the cut happens where it hurts least. Choosing late means it happens wherever you were standing when the money ran out.
Jobr launched in Kortrijk. One city, in a country with plenty of them. That was not a technical limitation, the app works anywhere. It was a scope decision applied to the market instead of the codebase. A matchmaking app needs candidates and vacancies in the same place at the same time, and a thin national launch would have felt empty everywhere at once. One city let a small supply of employers and candidates actually find each other, and it made the feedback loop legible: when something did not work in Kortrijk, we knew, because we could talk to the people it did not work for. Expanding city by city is slower on a map and faster in reality.
The test we apply is blunt: does this feature change whether the core transaction happens? On Tinrate the core transaction is an expert getting booked and paid. Escrow that releases after the call and invoicing an expert can actually use survived every cut, because without them the transaction dies. A polished profile editor did not make version one, because a rough profile still gets booked. On Fixie, our own goal-tracking app, the monthly look-back survived because it is the reason people come back; plenty of settings screens did not. Fixie runs with a few hundred users and a subscription model, and it got there on a fraction of its original feature list.
The uncomfortable part: cutting scope means launching something you are slightly embarrassed by. The profile editor is rough. The admin panel is a spreadsheet. Some flow that a competitor polishes is manual behind the scenes. Founders feel this as risk. We have come to read it as the opposite. The riskiest launch is the complete one, because it means you spent the most money before hearing from a single real user. Every feature you ship before launch is built on assumptions. Every feature you ship after launch is built on evidence.
So when we scope a project now, we draw the line early and in writing: this is version one, these are the features that change whether the core transaction happens, everything else waits for evidence. Founders who accept that trade get to their first real user months sooner and spend the saved budget on what those users reveal. Founders who insist on the full list get a longer invoice and a launch that teaches them the same lesson at a higher price.
Half the features, one city, slightly embarrassed. That is not a compromised launch. On everything we have shipped, it was the plan that worked.
We build websites, software and companies. Tell us which one you need.