Fixed price or hourly? How to pay for software without surprises
Most fights between business owners and developers are not about code. They are about money: the bill was bigger than expected, or the product was smaller. How you pay decides who carries that risk. Here is how the options really compare.
The risk is real. McKinsey and the University of Oxford studied more than 5,400 IT projects. Large ones ran on average 45% over budget and delivered 56% less value than expected.
Hourly: flexible, but the risk is yours
You pay for the time spent. It is flexible when you don’t know exactly what you want yet, and you can change direction any day.
The catch: if the work takes twice as long, you pay twice as much. Without close tracking, the bill is only known at the end.
Fixed price: predictable, if the scope is clear
You agree on what will be built and what it costs. The developer carries the risk of it taking longer.
The catch: it only works if the scope is written down clearly. Vague scope leads to arguments about what was “included”. Developers also add a safety margin to the price, because they carry the risk.
The middle way: a fixed price per milestone
Split the project into small steps of two to four weeks. Each step has a clear goal, a fixed price, and a demo at the end. You pay for a step when you have seen it working.
- You always know the cost of the next step.
- You can change direction between steps, without renegotiating everything.
- If the partnership isn’t working, you stop after one step, not after six months.
Small steps are the practical answer to those overruns: a problem shows up after two weeks, while it is still cheap to fix, not at the end of a year.
What a good milestone looks like
- You can see it. “Customers can sign up and pay”, not “backend 60% done”.
- It has acceptance criteria. A short list of what must work for it to count as finished.
- It is small. Two to four weeks. Longer steps hide problems.
Red flags, whatever the pricing
- No written scope, or a scope you don’t understand.
- Most of the money paid up front, before anything is delivered.
- The code, domain or cloud accounts are registered in the developer’s name, not yours.
- No regular demos. Weeks pass and you can’t see anything working.
- No clear process for changes. Every new idea becomes a surprise invoice.
How TechNova can help
This is how we work with every client.
- A free call, then a written plan with scope, timeline and a fixed price per milestone.
- Weekly demos you can follow without a technical background.
- An NDA before we start, and you own 100% of the code, domain and cloud accounts.
Book a free 30-minute call or see how we build first products for founders.
Pay a fixed price per small milestone, pay when you have seen it working, and make sure you own everything from day one.
Sources
- McKinsey & Company with the University of Oxford, Delivering large-scale IT projects on time, on budget, and on value (2012): 5,400+ projects; large projects 45% over budget, 7% over time, 56% less value than predicted.
FAQ
What if I want to change something in the middle of a milestone?
Small changes can often be swapped for something of similar size. Bigger ones go into the next milestone, with a price agreed before the work starts.
Is hourly ever the better choice?
Yes, for open-ended work like ongoing support or early experiments, ideally with a monthly cap.
Who should own the code?
You should, from day one, together with the domain, the cloud accounts and the design files.
Read next: Millions of new founders, not enough builders: the MVP gap in the US, EU and Australia