An MVP isn't an application built badly to spend less: it's the smallest one that answers the right question. How to pick that question, what you can handle by hand at first, and the three things that cost twice as much if you postpone them.
by Nadia Maar ·
Almost every custom software project starts too big. Not out of greed: when you describe a process, every case comes to mind, and every case seems essential. The result is a first version that arrives late, costs more than planned and gets half-used, because the process changed in the meantime.
The alternative isn't building less at random. It's building first the part that answers the question that matters — does it actually work, for the people who'll use it? — and postponing everything else deliberately. Here's how to decide.
A useful first version fits in one sentence: who uses it, what they do, what they get. "The sales rep enters an order from their phone and the warehouse sees it straight away." Anything that sentence doesn't need is left out of the first version.
If the description of your first version uses the word "also" more than twice — and also the reports, and also the export, and also the notifications — you're not describing a first version: you're describing the last one.
The sentence is easier to grasp once you see it applied. Three common situations, with the first version that makes sense to build and what stays out, for now:
| The first-version sentence | What stays out, for now |
|---|---|
| A B2B customer reorders the items from their last order through the portal, at their own prices. | The full catalogue, online payments, chat with the sales rep. |
| A warehouse worker confirms from their phone that an order is packed, and the office sees it ready to ship. | Inventory, returns handling, productivity statistics. |
| A sales rep builds a standard quote in a few minutes, with up-to-date prices. | Rare variants, digital signatures, the link to accounting. |
In each case, what stays out isn't less important: it's less urgent, and it's built better once you've seen how the first version gets used.
A first version doesn't have to do everything by itself. Many parts can, for a while, be done by hand behind the scenes — and it's the cheapest way to find out whether they're worth the cost of automating.
| Can be done by hand | Why that pays at the start |
|---|---|
| Reports | An export and a spreadsheet are enough to learn which numbers really matter, before building a dashboard. |
| Rare integrations | Data that changes once a month can be loaded by hand; connect it once you know it's needed. |
| Notifications | An email sent by a person reveals which alerts matter and which are noise. |
| Exceptions | The few odd cases get handled by hand until it's clear which one becomes a rule. |
There are three things a first version must get right, because adding them later costs far more than doing them now. They aren't features: they're foundations.
They're the same three things that separate a website from an application: identity, permissions, a record. A first version can be small in everything, except these.
A first version is built better in small visible steps than in one big final release. The method we use is simple:
The first version has worked if the number in your opening sentence moved — not if every feature was delivered. From there, there are three roads:
It isn't the software it delivers: it's the decision it lets you make while little money has been spent. A project that stops after the first version, because the numbers said stop, is a project that succeeded.
If you can write it — who uses it, what they do, what they get — half the design work is done. If you can't, that's the first problem to solve, before any quote.
The free audit starts right there: the process that costs you most, the sentence that describes it, and what it would take to build its first version. You get a cost and payback estimate.
Custom web application development
The smallest version of the application that answers the question that matters: does it actually work, for the people who'll use it? One person, one flow, one measurable result.
Reports, rare integrations, notifications and exceptions can be handled by hand at first, to learn which ones are worth the cost of automating.
Permissions — who sees what —, the data structure and the log of who did what. Adding them later costs far more than doing them now.
By the number you set yourself at the start — minutes saved, errors avoided, a step that disappears — not by the number of features delivered.