What exactly is custom software?
Custom software is software built specifically for your organisation, based on your processes, data and users. This contrasts with a standard package (SaaS, off-the-shelf), where you adapt to the way the vendor thinks the work should be done.
The difference lies not only in the product but, above all, in the way of thinking. With a SaaS package, you ask which functionality you need from a fixed menu. With custom software, you ask what your process ideally looks like and build software that supports it. The question "what does custom software cost?" is therefore harder to answer than "what does this SaaS subscription cost?" With custom development, the answer depends on what exactly you want to build.
In practice we see three types: fully custom development from scratch, custom development on top of a platform (for example, your own application that reuses Salesforce, SAP or a low-code foundation), and custom integrations that join existing packages together into something that works for your situation. Costs vary by type; see the section on cost drivers for more.
Custom software follows your process rather than the other way around. The cost is determined by scope, complexity, integrations, and the requirements you set for quality, security and maintenance.
When is custom development the right choice?
Custom development is not always the smartest choice. A good agency will advise you just as often to not build as to build. In practice we see five situations where custom development adds value over a standard package:
- Your process is your competitive advantage. If you work faster, smarter or more accurately than the market, you don't want to flatten that process into a SaaS template. Then custom development fits.
- No single package covers your reality. You have tried SaaS A, compared SaaS B, and in both cases 30 to 50 per cent of your work still lives in Excel or in someone's head.
- Licence costs are spiralling. With enough users, a per-seat licence adds up quickly. At some point, a one-off build investment plus maintenance is cheaper than continuing to pay the licence.
- You depend on integrations with systems your SaaS does not officially support. Custom development is then often cheaper than the patchwork needed to keep the standard solution running.
- You want ownership of the software and the data. With SaaS you rent functionality. With custom software you own it. That has strategic and financial consequences.
If none of these situations apply to you, a well-chosen SaaS package is probably the better option. We describe a deeper decision model in our article on build vs buy software, a required read before you enter a quoting process.
What drives the cost of custom software?
If you find the answer "it depends" frustrating, here is a more honest one: it depends on a few concrete factors, which we explain below. Two companies that both want "a planning system" can have completely different project costs, sometimes orders of magnitude apart.
1. Scope and complexity of the business logic
A form that fills a database is cheap. A scheduling module that weighs 30 technicians, 200 customers, stock levels, travel times, skills and SLAs against each other to find the best plan is not. The complexity of the logic, rather than the number of screens, accounts for most of the build time.
2. Number and nature of integrations
Every integration with another system brings its own work: authentication, data mapping, error handling, monitoring and version maintenance. An integration with a modern system that has good APIs and documentation is quicker to build than one with a legacy system or a SaaS package that only offers CSV exports.
3. Technical non-functional requirements
Requirements that never appear on a functional design but have a major impact: scalability (can the system handle ten times as many users?), availability (can it be down for 30 minutes overnight?), security (which standards, audit trail, MFA, encryption at rest?), privacy and compliance (GDPR, NEN 7510, ISO 27001, DORA), and performance requirements for certain flows.
4. Team size on our side
More people on a project does not lead to a proportional increase in speed. A team of two senior developers and a designer can often deliver more value than a team of six juniors, because coordination overhead rises sharply in large teams. We prefer to work with small, multidisciplinary teams, which keeps overhead low and quality high.
5. Design and user experience requirements
An internal tool for five employees needs a different level of quality than a customer portal that represents your organisation to the outside world. Investment in user research, prototyping, design iterations and usability testing are choices you make; they deliver proven value for customer-facing applications and are often overkill for narrow internal tools.
6. Lead time and start date
A project you want delivered within a few sprints costs more per delivered feature than one that can be spread over a more relaxed pace. The same applies to projects with hard deadlines: buffers in the schedule cost money.
What does a custom development project involve?
Many cost misunderstandings arise because clients think of "building software" as only programming. In reality, programming accounts for about half the time in a healthy project. The rest goes to work that is just as important to the final result:
- Research and discovery: mapping out processes, speaking with stakeholders, inventorying existing systems, identifying risks.
- UX design and prototyping: screen flows, prototypes, user testing, setting up a design system so that screens stay consistent.
- Technical architecture: decisions on technology, data model, deployment strategy and integration patterns.
- Build: the actual programming, carried out in sprints.
- Testing: automated tests, manual test rounds, user acceptance testing.
- Security and privacy: threat models, code review, sometimes an external penetration test, GDPR approach.
- Deployment and infrastructure: setting up the hosting environment, CI/CD pipeline, monitoring, backups, alerting.
- Documentation: technical documentation for future maintenance and user documentation for your team.
- Training and roll-out: bringing your team along with the new system, change management.
- Maintenance and further development: work continues after go-live; questions arise, small changes are needed, security updates are applied and new requests come in.
A quote that only mentions build hours is not a complete quote. Ask explicitly how the other items have been estimated; if they are not in the quote, they will likely surface later as additional work on your side.
The difference between project budget and sprint budget
There are two fundamentally different ways of managing a budget in a software project, and the difference determines both your risk and your flexibility.
Project budget (fixed price)
The supplier sets a fixed price for a pre-defined scope. It seems safe: you know what you'll pay. In practice, this often leads to one of two outcomes. Either the scope changes during the project (and then there's a discussion about additional work), or the supplier has to stick to the scope (and then you get exactly what was in the document, even if you realised during the build that it should be done differently).
Sprint-based budget
You buy a team for an agreed number of sprints. At the start of each sprint, you decide together with the team what the priorities are. You can steer based on what you saw in the previous sprint. The budget remains predictable (you know what a sprint costs), but the content can grow with your insight.
We prefer to work with a sprint-based budget. Why? Because, quite honestly, at the start of a project we don't know everything we're going to discover along the way. A fixed-price scope forces everyone to decide in month one what the software needs to do in month six, and that rarely holds up. A sprint-based budget keeps control with you, sprint by sprint, with full visibility into what has been delivered and what the next step is worth.
Ask every supplier how they handle scope changes. The answer will tell you more about your future collaboration than any other question you could put in a tender.
Hidden and ongoing costs
Building the software is a one-off investment, but custom software also carries structural costs. If you only look at the build quote, you'll be caught out by surprises later. In any case, budget for the following items:
- Hosting and infrastructure: servers, database, storage, CDN, possibly multi-region. Depends on scale.
- Monitoring and observability: error tracking, performance monitoring, log aggregation. Tools such as Sentry or Datadog carry licence fees.
- Third-party SaaS licences: all the tools your software relies on behind the scenes (email service, payment provider, identity provider, map API, AI APIs).
- Security maintenance: vulnerabilities in dependencies are discovered almost daily. If you don't update them, you're at risk.
- Integration maintenance: when another system changes its API (and it does happen), your integration has to keep up.
- Further development: no application stays as it was delivered for three years. Your business changes, and the software has to keep up.
- Maintenance contract: a supplier who is available for questions, incidents and small changes costs money, but saves you many panicked hours in-house.
A rule of thumb that often comes up in our sector: budget a significant percentage of the build cost each year for maintenance and further development. The exact percentage depends on how large, critical and integration-heavy your application is. We calculate this transparently in every quote, not as a surprise, but as part of the business case.
How do you make quotes genuinely comparable?
Three quotes for the "same" project can differ widely in total price, not because one supplier is expensive, but because the quotes contain fundamentally different things. To compare fairly, at the very least normalise the following points:
- Which discovery and design phase is included? Some suppliers start building straight away. Others spend time on research first. Both are valid, but it affects the price and the risk.
- What level of testing? Is testing automated or manual only? Is an external test round included?
- Security and privacy: is a threat analysis included? A penetration test? A GDPR implementation?
- Maintenance and further development: is this item mentioned, or is it out of scope? Ask for an estimate for the first year after go-live.
- Hosting and licences: is this supplied by the supplier, or do you set it up yourself?
- Ownership rights: who owns the code, the design and the data? Do you get access to your own Git repository?
- Team composition — who will be on your project, how experienced are they, and what roles do they fill? A quote that just says "5 FTE" without a breakdown of roles tells you very little.
- Pricing model — fixed price, sprint budget, time and materials, or dedicated team? Quotes are not comparable when the models differ.
Ask every supplier for the same additional information and compare the answers side by side. You will find that the reasoning behind the price tells you far more than the figure at the bottom of the page.
The four common pricing models
In practice, you will encounter four variants on the Dutch market. None of them is inherently right or wrong; each suits different situations.
| Model | Suits | Risk to you |
|---|---|---|
| Fixed price A fixed price for a predefined scope | A tightly defined, predictable scope. Often used for compliance projects with locked-down requirements. | Scope disputes; little room for insights gained along the way. |
| Time and materials Paying by the hour | Short projects, discovery work, or work where the scope cannot be determined in advance. | No budget ceiling; limited predictability. |
| Sprint budget A fixed price per sprint, with flexible scope | Iterative product development, where you want to adjust course as you go. | Requires active steering; passive clients do not get the most out of it. |
| Dedicated team A fixed monthly rate for team capacity | Longer engagements with several parallel initiatives. | You are responsible for steering and prioritisation yourself. |
For most custom projects, we recommend a sprint budget. It combines predictability (you know what each sprint costs) with flexibility (you steer on content sprint by sprint). For the broader picture of what custom software development involves on our side, and how we put a sprint budget into practice, see our service page.
For related cost questions on other types of project, our articles on how much an app costs to build and how much a website costs to build are also useful reading. For larger organisations considering modernising or replacing internal systems, see enterprise software development, where we cover projects with more stakeholders, compliance requirements and integration complexity.
Frequently Asked Questions
When is custom software cheaper than a SaaS licence?
Typically when the licence costs, added up over a number of years, exceed the cost of building and maintaining the software, or when a SaaS package forces workarounds that take your team more time than they save. The break-even point varies by organisation; as a rough rule, the more specific your process and the more users you have, the sooner custom software makes the business case.
Can we start small?
Yes, and we recommend it. We usually start with a clearly defined first version that delivers value quickly, often covering one critical process, and expand based on what it delivers. This prevents you from spending months building before the first end user sees anything.
What exactly is a sprint budget?
You buy a team for an agreed rhythm, usually two-week sprints. At the start of each sprint, you plan with the team what will be picked up; at the end, we demonstrate the result and plan the next sprint. The cost per sprint is fixed; the content is flexible.
Can we adjust course along the way?
With sprint budget and dedicated team models, adjusting course is built into the way of working. With fixed-price projects, changes are possible but go through a formal change-request process, which is why fixed price is less suitable for projects where you learn what you actually want along the way.
Who owns the code?
You own the code, the design and the documentation we produce for you. We provide access to a Git repository of your own and all related infrastructure. If the collaboration ends, you keep everything you have paid for, with no lock-in to our tooling.
What happens after go-live?
An application is not "finished" once it goes live; users have questions, small changes are needed, security updates arrive and new functionality is requested. We offer maintenance agreements at different levels — from a minimal package covering security and availability to ongoing development with a dedicated sprint team.