Custom software cost: fixed price, hourly rate or subscription?

If it isn't yet clear whether a custom build is the right path at all, read first Build custom software or buy a ready-made tool. This is about the step after that: you want something of your own — and the way you pay for it makes a bigger difference than most people suspect.

Model 1: a fixed-price contract for work

You describe what you need, get a fixed-price quote and pay once. After that the software can be yours — if the contract provides for it. Sounds clean, and in one case it really is:

When you genuinely have to own the code — for legal reasons, because you want to resell it or develop it further yourself.
When the scope stands rock-solid from beginning to end and beyond dispute.

One important caveat up front that many overlook: "the software is yours" stands and falls with the contract. The copyright in the code always stays, legally, with the developer — you only get the usage rights spelt out in black and white. So make sure the contract expressly guarantees you the handover of the source code and the right to change and pass it on. Without those clauses you may end up holding a finished program, but not the code behind it.

The snag hides in the word "fixed price": nobody can predict software effort exactly, so it's estimated generously — the buffer protects the vendor, not you. If it's done faster, you still pay the estimate.

And after handover? Software is never finished — it needs updates, security patches, adjustments. For that there's usually a separate support or maintenance contract, often a monthly or annual flat fee on top of the purchase price. You should factor that in from the start: the one-off fixed price is rarely the end of the costs. Without such a contract every later change is a new quote and a new negotiation.

Model 2: billing by the hour

Here you pay for the hours actually worked. Fairer when the scope is unclear — but with a structural problem you should know about: when effort determines the bill, you pay for every inefficiency. What would be doable in two days can be billed as "two weeks", and as a layperson you can't check it. That needn't be bad faith — it's baked into the model: speed and care aren't rewarded here, they cost the vendor revenue.

Model 3: you subscribe to the result

My path is a third one: you pay neither an estimated lump sum for effort nor counted hours, but a fixed monthly price for an ongoing, working solution. That flips the incentive structure — you pay for a solved problem, not for effort. Whether I need two days or two weeks is my risk, not yours. And because you can cancel anytime, it's my drive to keep it running well for the long haul, rather than going quiet after handover. How it works in detail and what it costs →

The honest downside of my model

To be fair: with me, you don't own the code. You use a running solution that I operate. Your data always belongs to you and you get it cleanly exported on cancellation — but you don't get the source code.

That has a real consequence that speaks for the contract-for-work model: whoever owns the code is independent of the vendor. If you're unhappy with your developer, you can take the code and go to another IT company that maintains and extends it further. You don't have that freedom with me — if you leave me, the solution doesn't keep running without me.

Two honest points on that. First: if the code is poorly documented, a new vendor may prefer to rebuild it rather than take it over — the switch is then rarely as smooth as code ownership promises. With cleanly maintained code, by contrast, the takeover is perfectly ordinary business. Second: my answer to the same risk is a different one — you can cancel anytime, so I have to stay good, rather than binding you to a handed-over state. But if independence through ownership matters more to you than this ongoing responsibility, then the contract-for-work is the right path for you — not me.

Which model fits you?

In short: code ownership or independence from the vendor strictly required? Contract for work — and negotiate the maintenance contract straight away. Scope totally unclear and you just want to try things out? Hourly billing can fit, but with a watchful eye. You simply want your problem solved for good and kept predictable, without standing alone after handover? Then the subscription is made for you.

And don't worry that you'd have to judge this technically: you tell me what should be solved — and I'll be honest with you about which model costs you the least, even when the answer is that another path suits you better.