Insights / Article / Custom Application Development
ArticleStart small: why the first release should be modest
A small first release gets feedback early and reduces risk. Solve one complete job for a small group, ship it quickly and let real use guide what comes next.
A small first release gets feedback early and reduces risk. That sounds obvious, yet many custom software projects still begin with a long requirements document, a year-long plan and a single launch date when everything goes live at once. By the time users see the system, the budget is mostly spent and the scope for change is small.
The alternative is to release something modest but genuinely useful within weeks or a few months, put it in front of real users, and let what you learn shape everything that follows. This article explains why that works, how to choose what goes into the first release and what leaders should expect along the way.
Why big first releases go wrong
Large initial releases rest on an assumption that rarely holds: that the organisation knows, in detail and in advance, exactly what the software needs to do. In practice, people describe what they think they need based on how they work today. Once they use a new tool, their needs change. Some requested features go unused. Others nobody thought to ask for turn out to be essential.
A big release also concentrates risk. Every integration, data migration and new process goes live on the same day. If something fails, it is hard to tell which part caused the problem, and the pressure to fix everything at once is intense. Training a whole organisation simultaneously stretches support teams thin just when they are needed most.
The planning trap
A long, detailed plan feels safe because it looks thorough. But the details are guesses until real people use real software. Time spent perfecting the plan is often better spent getting a working version into users’ hands.
Pick one workflow and finish it
Solve a complete job for a small group. The most common mistake with a “small” first release is to build a thin slice of every feature, so that users can start many tasks but finish none. A half-finished tool forces people to switch back to the old system or a spreadsheet to complete their work, and they quickly lose patience.
Choose one workflow that matters, and deliver it end to end. Consider a typical field service business replacing paper job sheets. Rather than building scheduling, stock control, invoicing and customer notifications all at once, the first release might simply let engineers receive jobs on a phone, record what they did and capture a customer signature. Office staff still schedule and invoice the old way for now. But the engineers’ job is fully done in the new tool, and the team learns quickly what works in the field.
How to choose the first workflow
- It should be used often, so you get plenty of feedback quickly.
- It should matter to the business, so success is visible and valued.
- It should be contained enough to build in weeks or a few months, not a year.
- It should involve a group of users willing to try something new and give honest feedback.
- It should avoid the riskiest integrations where possible, leaving them for later releases.
Release quickly to real users
A working version teaches more than a long plan. Within days of using it, users will tell you which screens are confusing, which steps are missing and which assumptions were wrong. That feedback is worth more than any number of workshops, because it is based on doing rather than imagining.
Release to a small pilot group first: one team, one site or one region. Keep the old process available as a fallback while confidence grows. Make it easy for pilot users to report problems, and fix the important ones fast so they can see their feedback acted on. Early users who feel heard become the system’s best advocates when it is rolled out more widely.
Iterate based on real use
Add features based on real use. After the first release, the original wish list should become a starting point, not a contract. Watch how people actually use the system, where they get stuck and what they ask for. Some features on the list will turn out to be unnecessary; drop them. New needs will emerge; weigh them against the rest.
A short cycle helps: release improvements every two to four weeks, review usage and feedback, then decide what comes next. Each cycle should end with a working, usable system, so the business can choose to pause or change direction at any point without being left with something half-built.
Half the features we were sure we needed never got built, because once people used the first version they asked for different things. We spent the budget on what they actually used.
Managing director, facilities services client
Small does not mean careless
A modest scope is not an excuse for low quality. The first release still needs to be secure, reliable and supported, because a bad first impression is hard to undo. Users who lose work or face constant errors will resist the next release, however good it is.
There is also a trade-off to manage with stakeholders. People who were promised a complete system may be disappointed by a narrow first release. Set expectations early: explain that the first version is deliberately limited, show the plan for what comes next and share results from the pilot as soon as you have them.
What this means for leaders
Funding and governance often push projects towards big releases. Budgets approved once for a fixed scope make it hard to change course. A better approach is to fund the first release and a defined period of improvement, then review the results before committing further. That keeps the decision to continue grounded in evidence rather than in the original business case.
If you are about to commission new software, ask the team one question before approving the plan: what is the smallest release that would let one group of users complete one important job entirely in the new system? Make that the first milestone, and judge the project by how quickly it gets there.
Source: Intelliversal analysis.
