MVP – minimum viable product – is one of those words that appears in every second proposal and means something different in every project. For some it is a clickable mockup, for others a half-finished product you have to apologize for. We mean a third thing: a deliberately small but properly built first version that takes over a real task in your business. Understood that way, the MVP approach is the best route to custom software on a limited budget – if you cut in the right places.

Small in scope, not in quality

The most important distinction first: an MVP saves on feature count, not on substance. An application with three features that run reliably, are built cleanly, and can be extended is an MVP. An application with ten features that wobble is a prototype – and prototypes have the unpleasant habit of going into production and staying there for years.

The difference doesn’t show on day one. It shows at the first expansion. If you build on a solid foundation, version two costs the normal price. If you build on a prototype, you first pay for the cleanup and then for version two.

Finding the core: one task, one group of users

A viable MVP answers a single question: which workflow hurts the most today? That might be the scheduling that lives in an overwhelmed spreadsheet, the order intake that gets retyped three times, or the monthly reporting that eats two days.

The first version covers exactly that one workflow – completely, for the people who work with it daily. Everything adjacent stays out for now. This sounds banal, but it is where most budgets tip over: “a tool for dispatch” quickly becomes “and accounting could use something too”, and three wishes later the project costs three times as much. Growing scope is not a small-business quirk: a study by McKinsey and the University of Oxford (2012) of 5,400 large IT projects found they ran 45 percent over budget on average and delivered 56 percent less value than predicted.

What does not belong in version 1

That generously ordered features end up idle is not a hunch: at the XP 2002 conference, Standish Group chairman Jim Johnson presented data from four internal business applications in which 64 percent of features were rarely or never used. Four applications is a small sample, but the direction matches what we find when cleaning up systems that grew for years. A few candidates that can almost always wait – and cost more than they deliver in a first version:

Elaborate roles and permissions: at the start, distinguishing two or three user groups is usually enough. Fine-grained permissions can be retrofitted.
Dashboards and analytics: after three months of real data you know which reports are actually needed. Before that, you are guessing.
Integrations with every neighboring system: the one interface that eliminates daily retyping goes in. The three others that “would be handy someday” do not.
Edge cases that occur twice a year: those can have a manual path at first.

Where cutting is off limits

Three things can only be fixed expensively later, so they belong even in the smallest first version: a well-thought-out data model, because the structure of your data outlives every interface and every rebuild; a proper authentication and security setup, because “we’ll do login properly later” takes its revenge reliably; and the ownership question – code that belongs to you, with documentation, so that you could switch providers.

Automated tests for the core logic belong in as well: they are what lets version two ship without breaking what version one could do. Cutting here means saving on the house’s foundation in order to invest in the curtains.

What “small budget” means in concrete terms

An honest ballpark: a focused first version – one core workflow, few user groups, one integration, properly built – typically lands in the range of €10,000 to €25,000 with us and is in production within four to ten weeks. Significantly below that, it becomes hard to take the foundations above seriously; significantly above it, you usually no longer have an MVP but a full project dressed up as one.

Cost control beyond the launch matters too: agree up front what happens when new wishes appear along the way. With us that runs through a fixed-price option where changes are priced transparently before they are built – the MVP stays small because every extension is a conscious decision rather than a creeping annex.

After launch: observe first, then extend

The first weeks of real operation are worth more than any concept document. Now you see which feature gets used daily, where people get stuck, and which of the postponed wishes is genuinely missing – and which quietly disappears because nobody misses it.

Expansion then follows usage, not the original wish list. That is the real payoff of the MVP approach: you spend the bigger money only once the application has proven it carries its weight, and by then you know far more precisely what to spend it on.