What does custom software cost, and when does it make sense?

What does custom software cost?

That depends on what you need. A small tool for one task costs less than a system for your whole business. An amount without knowing your business therefore says little. What does help: knowing what the costs consist of.

With me, you start with a business analysis, and then you get a proposal with a fixed price. That way you know in advance where you stand. This is what it looks like:

If you go ahead after the analysis, I offset the analysis against the follow-up work. Also read how your price is determined.

Why do you only get a fixed price after the analysis?

Because I first need to know what I am building. Two businesses with the same question often work very differently. One already has a good CRM, the other works in five spreadsheets. A price without an analysis is therefore a guess. That guess turns out too high, or too low.

In the analysis, I visit you, talk to your people and look at your systems and data. After that, you get a short proposal: what can be improved, what it costs and where you start. The proposal is yours, even if you do it yourself or have someone else build it.

When is standard software enough?

More often than you think. Good standard software exists for a lot of work, often as SaaS: you pay a subscription, often per user per month, and the supplier maintains it. A package is usually enough if:

• you work like most businesses in your sector;
• the package does what you need after some configuration;
• you don't need to connect it to many other systems;
• you don't have your own rules that the package doesn't know.

Then I recommend a package. I don't receive commission from suppliers, so I have no interest in which package you choose.

When does custom software make sense?

Custom software makes sense when standard software forces you into workarounds. A few signs:

• Your work is in lists that got out of hand. A spreadsheet that was once handy, but that ten people now work in. Also read Your Excel lists have got out of hand.
• You retype data between systems. Then an integration is sometimes enough, and you don't need to have a whole system built. See You retype the same data.
• Your way of working is your strength. For example your own way of planning or quoting that no package knows.
• A package does nine things well and the tenth not. Then a small tool alongside the package is sometimes the best choice.

So custom software doesn't have to be big. Often it is about one task, connected to the systems you already have. You can read exactly what custom software is in the glossary entry.

What determines the price of custom software?

Mainly the scope: how much the software has to be able to do, and how many systems it talks to. This makes it more or less work:

• The number of tasks and screens. One form with an overview is something different from a system for planning, hours and invoices.
• Users and permissions. Can everyone see everything, or are there roles, such as engineer, planner and management?
• Integrations. Every integration with another system is extra work. How much depends on that system's API.
• Existing data. Do old lists need to be transferred? And do they need to be cleaned up first?
• AI in the software. Does the software read documents or write a first draft? Then checks and usage costs are added.
• Privacy and security requirements. If the software works with sensitive data, that requires more care.
• How clear the work is. If the process is already clear, building is simpler than when it still has to be thought through.

Can you start small?

Yes, and that is often sensible. You first build a first version with only the most important things. That is called an MVP. Your team starts working with it. After that, you know better what still needs to be added. That way you keep the first version small, and you build further on what your team uses in practice.

What costs do you have per month?

Software has to run somewhere and be maintained. That is why there are monthly costs. With me, the software runs on my hosting. I charge three things together in one amount per month:

• Hosting. The servers and the database that hold the software and your data.
• Subscriptions. Services the software uses, such as for sending email. If the software uses an AI model, its provider often charges per amount of text that goes in and out.
• Maintenance. Updates, security, and updating when a connected package changes its API.

We agree that amount together, and it is in the proposal. We also agree there exactly what maintenance covers.

Which costs are easy to forget?

Some costs are not on a builder's quote, but they do belong to it. Think of:

• Your own team's time. For the analysis, the testing and learning to work with the software.
• Cleaning up data. If the same customer appears three times in your lists, that has to be put right first. With me, that is extra work, and I only do it once you agree in writing to the price.
• Wishes that come later. After a few months of working with it, new ideas come up. That is normal. A new wish gets its own proposal.
• Costs from other suppliers. Sometimes access to a package's API comes with a more expensive subscription.

How do you compare quotes for custom software?

Are two quotes far apart? Then they often don't describe the same thing. So don't just look at the amount at the bottom, but compare them side by side on these points:

• What is being built. Which tasks, screens, users and integrations? The more specific the quote, the better you can compare.
• One-off and monthly together. Work out what you will pay over a few years, for the build and for hosting and maintenance together. Do the same for a package, which you often pay per user per month.
• Fixed price or hours. Is the price fixed, or do you pay by the hour? And what happens if it turns out to be more work?
• What is excluded. Transferring and cleaning up data, extra integrations, new wishes: does it say how that works?
• What maintenance covers. Only updates and security, or also small changes?
• Testing and explanation. Do you test with real examples, and does someone explain to your team how it works?

What can you prepare yourself?

The better you know what you need, the more focused a builder can look. You can already do this in advance:

• List the work. What steps are there, who does what and where does it go wrong? You can read how to approach that in mapping processes.
• Make a list of your systems. Which packages do you use, and do they have an API in your subscription?
• Collect examples. A few ordinary cases and a few tricky ones.
• Choose what comes first. What must be in the first version, and what can wait?
• Appoint someone. Who decides, and who tests the software in your team?

Who owns the software when it is finished?

That depends on what you agree. In the Netherlands, copyright in software in principle lies with the maker. So if you have software built by another company, you do not automatically own the code. For that, the copyright has to be transferred by deed: a written document. Without such an agreement, you often only have a right to use the software.

With me, the code and your data belong to your business. If you stop the maintenance, you take them with you. You can then continue yourself, or with another party.

Software usually contains ready-made components from others, such as open source. Those components have their own licence. That is normal, and it is part of how software is made.

This is an explanation in plain language, not legal advice. Record agreements about ownership in the contract.

What happens if the builder stops?

Then you want to be able to continue without starting again. For that you need three things: the code, your data in a usable form, and someone in your team who knows how the software works.

Uniekaiconsultancy is a one-person business. That is why I think this is important. After the build, I explain to someone in your team how the software works. The code and your data belong to you. That way another developer can take over the work if needed.

Which five questions do you ask every builder?

Whether you work with me or with someone else: ask these questions before you sign.

1. Who owns the code and the data, and is that in writing? Ask about the transfer of copyright.
2. What does it cost per month, and what does that include? Hosting, subscriptions, maintenance, small changes?
3. Is the price fixed, and what is excluded? What happens if it turns out to be more work?
4. Where does the software run, and who can access my data? Will I get a data processing agreement?
5. What happens if you stop, or if I stop? How do I get the code and the data?

A good builder has a clear answer to every question, preferably in writing.

How do I work?

The first conversation is free of charge. Then comes the business analysis, and you get a proposal with a fixed price, so you know in advance where you stand. You decide whether I build it. Implementation usually takes 4–6 weeks for one improvement; the schedule is in the proposal. You pay half at the start and half on delivery. After the build, I explain to someone in your team how it works. We sign a data processing agreement for each assignment.

Is it only about two systems that need to share data? Then read what an API integration costs. Read more about custom software and about how your price is determined, or schedule a call.

Frequently asked questions

Sources: Dutch Copyright Act (Auteurswet), Articles 1 and 2 (in Dutch) and Anthropic: use of AI models, charged per amount of text (tokens). Consulted on 7 October 2026.