Fixed price vs hourly for web projects: which protects you?

A fixed price protects you when the scope is written down and unlikely to change: a company website with a known page list, a defined design process and a launch date. Hourly billing protects you when the scope is still forming: a web app where the second month's features depend on what the first month taught you. Pick the wrong one and the price looks fine on paper but the project fights you the whole way.

The question in the title has a less obvious answer underneath it: neither model protects you if the scope document is weak. The pricing model decides who pays for surprises. The scope decides how many surprises there are.

What does each model actually mean?

Fixed price. The studio quotes one number for a defined list of deliverables. Payment is tied to milestones, typically a deposit, a payment at design approval and the balance at launch. If the work takes longer than estimated, the studio eats the difference. If you ask for something outside the list, it is a change request with its own price.

Hourly, or time and materials. You pay a rate per hour or per day for the work done, plus third-party costs such as hosting, paid plugins or stock images, passed through at cost. The studio estimates the total but does not guarantee it. You can change direction at any time, and you pay for the time that takes. Most sensible contracts set a budget cap that cannot be crossed without your sign-off.

Retainer. A fixed monthly fee for a fixed block of hours or a fixed level of capacity. This is hourly with a predictable bill, and it is how we run a dedicated development team for clients with an ongoing backlog.

As of October 2026, hourly rates we see for competent web development range from ₹1,500 to ₹4,000 an hour in India and $75 to $200 an hour in the US and UK, with Gulf-based studios somewhere between. If you are on the other side of the table and setting your own rate, our hourly rate calculator works it out from your target income and billable hours.

Who carries the risk under each model?

This is the real difference, so it gets a table.

Read the table from the client's side. Fixed price moves the risk of a bad estimate onto the studio, which is why studios add a buffer and why they write tight scope documents. Hourly moves it onto you, which is why you need a cap and weekly visibility of hours.

When is fixed price the right choice?

Fixed price works when three things are true.

1. The deliverables can be listed. A sitemap with page names, a feature list with yes or no beside each item, a set of integrations with their documentation available.
2. The process is standard. The studio has done this kind of project many times and knows where the time goes. Company websites, WordPress builds, store setups and landing pages fit. A good website brief makes all of this possible.
3. You can make decisions on schedule. A fixed price assumes you will approve designs in days, not weeks. Most fixed-price contracts say so.

This describes most company websites, which is why we quote website design and development at a fixed price with milestone payments. The client gets a number they can put in a budget. We get a scope we can plan around.

The failure mode is a scope written loosely enough that both sides read it differently. "Contact form" is clear. "Integration with our CRM" is not, until someone has checked which CRM, which fields, and whether the API supports what you want. A fixed price on an unchecked integration is a guess with a signature on it.

When is hourly the right choice?

Hourly works when the scope cannot be known in advance, or when fixing it would be worse than leaving it open.

• Discovery and prototyping. You know the problem but not the solution. Two or three weeks of hourly work to produce a prototype and a scope document, which then gets a fixed price.
• Products that change as they are built. A web app or SaaS MVP where user feedback after the first release should change what gets built second. A fixed price here means either paying for change requests every week or shipping features you no longer want.
• Ongoing work after launch. Content changes, small features and fixes do not have a scope; they have a queue. A retainer or hourly arrangement fits.
• Rescue work. Fixing somebody else's codebase, where nobody knows how deep the problems go until a developer is inside it.

The failure mode is obvious: a meter that runs with no cap and no visibility. Protect yourself with a budget ceiling in the contract, a weekly summary of hours, and a defined point, such as a prototype or a milestone, at which you review and decide whether to continue.

What is the hybrid, and why do most good studios use it?

The common pattern is a paid discovery phase billed hourly or as a small fixed fee, followed by a fixed-price build, followed by a monthly plan for support.

Discovery produces the scope document, the sitemap or feature list, and the technical decisions. Because the studio has done the thinking, the fixed price that follows has a smaller buffer and fewer change requests. Because you paid for discovery separately, you can take the scope document to another studio if the relationship is not working. That is a genuine protection, and a studio that refuses to let you do that is telling you something.

As of October 2026, a discovery phase for a company website runs from a few hours to a few days; for a web or mobile app it is usually one to three weeks. Our project timeline estimator gives a rough shape of the phases for a project of a given size.

What should be in the contract regardless of model?

Four clauses do most of the protecting, and they belong in both fixed-price and hourly agreements.

• A change request process. What counts as a change, how it is priced, and that nothing starts without written approval.
• Milestones with acceptance criteria. For fixed price, what "design approved" or "launched" means. For hourly, the review points.
• A cap or a kill clause. For hourly, the budget ceiling. For fixed price, what happens if either side wants out at a milestone.
• Ownership on payment. Domain, content and code are yours once the invoice is paid. Say it in the contract.

The post on what a website contract should include goes through each of these with wording you can ask for.

How to decide in one minute

Answer two questions.

Can you write every deliverable on one page today, and would a stranger read it the same way you do? If yes, ask for a fixed price with milestones.

Will the first month of work change what you want in the second month? If yes, ask for hourly with a cap and a review point, or a short discovery phase followed by a fixed price.

If you are not sure what any of the deliverables cost in the first place, the figures in how much a website costs give you the ranges to sanity-check any quote against, whichever model it uses.