Before any code gets written, someone has to decide how the work will be paid for. Most software projects are priced one of two ways: a fixed price for a defined result, or an hourly (or daily) rate for time spent. Neither is always better. Each one moves risk to a different side of the table.
Knowing who carries that risk, and what each model quietly encourages, helps you pick the right one and write a contract that protects you either way.
How each model shifts risk
With a fixed price, the developer agrees to deliver a defined scope for a set amount. If the work takes longer than expected, that's their problem. If you want something that wasn't in the scope, it's a change, and changes cost extra.
With hourly billing, you pay for the time actually spent. If the work takes longer, you pay more. If priorities change halfway through, you can redirect the work without renegotiating anything.
- Fixed price: the developer carries the risk of underestimating. You carry the risk of a scope that doesn't match what you actually need.
- Hourly: you carry the risk of the work taking longer. The developer carries very little risk at all.
This is why fixed prices are usually higher than the hourly estimate for the same work. The developer is pricing in a buffer for the unknowns they're agreeing to absorb.
When fixed price fits
Fixed price works when the work can be described clearly before it starts. The clearer the description, the fairer the price and the fewer arguments later.
- A defined feature set with screens or flows you can point at.
- An audit or review with a clear list of what gets checked.
- Fixing a known list of problems in an existing app.
- A first version of a product where you're willing to cut scope to hit a date.
It's also the better choice when you can't evaluate technical work yourself. You don't need to judge whether forty hours was reasonable for a login screen. You only need to judge whether the login screen works.
When hourly fits
Hourly works when the work is genuinely open-ended or you expect it to change often.
- Ongoing improvements where next week's priority depends on this week's user feedback.
- Investigating a bug or performance problem whose cause is unknown.
- Exploratory work, such as testing whether an idea is technically possible.
- Long-term maintenance with small, unpredictable requests.
Hourly needs trust and visibility. If you can't tell whether the hours are well spent, you're relying entirely on the developer's honesty and efficiency.
The traps in each model
Fixed price can go wrong when the scope is vague. A developer who underpriced may cut corners on things you didn't specify: tests, error handling, security, documentation. Every unclear line becomes a debate about whether it's "in scope".
Hourly can go wrong when no one is watching the total. Small requests add up, estimates drift and there's no natural point to stop and ask whether the project is still worth it. Slow work also earns more, which isn't a great incentive even with honest people.
Middle grounds that work well
You don't have to pick one model for the whole relationship. Many good arrangements mix them.
- Fixed-price discovery first. Pay a fixed amount for a short phase that produces a clear scope, then price the build from that scope.
- Small fixed-price phases. Break a big project into one- to three-week chunks, each with its own scope and price. You can stop or change direction between chunks.
- Hourly with a cap. Agree an hourly rate but a maximum per week or per task. Going over the cap needs your approval first.
- A monthly retainer for ongoing work. A set number of days or a set availability each month, which keeps costs predictable while leaving room to change priorities.
Contract terms that protect you either way
Whichever model you choose, these terms matter more than the pricing itself.
- You own the code and every account (hosting, domain, database, app stores) from day one, in your name.
- Acceptance criteria: a written definition of "done" for each deliverable, so there's no argument at handover.
- A change process: how new requests are estimated, approved and billed before work on them starts.
- Regular visibility: a weekly update and access to the code repository, not just a demo at the end.
- Payment tied to milestones, not paid entirely upfront.
- A clear exit: how work in progress, code and credentials are handed over if either side ends the agreement.
A quick way to decide
Ask yourself one question: could you write down, today, what "finished" looks like? If yes, ask for a fixed price. If no, either pay for a short fixed-price phase to figure it out, or choose hourly with a cap and weekly check-ins.
And whatever the quote, compare what's included, not just the number. A cheaper fixed price that leaves out testing, deployment and a handover isn't cheaper.
Deeraf prices Tech Checks and Build Sprints at a fixed price agreed before work starts, and uses On Call for ongoing work where priorities shift month to month.