How to commission custom software: a practical guide for buyers
Ready to commission custom software but not sure where to start? A practical guide covering the process, contracts, costs, and how to pick the right partner.
Commissioning custom software means hiring a development partner to build something specific to your organisation — not buying a product off the shelf, but funding the creation of one. As the buyer, your job is different from the builder's. Knowing what the process involves dramatically reduces the chance of budget overruns, missed expectations, or a system that doesn't deliver what you envisioned.
This guide covers the four questions we hear most from first-time — and not-so-first-time — software commissioners: when does custom actually make sense, how does the specification process work, which contract type fits your situation, and what should you realistically budget?
When does custom software make sense?
The short answer: custom software makes sense when your process is a genuine source of competitive advantage and off-the-shelf tools force you into a generic workflow that erodes it. If the process is standard or likely to change substantially within two years, SaaS is usually the better bet. See our guide on custom software development for a deeper look at when custom software fits and when it doesn't.
The specification process
Most budget overruns in software projects aren't caused by bad developers — they're caused by insufficient specification upfront. Vague requirements produce expensive surprises.
Good specification starts with describing the problem, not the solution. 'We want an app that does X' is not a specification. 'We have 12 people manually running this process through spreadsheets, it takes an average of 3 hours per day, and the errors cost us €4,000 a month in rework' — that is a specification. From that problem description, you build toward a scope.
What a solid specification covers:
- Problem description: who has what problem, how large is it, what are the current costs or risks?
- User roles: who will use the software and what must each role be able to do?
- Core functionality: the features that are genuinely required for the first version — not nice-to-haves.
- Integrations: which existing systems does the software need to connect with or feed?
- Constraints and requirements: hosting, security, compliance, performance, scalability.
- Definition of success: how will you know in six months that the project delivered what it promised?
Many commissioners begin with a discovery phase — a short, paid engagement with the development partner (typically 2–6 weeks, €5,000–€20,000) to define scope together before build begins. This isn't overhead: it creates a shared picture, forces both sides to validate assumptions, and makes the build-phase proposal significantly more accurate.
“McKinsey research found that 45% of all large software projects run more than 45% over budget. The leading cause: insufficient specification in the early stages.”— McKinsey & Company, 2024
Contract types: fixed price vs. time and material
The contract model determines who carries the risk of unforeseen complexity. There are two base models — and a hybrid variant that has become increasingly common.
| Contract type | How it works | Advantage for the buyer | Risk for the buyer |
|---|---|---|---|
| Fixed price | Agreed scope, fixed price. Changes go through formal change requests. | Budget certainty. No open-ended invoice. | Scope freeze: changes are expensive. Supplier may price in risk buffer. |
| Time and material | You pay for actual hours by role. Scope can flex. | Flexibility. You can adjust direction without formal procedures. | No budget ceiling. Risk of scope creep without tight project management. |
| Hybrid: iterative fixed | Fixed price per sprint or phase. Scope locked per iteration. | Combines certainty with flexibility. Regular go/no-go checkpoints. | Requires active buyer involvement each iteration. |
For a well-defined, bounded scope — an internal dashboard, a form workflow, an integration service — fixed price works well. For more complex products where scope evolves as users interact with early versions, the hybrid model is wiser. Pure time and material fits best when you're embedding a supplier as an extension of your own team and you're managing the roadmap internally.
Cost estimates
Custom software projects in the Netherlands typically range from €25,000 for a focused internal tool to €500,000+ for a full platform — with most business applications landing between €75,000 and €200,000. Beyond the build, plan for 15–20% of the project value per year in maintenance and hosting. For a detailed cost breakdown, see our article on custom software costs.
Tips for a successful working relationship
The buyer-supplier dynamic in software projects is one of the most demanding working relationships in business. You're buying something that doesn't exist yet, based on a description of something not yet fully understood. Five practices that make the difference.
- Designate one internal owner. Not a steering committee, not two managers sharing the role — one person who makes decisions, consolidates feedback, and answers the supplier quickly. Delays from internal decision-making are the single most common cause of project slippage.
- Ask for fortnightly demos of working software. Not status reports, not slide decks — working code. You find problems in month two, not month six.
- Treat the discovery phase as mandatory, not optional. A supplier who starts building without shared specification isn't doing you a favour — they're transferring risk onto you.
- Involve end users early. The manager knows what the system should be able to do. The employee who will use it every day knows what it needs to do in practice. Those two things are rarely identical.
- Plan the handover from day one. Who manages the software after delivery? How does knowledge transfer work? What do changes cost after the warranty period? Good suppliers have ready answers to all of this.
The next step.
Commissioning custom software doesn't start with requesting a proposal — it starts with clearly articulating the problem. The sharper you are about what's currently broken and what success looks like, the more useful every conversation with a supplier becomes.
Ready to have that conversation? Describe in a few sentences what problem you're looking to solve. We respond within one business day with an initial estimate or an invitation for a discovery — whichever fits.