Cost of Software in 2026

It is no secret that I live in Slovakia. And living here gives you plenty of opportunities to get angry about how the government spends public money. Today was one of them.

On 8 October 2026, NASES, the state agency under minister Samuel Migaľ’s department, published a signed contract with GlobalTel for approximately €90.4 million to update and operate parts of slovensko.sk. According to Denník N¹, around €66.8 million covers software delivery and €23.6 million covers operations. Much of the technical documentation is unavailable to the public.

I read that and thought: ninety million euros? What exactly are we buying?

I have been building software for fifteen years, ten of them as an architect. I have worked on systems handling payments, sensitive information, large amounts of data, and substantial numbers of users. I know that serious software comes with serious responsibilities. I also know that the invoice covers more than developers writing code. There is analysis, documentation, testing, security, infrastructure, migration, maintenance, and human labour.

But I still cannot wrap my head around this number.

What are we buying?

We are talking about a country of roughly five million people, and a government service whose user experience I find painfully bad. Even ordinary tasks can feel like a fight with the interface. When the service is unavailable, your obligations do not disappear with it. You still have documents to submit and deadlines to meet.

I understand that slovensko.sk includes a lot of infrastructure behind the page we see. Identity management and communication between government systems are important. But when I look at the price and then at the experience people receive, I want someone to explain the connection.

The cost of implementation has changed

Because it is 2026, and the way we build software has changed.

People who could never have built an application on their own can now get something working. Experienced developers can explore alternatives, create prototypes, and automate repetitive implementation work much faster. We also have established products, frameworks, and open-source components for problems that used to require much more custom work.

Authentication, access control, messaging, monitoring, databases. These are mature areas of software engineering. We should be able to explain which parts of a project use existing solutions, which need to be adapted, and which genuinely need to be developed from scratch.

And yes, plenty of the software being generated today is AI slop. I see it too. Producing a lot of code is easy. Producing something useful that people can understand and maintain takes more care. Still, the fact that some output is rubbish does not erase the change happening around us.

A study published in July 2026², using data from Microsoft’s January–April 2026 rollout of Claude Code and GitHub Copilot CLI, estimated that adopters merged roughly 24% more pull requests than they would have without these tools. It was an observational study, and more merged code changes do not automatically mean better software or a 24% reduction in costs. But it gives us a concrete reason to ask why project estimates and delivery methods should stay the same while the tools change this quickly.

If parts of implementation take less effort, where does the benefit go? Does the customer pay less? Do we deliver sooner? Do we use the saved time to improve reliability, testing, and the user experience? Or does the invoice stay the same while we simply produce more code?

That is what I want us to start thinking about when we talk about the cost of software.

Domain knowledge and design matter more

In my view, code production is increasingly becoming a commodity. Getting a standard feature implemented is becoming less of a barrier. That makes domain knowledge and system design even more important.

Someone still needs to understand the actual problem. The rules, the exceptions, the responsibilities, and the consequences of getting it wrong. In a government service, who can act on someone else’s behalf? What makes a submission complete? What happens if someone submits the same request twice, or if a process fails halfway through?

You can generate a perfectly functional implementation of a completely misunderstood process. Someone has to recognise that. Someone needs to know enough about the domain to ask the missing questions and challenge the assumptions before they become part of the system.

Architecture matters for the same reason. A demo where everything works tells you very little about what will happen after years of changes, integrations, outages, and migrations. Can you replace one component without rebuilding everything? Can another supplier maintain it? Can you deploy an update safely? How difficult will the next legislative change be?

Martin Fowler described this problem long before AI in his Design Stamina Hypothesis³. His argument is that neglecting design can make you faster initially, while making future development progressively harder. Good design helps a project keep delivering over time. He presents it as a hypothesis grounded in engineering experience, and it matches the kind of problems I worry about when looking at a long-lived system.

AI makes me take that argument even more seriously. We can now produce questionable implementations faster than ever. We need people who understand the domain, recognise bad assumptions, and make sound design decisions. That expertise is worth paying for. Its value should show up in software that works reliably and does not become a financial nightmare every time something needs to change.

Explain the price

So when I see a €90 million contract, I want to know where the money goes. What is genuinely difficult about this project? Which existing solutions were considered? How were the costs calculated? What will improve for citizens, and what will become cheaper to maintain?

I cannot tell you the correct price from a newspaper article. The people signing the contract should be able to explain theirs. Calling something critical infrastructure does not make every price reasonable. Listing analysis, security, documentation, and operations does not explain how those activities add up to ninety million euros.

Public money, public code

And I want to go further: government software developed with public money should be open source by default, with any exceptions clearly justified.

Publish the code under an open-source licence. Include the documentation, tests, dependencies, and instructions needed to build it. Let independent engineers inspect what we are paying for. Let us examine the architecture, the business rules, the unnecessary complexity, and the quality of the tests.

If we are paying for thoughtful engineering, let people review that work. If we are paying for a mountain of AI slop that nobody properly understands, taxpayers deserve to know that too. Source code alone cannot reliably tell us how much AI wrote, so disclose how AI was used as well. We can then examine the quality of the result and how responsibility for it was handled.

Keep credentials, citizens’ personal data, and private production settings private. Publish the software.

The Free Software Foundation Europe’s Public Money? Public Code!⁴ campaign makes this case: publicly financed software developed for the public sector should be available under a free and open-source licence. I agree. Other suppliers should have the opportunity to understand, maintain, and improve it, and the state should be able to keep its services running without being trapped by one supplier.

Make the price believable

For this kind of money, I expect a service that respects people’s time, works reliably, and can evolve without another enormous bill every time something changes. I expect the people paying for it to be able to examine what they bought.

If €90 million is the right price, explain why. Then publish the code and deliver something that makes the price believable.