How we scope fixed-price software projects

We have quoted fixed prices for software projects since the theme shop days, and we still get asked how it can possibly work. Software is uncertain; requirements change; estimates are famously wrong. All true. Fixed pricing works anyway, provided two things hold: the scope is described precisely enough that both sides agree on what done means, and the price honestly includes the risk that we will be wrong. This is how we get there, including the parts clients do not usually see.

Why we price this way

Time-and-materials billing is simpler for an agency, and it is right for some work, such as open-ended research or ongoing product development where priorities shift weekly. But for a defined build, hourly billing moves all the estimation risk onto the client, who is the party least able to judge it. A fixed price moves that risk to us, which gives us a direct incentive to estimate carefully, work efficiently and flag problems early. It also gives the client a number they can put in a budget and defend to their board.

Step one: a short, structured discovery

Most quotes start with a brief that runs anywhere from one paragraph to forty pages. Neither extreme is enough on its own. Within the first day, a senior engineer and a delivery lead read the brief and prepare a list of questions, usually fifteen to thirty, grouped by theme:

• Users and journeys. Who uses the system, and what are the five to ten things they must be able to do on launch day?
• Data and integrations. What systems does this talk to, who owns their APIs, and do those APIs actually exist and work?
• Content and migration. What existing data must come across, and in what state is it?
• Constraints. Hosting requirements, compliance, accessibility standards, browser and device support, deadlines that cannot move.
• What is out. Features the client considered and decided to leave for later.

The last category is the most useful. An explicit out-of-scope list prevents more disputes than any other part of a proposal.

Scope is defined as much by what you agree not to build as by what you agree to build.

Step two: break it into estimable pieces

We break the work into pieces small enough that an experienced engineer can estimate each one with reasonable confidence, typically between half a day and three days. Anything larger is split further or flagged as uncertain. For each piece, we record a likely estimate and a pessimistic one. The gap between the two is as informative as the numbers: a narrow gap means well-understood work, a wide one means we are guessing.

Estimates come from the people who will do the work, not from a sales team, and at least two engineers review the breakdown. When their numbers diverge significantly, the discussion almost always reveals an assumption that needs to be written into the proposal.

Step three: price the risk honestly

The quote is not the sum of the likely estimates. We add three things:

1. Delivery overhead. Project management, code review, QA, deployment and handover, typically 20 to 30 percent on top of build effort.
2. Uncertainty allowance. Derived from the gap between likely and pessimistic estimates, concentrated where the unknowns are, such as a third-party integration we have not used before.
3. Named assumptions. Where a risk is too large to price, we name it as an assumption instead. For example, "the client's ERP exposes an API for stock levels; if it does not, integration work will be re-quoted."

That third category keeps prices honest. It is tempting to absorb every unknown into a bigger number, but that makes the quote uncompetitive and hides the real conversation. A named assumption lets the client resolve the uncertainty, often cheaply, before it becomes expensive.

Step four: change control that does not feel like a trap

Requirements change during every project. Our proposals describe how changes are handled before anyone needs to use the process. Small adjustments within the spirit of a feature are absorbed. Genuinely new work is estimated in the same way as the original scope and either added at a quoted price or swapped for something of similar size that the client is willing to drop. We keep a running log of changes visible to both sides, so the conversation at the end of the project contains no surprises.

Across the last few years, around 85 percent of our fixed-price projects have delivered within the original price plus approved changes, and most of the remainder overran on our side, at our cost. We track those overruns closely because they feed back into how we estimate the next project.

What you should expect from any fixed-price quote

Whether you work with us or someone else, a fixed-price proposal for software should include:

• A feature list written in terms of what users can do, not technical tasks.
• An explicit out-of-scope list.
• Named assumptions and dependencies on your side, such as content, access and decisions.
• A change process with examples.
• Milestones tied to working software, not to hours spent.
• A clear statement of who owns the code, which in our case is always the client.

If a quote lacks these, the price is less fixed than it appears. Our custom web applications and SaaS platform builds are all scoped this way, with the discovery questions sent within a day of receiving a brief.

Send us your brief

Whether you have a detailed specification or a rough idea on half a page, we will read it properly and reply within 24 hours with questions or a fixed-price quote. Share your project with us.