Pay a freelance developer a fixed price when the scope is clear enough to write down and test, and hourly or daily when it is not: maintenance, bug hunting, exploring an idea, working in someone else's code. For most first projects the best answer is a mix: fixed prices per milestone, plus an hourly or day rate agreed up front for anything outside the scope.
Neither model is cheaper in itself. Each one decides who carries the risk when the work turns out bigger than expected, and that is the real choice you are making.
Who carries the risk
| Fixed price | Hourly or daily | |
|---|---|---|
| If the work takes longer | The developer absorbs it | You pay for it |
| What you need before starting | A clear, written scope | A rate and a way to see the hours |
| When the scope changes | A change request and a new price | It just costs more |
| What you can budget | The total, up front | A rate, and a cap if you set one |
| What it quietly rewards | Finishing the agreed thing fast | Thoroughness, and also slowness |
| Typical fit | A defined build with a clear "done" | Ongoing work and unclear problems |
The trade is simple to state. Fixed price moves the risk of overrun to the developer, so a sensible developer prices that risk in. Hourly leaves the risk with you, so you only pay for what happens, but you have to watch it.
When fixed price works
Fixed price works when both of you can read the same document and agree what "finished" looks like. That means:
- A written brief with the features listed, and a line saying what is not included.
- Deliverables you can open and test: a working sign-up, a checkout that takes a test payment, a build on a test device.
- A short acceptance window: you check it within a few days and report problems in one list.
The cost of a fixed price is padding. A developer quoting a fixed sum against a vague brief has to cover everything that might go wrong, and you pay for that cover whether it is needed or not. The clearer the brief, the smaller the padding. How to write a project brief a developer can quote from is the cheapest way to lower a fixed quote.
When hourly works
Hourly (or daily) is the honest model when nobody can know the size of the job in advance:
- Fixing or extending an existing app. Nobody knows what is in someone else's code until they read it.
- Debugging. The bug that takes ten minutes and the one that takes three days look identical from the outside.
- Ongoing maintenance and small changes. A fixed price for "whatever comes up" is a guess.
- Exploration. "Can we add AI search to this?" needs a few days of finding out before anyone can quote the build.
The risk is open-ended spend. That is fixable, and the fix is below.
The mix most projects should use
For a first project with someone new, combine them:
- A small paid first slice at a fixed price. One to two weeks, one defined piece. You learn how they work for a small, known sum.
- Fixed prices per milestone for the main build. Each milestone is something you can open and test, with its own price. Milestone payments covers how to split them.
- A rate for everything outside scope. Agree the hourly or day rate before you start, so a change request is a quick calculation instead of a negotiation.
- Hourly with a monthly cap after launch. Maintenance and small changes, billed as they happen, never above an agreed limit without asking.
This gives you a known total for the part that can be known, and a fair, visible price for the part that cannot.
How to keep hourly from running away
- Set a cap. "Up to 20 hours this week; ask before going over." The developer stops and checks in instead of discovering the overrun on the invoice.
- Ask for a short time log. Date, hours, what was done. Not to police anyone, but so both of you can see where the time goes.
- Look at the work every week. A demo link or a short screen recording. Hours you cannot see turning into progress are the ones that cause arguments.
- Ask for a range up front. Even hourly work deserves a guess: "probably 10 to 20 hours" is useful, and a large miss is worth a conversation.
How to keep fixed price from going sour
Most fixed-price disputes are not about money. They are about what was included. Two habits prevent nearly all of them.
Write the "not included" line. Two sentences at the end of the scope: what is in, and what is explicitly out.
Handle changes in writing, every time. When you ask for something new, the developer replies with the cost and the effect on the date, and you say yes or no before work starts:
Adding Apple sign-in on top of email login is about 2 days at the agreed day rate, and moves the launch milestone by the same. Shall I go ahead?
That one habit is the difference between a fixed price and a fixed price that quietly turns into unpaid work, which is how good freelancers end up resenting good clients. It is the same problem seen from the other side in how freelancers handle scope creep.
A quick way to decide
- Can you write down what "done" means, in a page, so a stranger could test it? Fixed price.
- Is the job working in existing code, fixing problems, or answering a question first? Hourly, with a cap.
- Is it a new build with someone you have never worked with? A small fixed first slice, then fixed milestones, with a rate for changes.
If you want a sense of the size before you ask anyone, the project cost estimator breaks a build into developer-days, which works for both models: it is the scope for a fixed price and the expected hours for an hourly one.