Cut scope, not engineering
An MVP has two ways to get smaller. Only one of them still works when someone pays for it.
The short version
4 things that decide this
- 01Cutting features and cutting engineering both shrink an MVP, but they are not the same decision.
- 02Cutting a feature means fewer things work. Cutting engineering means everything works a little worse.
- 03Golancer launched with one operational core, invoicing, CRM, scheduling and AI daily priorities, and skipped features rather than skip the plumbing under them.
- 04Broollie kept its first release to the meeting lifecycle itself, then grew into 38+ countries once the core held under real load.
Two ways to make an MVP smaller
A founder with a fixed budget and a launch date has one real lever: scope. The question is what to cut, and most teams treat every cut as equal. It is not.
Cutting a feature means the product does fewer things. A freelancer platform without a proposal module still invoices, still schedules, still tracks clients. The parts that ship are complete. Cutting engineering means every feature ships thinner. No server-side checks. No handling for two people editing the same record. No plan for what happens when a webhook fires twice. The product does more things, and each one is a little less trustworthy.
Why one cut compounds and the other does not
A missing feature is visible and bounded. A user notices it is gone, and the team knows exactly what to build next. A thin foundation stays invisible until it fails. It fails in a different place every time: a race condition here, an unhandled error there, a permission check that was never written.
- 01A cut feature costs one conversation with the buyer about what shipped later
- 02A cut engineering layer costs a debugging session for every bug it causes, spread across months
- 03Scope comes back as a roadmap item. Skipped engineering comes back as a rebuild
One MVP that stayed narrow, one that grew
Golancer gives freelancers one place to run their business instead of the four to six tools most were juggling. The first version did not try to be everything. It shipped a dashboard, a client CRM, a Stripe-powered invoice engine, and project tracking synced to Google Calendar. A public booking page and AI daily priorities rounded it out. Each piece was built to hold real payments and real client data from day one. Invoicing and scheduling are the parts a freelancer cannot afford to half-build.
Broollie took the same approach from the other direction. Meetings ended without a record: no agenda, no minutes, no tracked action items. Its first build stayed inside that one lifecycle, before the call, during it, after it, rather than expanding into adjacent tools. GPT-4o-mini drafts the agenda, MeetGeek transcribes, and Twilio sends the follow-up by voice, WhatsApp and SMS. That narrow, solidly built core is what a platform now used across 38+ countries, by universities, enterprises, government and healthcare teams, was built on. It did not get there by adding scope early. It got there because the first version did not have to be rebuilt to handle the second customer, or the two hundredth.
What to cut when the deadline is fixed
When the launch date will not move, cut the feature list before cutting anything underneath it. Ask which capabilities the first customer actually needs, and defer the rest to a named later release rather than a vague one. Keep every feature that does ship built to handle two users, a failed request, and a record two people touch at once. A smaller product that works is a foundation. A full-looking product that breaks under its first real customer is a rebuild waiting to happen.
Questions this raises
01How small should an MVP be?
Small enough that every feature it ships is fully built, not partially built. That usually means one core workflow done properly, rather than several done thinly. Golancer's first release covered invoicing, CRM, scheduling and daily priorities, each complete, instead of a wider set of half-finished modules.
02What should get cut first when scope has to shrink?
Features, not the engineering underneath the features that remain. Drop a module, a report, an integration, before dropping auth checks, error handling or data isolation between users. A dropped feature is visible and reversible. Dropped engineering causes failures that show up later, in production, with real data at stake.
03Is a narrow MVP a permanent limit?
No. Broollie started inside one workflow, the meeting lifecycle, and grew to teams in 38+ countries once that core proved solid. A narrow, well-built first version is a base to extend. A wide, thinly built one is a base to replace.
