When someone decides to build software, the first instinct is almost always the same: list everything it should do, then build all of it. It feels responsible. It's usually the most expensive mistake you can make — because the biggest risk in any build isn't that the code fails, it's that you spend months building something people don't actually use the way you assumed.

That's the whole case for shipping a first version, small. Here's how to decide what's in it.

What an MVP actually is (and isn't)

"MVP" has been abused into meaning "cheap and half-finished." It doesn't. A minimum viable product is the smallest complete thing that delivers real value — production-grade, just narrow. Not a rough prototype you'll throw away; the first honest version of the real product, doing one job well instead of ten jobs badly.

The test isn't "how little can we build?" It's "what's the smallest version someone would genuinely use — and pay for, or rely on?"

The real cost of building everything first

Building the full vision before anyone's touched it stacks up three quiet costs:

  • You bet big on assumptions. Every feature you build before real usage is a guess. Build fifty of them and you've made fifty untested bets with your budget.
  • It takes far longer. More scope means more time before anything is real — and the longer a build runs without contact with real users, the further it can drift from what they needed.
  • The wrong things get polished. Time spent perfecting a feature nobody ends up using is time — and money — you don't get back.

Ship the core first and every one of those risks shrinks. You learn what matters from real use, then spend the rest of the budget on the things that actually earned it.

What belongs in version one

The trick is to find the one core loop — the single path that delivers the product's main value — and build that end to end, properly. For a marketplace it's list → find → transact. For an internal tool it's the one workflow that's costing you the most today. Everything that isn't part of that core loop is a candidate to cut from v1.

A useful filter for every proposed feature: does the core value work without this? If yes, it can wait. If no, it's in.

What to cut (and add back later)

The usual suspects that feel essential but almost never belong in v1:

  • Elaborate admin dashboards and settings — you can manage a lot by hand at first.
  • Every edge case and permission tier — start with the main one.
  • Integrations you might want — add them when there's demand.
  • Customisation and configurability — hard-code the sensible default; make it flexible once you know what varies.

None of these are gone forever. They're just sequenced — built once the core has proven itself, in the order real usage says matters.

When a full build genuinely is right

Sometimes the honest answer is "build it all." An MVP is the wrong call when the value only exists when the thing is complete (some regulated or safety-critical systems), when a partial version would damage trust with the customers you're launching to, or when the "minimum" genuinely can't be carved down without breaking the core. A good studio will tell you when that's the case rather than reflexively shrinking scope.

Shipping small isn't about doing less. It's about learning before you spend — so the money goes where it's proven to matter.

How we'd approach it

We help you find that core loop, then fix a price and a deadline on it — not on a vague someday-everything. You get a production-grade first version in weeks, a working demo every Friday, and full ownership. Then, if it's earning its keep, we scope the next slice the same way. It's also the fairest way to work with a new studio: you find out we're good on a small, contained bet before a big one.

Not sure where the line is for your idea? That's exactly what a discovery call is for — we'll help you find the smallest version worth building.