Hire a freelance developer on a fixed price when the job can be written down: the pages or features, and what done looks like. Pay hourly, with a weekly or monthly cap, when the work will keep changing, like a product still finding its users. Many projects use both: a fixed build, then capped support.
People often treat this as a question about trust: fixed feels safer, hourly feels open-ended. It's really a question about how much of the job is known. A fixed price on a vague job ends in arguments about what was included. Hourly on a clear job means you carry risk you didn't need to. Below: how each works, which one really costs less, how common projects are priced, how changes and caps work, and what to agree before you sign. It assumes you've already chosen a freelancer rather than an agency.
Fixed price or hourly: the short answer
Choose a fixed price when
The job can be written down
- You can list the pages or features, and what done looks like
- The budget can't move, so you need one number up front
- Design is settled, or simple enough to agree early
- It's a build with an end: a website, a feature, a code review
Choose hourly with a cap when
The work will keep moving
- Priorities will change as you learn from users
- Nobody has read the existing code yet
- It's ongoing: fixes, small changes, support
- You're happy to review hours every week
The cut
Notice that neither list mentions the size of the project. A large website with every page listed is a good fixed-price job. A small feature inside code nobody has read is not. The deciding factor is how much is still unknown, and who pays when the unknowns turn up. If you're unsure, ask the developer to list what they don't know yet. A short list means a fixed price is safe. A long one means start hourly, with a cap, and fix the price once the list is shorter.
How fixed price and hourly billing work
| Fixed price | Hourly | Monthly support | |
|---|---|---|---|
| You pay for | A written scope | Time actually spent | A capped amount of help each month |
| If it takes longer | The developer absorbs it | You pay for it | Extra work waits or is quoted |
| If you change your mind | A change request, priced first | Just ask, and it's billed | It comes out of the month's cap |
| Budget certainty | High | Low, unless capped | High |
| Best for | Websites, features, reviews | Changing products, unknown code | Fixes and small changes after launch |
Monthly support is the third option people forget. It's neither a project nor an open tab: a set amount of help each month for a set price. Mine is $600–1,500 a month for a business website, explained in what maintenance costs.
Is fixed price or hourly cheaper?
Neither, by default. A fixed price includes some buffer, because the developer carries the risk of the job taking longer. Hourly has no buffer, but every surprise lands on your bill. So on a well-defined job, hourly can be slightly cheaper if nothing goes wrong, and a fixed price is cheaper if something does.
A simple example, with round numbers: a job is estimated at 100 hours. On a fixed price, the quote reflects those hours plus a margin for risk, and if the work takes 130 hours, that's the developer's problem. On hourly, you pay for 130. If it takes 90, hourly wins. The honest question isn't which model is cheaper. It's how confident anyone can be about the 100. On a website with every page listed, that confidence is high, so a fixed price costs you very little extra. On code nobody has read, it's low, and a fixed price either carries a big buffer or leads to change requests later.
Where fixed prices really get expensive is a vague scope. The first quote looks low, then every unclear item becomes a change request. That's why the written scope matters more than the model. Price ranges for each type of project are in what a custom website costs and what a web product costs.
Which pricing fits common freelance projects
This is how I'd price the jobs I see most often. The pattern: fix the price on whatever is known, and cap the hours on whatever isn't.
| Project | Best fit |
|---|---|
| A business website with the pages listed | Fixed price, paid by milestone |
| One feature with its details written down | Fixed price |
| A first product version still changing weekly | Hourly with a cap, or cut it to a clear first version and fix the price on that |
| Taking over code nobody has reviewed | Fixed-price review first, then fixed or hourly depending on what it finds |
| Fixes and small changes after launch | Monthly support with a cap, or hourly as needed |
The takeover row is worth a closer look. On The Chat Company, reading the code first showed that only about 20% of an AI-generated demo was worth keeping. That finding set the plan and the price for everything after it. Any fixed price quoted before that review would have been a guess. The full process is in what a takeover costs.
How change requests work on a fixed price
Every project changes a little. A fixed price handles that with change requests, and a good process keeps them from turning into arguments:
- You ask in writing. An email or message is enough.
- The developer replies with the impact. Extra cost, extra time, or a swap for something else of similar size.
- You approve before work starts.Nothing is billed that you didn't agree to.
- The scope document is updated. So everyone is still working from the same page.
Swaps are underrated. If you want a new feature, ask what could come out to make room for it. Often the answer keeps the price and date the same. And small wording or layout tweaks shouldn't need a formal request at all: agree up front what counts as small, so neither side feels nickel-and-dimed. One more habit helps: collect non-urgent requests in a list and review them together once a week. Seeing them side by side makes it easier to decide which are worth paying for now and which can wait until after launch.
How to keep hourly work under control
Hourly work goes wrong when nobody is watching the hours until the invoice arrives. Five habits prevent that:
- A cap.A maximum per week or month. When it's reached, work pauses until you decide.
- A weekly summary.Hours spent, what they produced, and what's next, in a few lines.
- A ranked list. You set the order of work, so the most valuable things get done first if hours run short.
- Estimates per task. Rough, but agreed before anything big starts.
- A review point.Every few weeks, decide whether to keep going hourly or fix the price on what's now clear.
With these in place, hourly is not an open tab. It's a budget you spend in small, visible pieces, which suits work where the next step depends on what the last one showed. The weekly summary also protects you if the developer ever leaves: you have a written record of what was done, what's half-finished, and why.
How payments are usually split
Fixed-price projects are usually paid as a deposit, then in stages tied to milestones like approved designs, a working preview, and launch. Hourly work is invoiced weekly or every two weeks, against the hours summary. Monthly support is paid at the start of each month.
Two rules protect both sides. Never pay 100% up front: once everything is paid, you have nothing left to hold the timeline to. And don't expect a developer to work weeks with nothing paid: a deposit shows you're committed and lets them reserve the time. Tie each payment to something you can see and check, not to a date on the calendar. If a milestone slips, the payment moves with it, and neither side has to argue about whether the work was really done. For hourly work, ask for invoices that match the weekly summaries, so every line can be traced to something you saw.
What to agree before you sign either
Whichever model you pick, get these in writing. They turn a price into an agreement both sides can hold to:
If a developer won't put these in writing, the pricing model won't save you. A short agreement that covers all seven is worth more than a long contract that skips the scope, because the scope is where almost every freelance dispute starts. The rest of the vetting questions are in what to ask before hiring a developer. Or send me your two quotes, and I'll tell you which model fits the job and what each quote is missing.
