If you’re commissioning custom software for the first time, you’ll face an early choice: start with an MVP, or specify everything upfront and build the system in full from the outset? It sounds like a question of scope, but it isn’t. It’s a question of when you want to find out whether your assumptions hold up.
An MVP, a minimum viable product, is the smallest working version of your software that delivers real value: enough to use daily, and not much more. Fully built software is the complete system as originally specified, with all functionality in place from day one. Both approaches are legitimate; they simply suit different situations.
The difference lies in when you learn
With fully built software, the learning happens at the end. You specify the requirements, development runs for months, and only at delivery do you find out whether your initial assumptions were right. An MVP reverses that: within weeks, the first users are already working with a live version, and their experience shapes what gets built next.
That difference determines where the risk sits. A wrong assumption in a specification costs months of work on a fully built project; with an MVP, you spot it after the first iteration and adjust. The trade-off is that an MVP never feels finished. There’s always a next step, and that asks for an organisation that keeps prioritising and sets budget aside for further development.
When an MVP is the sensible starting point
An MVP fits when uncertainty is your biggest cost. If you recognise any of these situations, starting small is usually the better choice:
- You’re testing a new concept and don’t yet know whether users will take to it.
- The requirements aren’t fixed yet, or you expect them to shift.
- You want to spread the investment and scale up only once the value is proven.
- Time to launch matters: you want something working this quarter, not next year.
You can read what that choice means for your planning in our article on how long custom software development takes; an MVP sits at the lower end of those ranges.
When building the full system upfront makes sense
There are situations where an MVP adds little. If you’re replacing an existing system whose functionality is already fixed, there’s not much to validate: users expect at least what they already have, from day one. In regulated environments, such as financial services or healthcare, a minimal version isn’t always possible either: compliance requirements apply from day one, not from the third iteration.
The same applies to a proven concept you’re scaling up. When large numbers of users rely on a system every day, predictability outweighs speed of learning. The trade-off doesn’t disappear, though: the further ahead a specification has to look, the greater the risk of functionality nobody ends up using, and of software that turns rigid the moment the market changes.
What an MVP project looks like in practice
Take a client portal, a type of custom application well suited to this approach. The first version does two things: clients log in securely and see their documents. No messaging module, no reporting, no integrations with other systems. That version goes live within weeks and immediately replaces the back and forth of emails with attachments.
From there, usage decides what comes next, not the original wish list. If clients mostly ask about the status of their file, a status view takes priority over the messaging module. If not a single client asks to upload their own documents, you drop that extension without ever having paid for it.
One thing is essential here: minimal applies to the functionality, not the quality. The architecture, security and data structure of the first version have to be able to carry the later system, or you’re trading speed now for a rebuild later. That’s why an MVP needs a plan for ongoing development and maintenance built in from the start.
Not sure which approach fits your situation? One conversation is usually enough to clarify it, because the core question is simple: is it already settled what the software needs to do, or will that only become clear once it’s in use? We develop custom applications both ways, and regularly advise a smaller first step than you had in mind.