Hourly Rate or Fixed Price for a Development Project?
Hourly rate is usually cheapest when requirements change during the project, since fixed price carries a 20–40 percent risk markup for the uncertainty. Fixed price suits small, well-defined assignments with stable scope. Middle-ground models like target price, cost caps, and sprint budgets combine predictability with flexibility, and fit most development projects better than either pure model.
The choice between hourly rate and fixed price isn’t really about the price – it’s about who bears the risk when reality deviates from the plan. Understanding that lets you pick the right model, and avoid both runaway hour banks and fixed-price projects that collapse into interpretation disputes.
Incentives drive the outcome – not the price tag
Hourly billing puts the risk on you as the client: if the project grows bigger than planned, you pay more. The agency’s incentives are sound on quality – no one profits from cutting corners – but the pressure to stay within budget has to come from you. The model requires transparency: ongoing time reporting, a demo every sprint, and a client who actively prioritizes.
Fixed price puts the risk on the agency, and the agency acts accordingly. Scope is defended fiercely, every ambiguity is interpreted narrowly, and every change becomes a negotiation. You get predictability in kronor, but you pay for it with rigidity – and with a risk markup built into the price from the start.
Neither model is dishonest. They just answer different questions: “what does an hour of work cost?” versus “what does it cost not to have to know?”
The choice also affects your day-to-day as a client. In an hourly project, you’re involved in prioritizing every week and watch the work take shape. In a fixed-price project, you hand it over – and get back something that matches the spec, not necessarily the need. Fixed price therefore requires better requirements work up front, while hourly requires more engagement along the way. No model lets you skip both.
The built-in risk markup in fixed price: 20–40 percent
An agency quoting fixed price is pricing the uncertainty. Worked example: a project the agency estimates at SEK 500,000 on an hourly basis is quoted as a fixed price of SEK 600,000–700,000 – a 20–40 percent markup.
If the project goes according to plan, you’ve paid SEK 100,000–200,000 for a risk that never materialized. If it runs over, the agency absorbs the difference – or tries to recover it by interpreting requirements narrowly and pricing every change. Note the paradox: fixed price is most expensive precisely when requirements are least clear, since that’s when uncertainty is greatest and the markup highest.
The markup itself isn’t unreasonable – it’s the price of the agency taking on a risk you’d otherwise carry yourself. The only question is whether that particular risk is worth shifting, at that particular price.
The middle-ground models – often the best choice
| Model | How it works | Fits when |
|---|---|---|
| Target price | Joint estimate; overruns and underruns are shared per an agreed formula | Mid-size projects with a decent grasp of requirements, where both parties want to share risk |
| Cost cap | Hourly billing up to an agreed ceiling | You want flexibility but protection against runaway total cost |
| Sprint budget | Fixed amount per sprint; content is prioritized on an ongoing basis | Product development where learnings should shape the content |
| Fixed price per stage | Hourly billing for discovery, then fixed price for well-defined stages | You want predictability without paying for priced-in ignorance |
What the middle-ground models share is that they force a shared picture of the uncertainty. Just the conversation about where to set a target price reveals where you and the agency see risk differently – and that conversation is often worth more than the model choice itself.
How to choose a model
- Small, crystal-clear assignment: fixed price works great – the risk markup is small when the uncertainty is small.
- Exploratory product development: sprint budget or hourly with a cost cap, so new knowledge can shape the content.
- In between: target price or fixed price per stage after a paid discovery phase.
- Regardless of model: demand transparency – time reports, demos, and a clear change process. The pricing model never replaces active ownership from you as the client.
Two common misunderstandings
“Fixed price is risk-free for us.” No – you pay the risk markup regardless of outcome, and the change friction hits exactly when you need flexibility the most.
“Hourly billing is a blank check.” Only without governance. With weekly reports, sprint demos, and defined stop points, you actually have better control than in a fixed-price project, because you see where the money goes while it’s going there.
At Weapp we usually work with staged pricing or sprint budgets, precisely because that aligns incentives for both parties. Want to discuss which model fits your project? Get in touch.
Frequently asked questions
Why won't many agencies give a fixed price without a discovery phase?
Because a fixed price on loose requirements forces the agency to price the unknown – the result is either a high risk markup or future conflicts over what was included. A serious vendor wants to define the assignment first. That protects both parties, not just the agency.
What's a reasonable risk markup in a fixed price?
Typically 20–40 percent on top of the estimated cost, depending on how clear the requirements are and how much is technically untested. The vaguer the brief, the higher the markup. A fixed price with no visible markup often means the margin is recovered through how scope gets interpreted.
Can you switch pricing model mid-project?
Yes, and it's often wise. A common sequence is hourly billing during a discovery phase, fixed price or target price on well-defined stages, and a sprint budget for further development after launch. The model should follow how much you know – not be set in stone.
How do I protect the budget in an hourly-billing agreement?
Combine hourly rate with a cost cap, require weekly reporting of hours worked against budget, and schedule a demo every week or two. Also define stop points where you actively decide whether to continue. Transparency, not the pricing model, is the real protection.
What happens to changes in a fixed-price project?
They're handled as add-on orders with their own price tag, often called change requests. This is where fixed-price projects tend to get expensive: the base price was low, but every deviation from the spec is billed separately. Set the change process in the contract before you sign.