What Does Software Development Really Cost? Prices, Drivers & Hidden Costs

What Does Software Development Really Cost? Prices, Drivers & Hidden Costs

"How much does software cost?" is the most common question we hear. And the hardest to answer honestly – not because there are no numbers, but because the question itself already carries the wrong mental model.

A car you buy finished. Software you build together – and it changes the moment you start using it. So you are not paying for a product. You are paying for a decision about how you will work for the next few years.

We are not going to wave a price list at you. We will show you what actually drives cost in our projects, how we tell whether a budget is plausible, and which questions you should have answered before you hire anyone – including us.

Quick orientation

If you need a rough order of magnitude right now – typical ranges from our work over recent years that you can plan against sensibly:

• A marketing website you want to maintain yourself: €6,000 to €18,000
• An internal tool that automates a process: €20,000 to €60,000
• A platform meant to grow over several years: from €80,000, often €150,000 and more

What moves the range is rarely the size of the project – it is almost always the sharpness of the requirement. More on that in a moment.

Three lenses on the same number

Whenever we look at a project, we ask the same thing – through three different lenses.

The business lens. Which concrete bottleneck does the software solve? What is that bottleneck costing today – in hours, in mistakes, in lost revenue? And how quickly does the solution need to pay back for the investment to make sense?

The psychology lens. Who will actually work with the system later? What forces those people into workaround logic in the current setup? Software built without an understanding of habits and reservations ends up in the archive – and then every euro was too much.

The IT lens. Which architecture supports the project without forcing a rebuild in two years? Where will the future maintenance live, where are we keeping our options open for tomorrow?

An honest number emerges from the intersection of these three views. Software that fits the work, holds up technically, and actually gets used is rarely the cheapest – but usually the only version that pays for itself.

Three patterns we keep seeing

In almost every project we look at, the same three places decide the cost. Not abstract "factors" – patterns. They are connected to each other, and they repeat, whether the project is €20,000 or €200,000.

1. "Kind of" costs 40 %

The most expensive day in any project is the one when "kind of" is still allowed between client and us. "Kind of a login area", "kind of a report", "kind of integrated" – those are not requirements, those are placeholders.

In our experience, a project pitched as a €30,000 idea regularly lands in discovery between €40,000 and €50,000. Not because the scope grew – because what was actually meant becomes visible. Interestingly, clients almost always perceive that as cheaper than the original €30,000, because they leave the room with three fewer wrinkles in the fabric.

"A report" can mean an Excel export (two days of work) or an interactive dashboard pulling live data from three systems (three weeks of work). Same sentence, ten times the price. Whoever sharpens at the start, pays clearly less at the end.

2. The second integration costs three times the first

Interfaces look identical on paper – rarely on the invoice. We estimate a first, clean connection to an external system with a clear effort. By the second one in the same project, we regularly see three times the effort.

The reason is not technical, it is organisational. External systems have quirks, downtime, owners with their own plans, old API versions, undocumented fields, rate limits no one mentioned. Every additional interface does not double the code – it doubles the risk. And risk always gets paid for, eventually, by someone.

That is why we ask early on the question that is more honest than "how much code will be written?": how many other systems are talking to it?

3. Three months after launch the real work begins

Launch is not the end of the project. It is the beginning of the learning phase, when you see for the first time what real usage does to your assumptions.

In every project we see the same three items underbudgeted at the start:

Maintenance as value preservation. Software does not age like a car, but it goes stale faster than most people think. Libraries, security updates, new browsers, new OS versions. Our rule of thumb: 15 to 20 % of the build cost per year, just so the system does not start working against you.

Requirements that shift in real use. The first three months after launch are the most expensive learning phase. Plan for them and you can shape them. Ignore them and you pay double in the second year for every follow-up – because post-launch changes cost five to ten times what they would have cost during concept.

Onboarding and accompaniment. Software no one uses was too expensive – regardless of what it cost. Training, documentation, a clear point of contact in the early weeks: not optional polish, but part of the investment.

What you can do before you hire anyone

Three things that will make every quote easier to read:

1. Write down who will use the system, when, and which bottleneck it solves. One paragraph per user group is enough – if it is honest, you have done 80 % of the work a good advisor would do in a first workshop anyway.

2. Ask for a range, not a price. Anyone who quotes a fixed price without having seen your data, processes and interfaces has either guessed wrong – or already priced the wiggle room in.

3. Expect a halving offer. The most honest answer to "what will this cost" is usually: "let us look together at what we can leave out for half the price, without halving the value." Anyone who does not offer that on their own tends to build too much.

My concrete offer

If you are currently thinking about a project and staring at a number that means nothing to you: send me two or three sentences about what you have in mind. I will reply with an honest range and three questions you should clarify first – even if I turn out not to be the right person to build it.

Drop me a line