A good first version contains only what the main flow needs to work for real users, plus data protection, access rights, backups and monitoring. Everything else goes on a list for later. This decision comes before the first line of code and is the most effective one in the whole project. A tight scope gets you to real feedback sooner and protects your budget from features nobody ends up using.
The industry often calls this an MVP, short for minimum viable product. We say first version because it is meant to run in daily use and grow from there. A prototype, by contrast, is there to show an idea and often gets thrown away.
Start from the outcome
Say in one sentence what should be possible after launch, for example: a customer can book an appointment online and receives a confirmation. Anything not needed for that becomes a candidate for later.
Write the sentence from the point of view of the person using the product. "We need a customer portal" describes a solution. "A customer can see their open invoices without phoning us" describes an outcome, and you can test every feature against it.
Three questions for every feature
- Does the main flow work without this feature?
- Can the step be done by hand for now?
- Do we know for certain that someone needs it, or are we guessing?
If the main flow runs without the feature, the step can be done by hand for now, or the need is only a guess, it goes on the list for later. That list is not lost. It becomes the basis for the second version.
An example: online appointment booking
Take the appointment booking from the sentence above as a model case for a service business. The main flow needs these four features:
- Show available appointments
- Choose an appointment and enter contact details
- Send a confirmation by email
- Show your team the bookings in one overview
These features can wait:
- Customer accounts with login, because the email confirmation is enough to begin with.
- Online payment, as long as customers can pay on site.
- A link to your calendar, if the team can copy bookings across by hand for now.
- Reports, until there are enough bookings to report on.
What a first version costs and how long it takes
A first version as a web app can start with the simple tool package at CHF 9'000 – 13'500. A customer portal is CHF 28'000 – 42'000. Every feature you postpone shows up directly in the sums. An integration with ERP or industry software alone costs CHF 9'000 – 13'500 and extends the timeframe by several weeks.
Move that integration to the second version and you launch correspondingly sooner. You still have to pay for it later. By then, though, you decide with experience from live use whether you need it and in what form. The appointment booking in the example can often be smaller still: a website with an embedded booking tool costs CHF 100 – 170 as an add-on.
The figures come from our overview of software prices and guide ranges. The article How much does a web app cost in Switzerland? works through model cases. For custom software, the packages are in the article How much does custom software cost?. The binding quote follows after we talk.
Where not to cut
Even the smallest version has to run safely and reliably. Data protection, access rights, backups and monitoring belong in every version, including the first. Adding them afterwards is more expensive and riskier. The same goes for tests and short documentation, because the second version builds on them.
When the first version has to be bigger
Sometimes it cannot get any smaller. If you are replacing an existing system, the new version has to do everything daily work strictly requires, or your team ends up doing the job twice. Legal or contractual requirements cannot wait for later either. In such cases a step-by-step replacement helps: part of the process moves across while the rest stays in the old system for now.
Three traps when scoping
- Everyone has a say and nobody decides. Name one person who has the last word on scope.
- Special cases creep back in. Put each one through the same three questions as any other feature.
- Shortly before launch someone says "while we are at it". Put the wish on the list for later and keep the launch date.
Measure before you expand
Decide before launch how you will recognise success: fewer phone calls, more sales, shorter handling time. Note today's value while the old process is still running. That way the second version rests on observation rather than assumption.
The next step
If you can state the outcome in one sentence, you have the most important thing for a first conversation. At SIMPLY CODE SOLUTIONS we then decide together what is needed at launch and what can wait. You can request your project directly. Our way of working is on the page web app development. The article Custom software or off-the-shelf? covers whether building your own product makes sense at all.