Fixed Price vs. Hourly: How Development Agencies Actually Quote

With hourly billing, also called time and materials, you pay for the time the team spends. The final cost depends on how long the work actually takes.

With a fixed price, the agency commits to a defined scope for an agreed amount. You know the cost before work starts, as long as the scope stays the same.

Every software project has unknowns. An integration behaves differently than its documentation says, or a design turns out harder to build than it looked. The pricing model decides who pays for those surprises.

With hourly billing, you carry the risk. If a feature takes three times longer than expected, so does the invoice.

With a fixed price, the agency carries it. If it underestimates, it absorbs the difference. That is why a serious fixed quote takes longer to prepare: the agency has to understand the work before it can commit to a number.

Hourly billing is the honest choice when nobody can define the work yet. In those cases a fixed price would be a guess with a safety margin added on top.

• Research and discovery. Exploring what users need or whether a technical approach works.
• Technical unknowns. For example, a startup that needs to test whether a third-party API can handle its data before committing to a product built on it.
• Ongoing work with no fixed end. Maintenance, small improvements and long-term support.
• A team that you direct. When outside developers join your team and you set their priorities, paying for time is the natural model.

Hourly billing also needs something from you: the time and technical background to review hours and reprioritise every week. Without that, the flexibility turns into drift.

A fixed price fits when you know what you need to launch and can describe it, even roughly. Most MVPs and well-defined redesigns fall into this group.

• You have a budget you cannot go over, which is true for most pre-seed and bootstrapped founders.
• You want to compare agencies on the same scope, not on hourly rates that hide different estimates.
• You do not want to manage an agency's timesheets on top of running a company.

If the scope is not clear enough yet, split the project. A fixed-price design and prototype phase turns an unclear idea into a scope that the build can be priced on.

AutoIntel, a B2B tool for the German used-car market, shows why that order works. The interactive prototype let the client settle which fields and filters matter before the data pipeline behind them was scoped.

Yes, if the contract fixes the right things. Martin Fowler argues in his note on fixed price contracts that the problem is not a fixed price but a fixed scope that pretends nothing will change.

The Agile Manifesto puts the same idea in one line: "customer collaboration over contract negotiation". In practice, that means a fixed budget and timeline, a clear priority order for features, and a process for swapping one feature for another.

A good fixed-price agreement is not rigid. It is predictable about money and honest about the fact that plans change.

Scope always changes. What separates a good fixed-price agreement from a bad one is what happens when it does.

A good agreement has a written change process:

• The new request is described in a sentence or two.
• The agency estimates its cost and its effect on the timeline.
• You approve it, swap it for something of equal size, or move it to a later phase.
• Only then does anyone start working on it.

A bad agreement either refuses every change or quietly absorbs them until quality starts to slip. Both end badly, just at different times.

For example, a startup that decides mid-project to add a second payment provider should get a short written estimate within days. Then it can choose between paying for it now and launching with one provider first.

Planning a project and unsure which model fits? Send us a short brief and we will tell you which one we would recommend, and why.

A fixed price is only as good as the document behind it. Before you sign, check that the contract or its scope appendix covers these points:

• The user flows included, written as outcomes you can test.
• A list of exclusions, so there is no argument about what was "obviously included".
• Milestones, what you will see at each one, and the payment tied to it.
• The change process: how requests are described, estimated and approved.
• Who owns the code, designs and accounts once you have paid.
• What happens after launch: a support window for bugs and how further work is priced.

If any of these is missing, ask for it to be added. A serious agency will not mind, because the same clarity protects it too.

Whichever model you choose, tie payments to milestones you can see: approved designs, a working build on a test link, a launch.

Paying everything up front takes away your bargaining power. Paying only at the end makes the agency finance your project. Milestones keep both sides honest, because each payment follows something you can check.

Milestones also give you natural exit points. If the partnership is not working, you can stop between stages instead of losing everything you paid in advance.

Many projects use a mix rather than one pure model. Three combinations come up often:

• A fixed discovery phase, then a fixed build. Design and prototype first, then a price for the build based on what the prototype showed.
• A fixed build, then hourly or monthly support. The launch has a clear scope; what comes after it does not.
• A monthly scope agreed in advance. Support and improvements are planned month by month, so the budget stays predictable without a fixed end date.

The mix should follow how well-defined each part of the work is. Defined work gets a fixed price; open-ended work gets a time-based model with a clear monthly limit.

We quote a fixed scope, timeline and price after a brief. Most proposals go out within 2–3 business days of a completed brief.

Payment is split across milestones: a deposit to start and the rest tied to delivery. We never take 100% before work begins, and our default structure lets you stop between milestones without paying for work that has not started.

If the scope changes mid-project, we re-scope the affected piece and share the cost and timeline impact before continuing. Work after launch runs on a monthly support plan that you can stop at any time.

If you are still sizing the budget, our breakdown of what a SaaS MVP costs gives typical ranges. Once you have proposals in hand, our guide on how to read a development proposal helps you compare them.

Use this as a quick check:

If most of your answers point one way, that is your model. If they are split, divide the project into phases and price each phase on its own terms.

Ready to get a fixed quote? Tell us about your product. We will ask a few questions first, then send a proposal with scope, timeline and price.