How custom software actually gets built
Having custom software built runs in five phases and gives you a first working version after 8 to 16 weeks. Budget €8,000 to €75,000 depending on scope. Most of the outcome is decided before a single line of code exists: in what you prepare and in how tightly that first version is scoped. Below is the whole route. The phases, your own homework, the real timeline and the places where it goes wrong.
How does a project run from start to finish?
In five phases. These are the timelines you can expect on an average SME project.
| Phase | What happens | Duration |
|---|---|---|
| 1. Intake and scoping | Which problem you solve, for whom, and what belongs in version one | 1 to 2 weeks |
| 2. Design and clickable walkthrough | The screens, as a clickable model you can try out | 1 to 2 weeks |
| 3. Building | Every week a working version you can open yourself | 4 to 10 weeks |
| 4. Testing with your own people | The colleagues who will use it daily do their real work in it | 1 to 2 weeks |
| 5. Live and adjusting | Rolling out, and refining over the first weeks on what you see in practice | ongoing |
Phase 3 is the one to understand. You see a running version every week, never a status report. That sounds like a detail, and it is the difference between correcting course in week three and discovering in week twelve that you meant something else.
The clickable walkthrough in phase 2 does the same job one step earlier. You click through your own future software before anything is built. Whatever jars there takes an hour to change. The same problem surfacing after the build costs days.
What do you prepare before you start?
Four things, together about half a day of work. They are also the four things a project stalls on when they are missing.
The process as it actually runs today. Not the version from the procedure manual. The version with the spreadsheet Marc keeps, the WhatsApp group of the team leads and the form everybody skips. Those exceptions are the work.
One decision maker. Someone on your side who can settle a question without calling three people first. Projects running on two or three opinions overrun structurally.
Access to your data. Your accounting package, your ERP, the existing spreadsheets. Who manages the logins and how long such a request takes at your company is a question better asked now than in week six.
A list of what version one does not need to do. This is the hardest one and it pays back the most. Every feature you keep out of version one is time that goes to the core.
How long does it really take?
Eight to sixteen weeks to a first working version, for a well-defined project. Larger platforms with several user groups and many integrations run to six months or longer.
The overrun rarely sits in the building itself. It sits in waiting. Waiting on a decision about a screen, on access to a system, on someone freeing up time to test. On projects that overrun, our experience says it is about calendars more often than about technology.
Want to go live sooner? The shortest route is almost always building less. Shipping an MVP first and expanding afterwards puts you in front of real users months earlier.
What does it cost?
Between €8,000 for a well-defined tool and €75,000 or more for a full platform. The price follows four things: the number of screens and user roles, the complexity of the logic, the number of integrations and the pace. Those ranges and what sits behind them are worked out in what custom software costs in 2026.
If you are a Flemish SME, look at the kmo-portefeuille before you sign. It takes a solid chunk off the invoice and the application has to happen before the start.
Where do projects go wrong?
On scope and decisions, almost never on the technology. McKinsey, together with the University of Oxford, studied more than 5,400 IT projects and found that large projects run 45% over budget and deliver 56% less value than promised. Every extra year of runtime adds an average of 15% to the overrun.
Those figures deserve a caveat: the research looked at projects with a starting budget above 15 million dollars. An SME project of €30,000 is a different animal. You do recognise the pattern at small scale, and it is exactly why a short first version removes so much risk.
The three ways it goes wrong in practice:
- Too much in version one. The classic case. Everything has to be in it, so nothing is finished by the time the budget runs out.
- No owner on your side. Without someone deciding and testing, the supplier builds on assumptions. Those always surface, only too late.
- Integrations tested only at the end. The connection to your accounting or ERP holds the most surprises. It belongs in week two, not in week ten.
When should you leave custom software alone?
More often than you would think. Four situations where we advise against starting:
- A standard package covers 80% or more of what you need. Buying is faster and cheaper then. Where the line sits is worked out in custom software or a standard package.
- Your process still changes every month. Software fixes a way of working in place. Do that once the way of working has settled.
- Nobody on your side has time. Budget half a day a week from someone who knows the process. If that person does not exist, postpone.
- The problem is really an agreement. Some things get solved with a clear agreement or a better manual. That costs you nothing.
If you are in the situation where separate spreadsheets are bursting at the seams, that is a classic reason to build. What that step looks like is in replacing Excel with custom software.
Not sure if your case is worth it? Put it to us. We look at your process together, give you a realistic range and an approach. Sometimes the conclusion is that you are better off waiting a while, or that an existing package gets you there faster. You will hear that from us too.
Frequently asked questions
- How long does it take to have custom software built?
- Count on 8 to 16 weeks to a first working version for a well-defined project. Larger platforms with several user groups and many integrations run to six months or longer. The overrun rarely sits in the building itself. It sits in waiting on decisions, system access and people freeing up time to test.
- What do I prepare before the project starts?
- Four things, together about half a day of work. The process as it actually runs today including all its exceptions, one person who can settle questions, access to your existing data and systems, and a list of what version one specifically does not need to do. That last one pays back the most.
- How do you recognise a good custom software builder?
- By what they ask before quoting a price. A good builder wants to see your process, asks about your exceptions and dares to cut features from version one. Ask as well for a fixed price with a date, for weekly working versions, and about who ends up owning the code.
- What happens after the software goes live?
- The first weeks you refine on what you see in practice, because users always do things nobody anticipated. After that comes maintenance: updates, small changes and new features as your process shifts. Agree beforehand on who does that, what it costs and who owns the code.
- When should you leave custom software alone?
- When a standard package covers 80% or more of what you need, because buying is then faster and cheaper. Also when your process still changes every month, when nobody can free up half a day a week, or when the problem can really be solved with a clear agreement.