The pricing model is one of the most consequential decisions in a developer engagement, and it's almost always made carelessly. Founders pick fixed-price because it "feels safe." Developers prefer hourly because it transfers risk. The wrong choice from either side produces friction throughout the project, and the right choice is determined by specific properties of the work — not by which feels more comfortable.
Three pricing models dominate freelance and small-agency work: hourly, fixed-price, and monthly retainer. Each has a situation where it's clearly correct and a situation where it's clearly wrong. Picking the right model for your specific situation often saves more money than negotiating the rate.
Hourly: pay for time, transfer scope risk to yourself
You pay the developer's hourly rate for hours actually worked, tracked and reported.
When hourly is right
The scope is genuinely unclear. If you don't know exactly what V1 should be, hourly is the only honest model. Fixed-price requires both sides to agree on scope; if you can't agree on scope, you can't fix the price.
You're rescuing or evolving an existing project. Codebase rescues, performance fixes, ongoing improvements — these are hourly by nature. The work is "open the codebase, find the problem, fix it" — you don't know how long it'll take until you start.
The relationship is exploratory. First few hours of working together. Both sides need to feel out whether they fit before committing to a larger arrangement.
You can review work weekly. Hourly works when you're paying attention. The developer reports what they did each week; you read it and provide direction for the next week.
When hourly is wrong
You can't review weekly. If the work happens in a black box and you only check in monthly, hourly billing becomes "trust me, I worked these hours." Some developers are honest about this; some aren't. Either way, you've lost the feedback loop.
The scope is genuinely fixed. If you know exactly what you want and the developer can scope it accurately, hourly transfers scope risk to you for no good reason. Fixed-price would be cheaper because the developer absorbs scope risk in their estimate.
You're prone to scope creep. Hourly means every "small change" you request gets billed. Founders prone to mid-project changes find their hourly bills mounting beyond what they expected.
What you should pay
Hourly rates by tier, in 2026:
- Junior offshore: $5–15/hr
- Mid-level offshore: $20–40/hr
- Senior offshore: $50–80/hr (this is where my own work sits, at the bottom of the band)
- Top-tier offshore (Toptal level): $80–150/hr
- Mid-level onshore (US/UK/AU): $75–125/hr
- Senior onshore: $125–200/hr
- Specialist consultant: $200–500/hr
The right rate depends on the complexity of the work, not the prestige of the rate. Pay for the level of skill the work needs, not the highest-status option.
Fixed-price: pay for outcome, transfer scope risk to the developer
You pay a single agreed price for a clearly-defined deliverable, regardless of how long it actually takes.
When fixed-price is right
The scope is genuinely fixed. Both sides have a written brief, both agree on what "done" looks like, both have visibility into the implementation path. The developer can quote with confidence because there's no ambiguity.
The deliverable is one clear thing. "Build me a marketing site with these 8 pages, this design, these forms" — perfect for fixed-price. "Build me a SaaS" is not.
You're risk-averse on cash flow. Fixed-price means you know the total cost upfront. If your runway is tight, this predictability is valuable.
You won't request mid-project changes. This is critical. Fixed-price assumes the scope doesn't change. Mid-project changes void the assumption and require renegotiation.
When fixed-price is wrong
The scope is unclear. Fixed-pricing unclear scope is how disasters happen. The developer pads the price by 50–100% to absorb scope risk; you pay the padded price; mid-project the scope is found to be unclear; both sides are unhappy.
You're prone to changes. If you request changes mid-project (most founders do), fixed-price agreements either need expensive change orders or get thrashed into informal hourly arrangements where neither side is happy.
The work is exploratory or research-heavy. Some work — performance tuning, debugging, exploratory architecture — can't be honestly fixed-priced because the developer doesn't know what they'll find. A fixed-price for this kind of work is either over-priced (developer protects themselves) or under-priced (developer absorbs the loss).
The 30–50% padding nobody talks about
Honest fixed-price quotes contain 30–50% padding above what the developer actually thinks the work will take. Why: the developer is absorbing all the scope risk. If the project takes 1.3x longer than expected (which it usually does — see why developer estimates are wrong), the developer is on the hook for the overrun, not you.
The padding is rational. Without it, fixed-price work is a money-loser for the developer over time. You pay slightly more on the smooth-case projects so the developer can absorb the bumpy-case ones without going broke.
The implication: fixed-price is more expensive than hourly for the expected case, but cheaper for the bad case. If you're confident the scope is solid and the developer is senior, hourly will be cheaper in expectation. If you're worried about overruns and want predictability, fixed-price's premium is worth paying.
How fixed-pricing should be structured
A clean fixed-price arrangement:
- 30–50% deposit upfront (covers the developer's risk if you cancel mid-project)
- Milestone payments tied to specific deliverables (each milestone is reviewed and accepted before the payment releases)
- Final 30% on launch and acceptance (with a defined acceptance criteria)
- Change orders for any mid-project additions (priced separately, signed by both sides)
Avoid: "$15,000 due on completion" structures where the developer takes all the risk and gets nothing until the end. Either the project succeeds and they're paid late, or it fails and they're paid not at all. Even senior developers won't sign these terms without significant premium pricing.
Retainer: pay for capacity, transfer flexibility to both sides
You pay a fixed monthly amount for a set number of hours per month, used flexibly across whatever work the founder needs.
When retainer is right
The work is steady but variable in shape. A solo founder who needs 15 hours of dev work some months and 5 hours of EA-style work other months. The retainer handles both without renegotiating.
The relationship is long-term. Past 4–6 months of working together, retainer becomes the cleanest arrangement. Both sides have predictability; neither side has to renegotiate every month.
The founder values response time. Retainer clients usually get faster response times than ad-hoc clients because they're contractually allocated. If you want a developer who responds within hours instead of days, retainer is the way.
The cost is predictable for budgeting. Same monthly invoice every month. Easy for accounting, easy for cash flow planning, easy for tax filing.
When retainer is wrong
You don't know if you'll have steady work. Retainers require enough recurring work to justify the monthly minimum. If you're occasionally going to need help, hourly is cleaner.
You're testing a new developer. Don't go straight to retainer with an unknown developer. Start hourly, see if the relationship works, then graduate to retainer once trust is established.
The work is project-shaped, not maintenance-shaped. A clearly-defined 80-hour project should be fixed-price, not 4 months of retainer.
The retainer math
The Lead Steer retainer I offer is $500 USD/month for 10 hours, or about $50/hour effective rate. That's the same as my hourly rate — there's no per-hour discount on the retainer itself.
The savings are in the soft costs:
- No re-negotiating per task. The hours are pre-allocated; tasks just go on the queue.
- Faster response times. Retainer clients get same-day or next-day response. Ad-hoc clients sometimes wait several days.
- Roll-over of unused hours. Up to 50% rolls into the next month, so monthly variation is absorbed.
- Predictable overflow. Hours beyond the monthly cap are billed at the same $50/hr ad-hoc rate, so the monthly cap is a soft cap, not a punitive cliff.
For a founder who'd otherwise hire ad-hoc 15 hours/month, the retainer is cheaper in soft costs and faster in response. For a founder who'd hire ad-hoc 3 hours/month, the retainer is over-priced and the wrong choice.
A decision framework
If you remember nothing else from this article, the decision framework:
| Situation | Best model | Why | |---|---|---| | Scope unclear, exploratory | Hourly | Honest pricing for unclear work | | Scope locked, clearly-defined deliverable | Fixed-price | Predictable cost, transfers risk | | Steady multi-month work | Retainer | Predictability + faster response | | Codebase rescue / debugging | Hourly | Can't be honestly fixed-priced | | First engagement with new developer | Hourly | Test the fit before committing | | Marketing site or specific feature | Fixed-price | Clear scope, clear deliverable | | Ongoing maintenance and small features | Retainer | Variable shape, predictable volume | | One-off small task | Hourly with a cap | Clean and simple |
How to switch models mid-relationship
A common pattern: you start hourly, the relationship works, you want to graduate to retainer. How to do this without friction:
- Look at the actual hours data. What were your average monthly hours over the past 3 months?
- Pick a retainer size slightly above the average. If average was 6 hours/month, the 10-hour retainer might be right. The buffer protects you from busy months.
- Discuss with the developer. They'll often be happy to formalise into a retainer because it gives them predictability. Negotiate the start date and any roll-over terms.
- Convert the existing arrangement. New month, new model. The previous hourly invoices stand; the new retainer starts cleanly.
The reverse path (retainer → hourly) sometimes makes sense when work patterns become unpredictable. Same approach: discuss it openly, agree on the transition, restart cleanly.
What to do next
Once you've picked the pricing model, the next decisions are about working together day-to-day. See:
- Working With Your Developer Without Becoming a Project Manager
- Why Your Developer's Quote Will Be Wrong
If you'd like to talk about the pricing model that fits your specific situation, the first call is free — see the SaaS Startups, Bootstrappers, or Lead Steer Retainer service pages.
---
Part of the Full-Stack Development for Solo Founders pillar guide.