What Custom Software Actually Costs

You get three quotes. One is €12k, one is €24k, one is €44k. All for the same thing. How do you know which one is right?

Short answer: you don't, because you are not buying the same thing. That is where the problem starts — and it is a problem that hits everyone who has ever commissioned custom software.

The hourly rate tells you nothing

The most common comparison metric is the hourly rate. A developer from an outsourcing shop at €30/h looks cheaper than a senior architect at €100/h. But that comparison only makes sense if you know what each of them produces in an hour.

A senior architect designs a data model on day one that handles three years of application growth without a refactor. A developer designs it the way that seems logical to him — and in a year you are paying for a refactor that costs more than you saved on the rate.

The hourly rate is the price of the work. The value of the work is a different thing. You need to know both.

Blended rate: an average that says little

Agencies and larger teams often present a single rate for the whole team — a blended rate. It is an average across all roles. It might be €60/h.

But €60/h as an average of a junior developer at €30/h and a senior at €80/h tells you little about who is actually making decisions on your project. If the architect spent three days on system design and handed the rest to juniors without oversight, you paid an average price for a below-average result.

The right question is not "what is your hourly rate?" It is: who reviews the architecture, who makes the key decisions, and what percentage of that person's capacity do I get?

When SaaS is enough and when it isn't

There is software that is pointless to build. If you need to invoice, send emails, collect forms, or process payments — there is a ready-made product for each of those for a few hundred a month. It makes sense to use it.

The tipping point comes when you need it to work inside your system — not alongside it.

Example: a SaaS solution for e-invoicing within KSeF can issue an invoice. But if that invoice has to be generated automatically from your ERP database, pass through an approval workflow, store the UPO (the government acknowledgement) back into the order record, and trigger an accounting entry — a packaged product will hit a wall. Either it cannot do it, or it can do it with so many compromises that the integration cost outweighs the saving.

The question before any decision: do I need this as a standalone tool or as part of a process? If as part of a process, calculate the integration, not just the licence.

Why fixed-price fails

Fixed-price sounds safe. You know what you will pay. The risk sits with the vendor.

In theory. In practice it breaks at one point: the specification is written after the price is agreed, not before.

The vendor prices the project based on your verbal description. Then they write the specification. And that is where you first discover what each of you meant differently — what data will come from the old system, who approves, what happens on error, what the system must handle in January when ten thousand documents arrive at once.

Every point where the specification differs from the original description is a dispute. Either the vendor absorbs it and cuts corners on quality, or you get a change order. Both are bad.

The solution is to reverse the order. Specification first, then price. This is called a spec-first approach and it is the only way fixed-price makes sense. A specification is laborious to write — but it is the right document to pay for, because then you know exactly what you are getting.

Three pricing models

T&M (time and materials): You pay for hours worked. Transparent, flexible on changes, but with no ceiling. Good when you do not know exactly what you want — or when you know it will change.

Fixed scope: You pay for the outcome, not the hours. Only works when you have a finished specification before you start. Any change mid-project is a new round of negotiation.

FLEX: A less common model, but it makes sense in some situations. You pay in stages or as a share of achieved results — for example, from a saving that is demonstrably attributable to the work. The client owns the code from day one, no vendor lock-in. The vendor has a stake in the outcome, not in maximising hours. Works where the result can be measured.

Each model makes sense under different conditions. If a firm offers you only one — without explaining why — ask.

What the cheaper option actually costs

The cheapest quote is almost never the cheapest project.

The sequence is predictable: fast implementation, no architecture, no tests. It works for a year. Then you add a feature and something else breaks. A new developer arrives, spends three weeks getting oriented, then adds their code next to the old code. After three years you have an application nobody wants to touch because nobody knows what it will break.

Rework will come. The only question is whether in a year or three. And reworking an entire application costs more than doing it right the first time.

Almost nobody does that calculation upfront, because rework is in the future and the saving is now.

What to ask before you sign

A few questions that will save you headaches:

• Who designs the architecture and what percentage of their capacity do I get?
• Do you have experience with this type of integration, or will you be figuring it out for the first time?
• What does the specification look like that you base your pricing on? Can I see it before signing?
• What happens when we discover a new requirement mid-project? How do you handle it?
• Who owns the code and documentation when the project ends?

A good vendor answers these without hesitation. A bad one changes the subject.

---

FAQ

Why do estimates vary so much?

Because everyone is estimating a different project. Without a detailed specification, everyone estimates their own interpretation of what they heard. One includes a simple REST API, another includes full-text search and an audit log. The scope differs, so the price differs. The only path to comparable quotes is to give every candidate the same input — a specification.

When SaaS and when custom?

SaaS makes sense as long as the software exists alongside your processes — as a tool you open, use, and close. Once you need it deeply connected to your ERP, data flows, approval process, or reporting, SaaS hits its limits. Integration costs and design compromises can easily exceed the price of a custom solution. Calculate total cost of ownership over three years, not just the licence.

What is the FLEX model?

FLEX is a pricing model where you pay incrementally — in stages or as a share of a measurable result (time saved, error reduction, automated volume). The client owns the code from the start, which eliminates vendor lock-in. The vendor has a direct stake in the outcome, not in the number of hours. Works where the result is measurable and both sides trust each other enough to agree on the metric upfront.