What is the main difference between a fixed-price project and a retainer?

A fixed-price project sets one price for one defined set of deliverables, agreed before the work starts. A retainer pays for a set amount of time or capacity each period, usually a month, and the work inside that time can change as priorities change. The first assumes you know what you are building. The second assumes you do not know all of it yet, and that is fine.

How do I know if my project is specified enough for a fixed price?

Ask whether you could hand a written description of every screen, every rule, and every unusual case to a new team member and have them build the right thing without asking you a question. If the answer is yes, the work is specified enough. If you are still discovering requirements by watching users, or if the underlying product decision has not been made yet, the work is not ready for a fixed price.

Is a fixed price always cheaper than a retainer?

No, and comparing the two on price alone is a mistake. A fixed price moves the risk of the unknown onto the team building it, so if it takes longer than planned, the price to you does not change. A retainer moves that risk onto you, but it also removes the extra cost that unknown work adds to a fixed quote, because nobody has to price in a margin for surprises that may not happen.

Why does a fixed price get expensive when requirements are not clear?

Because the team pricing it has to protect itself against everything it does not yet know, and the only way to do that under a single number is to add a margin for the unknown. The less defined the work, the bigger that margin has to be. You end up paying for risk you may never have created, or the team pays for the risk itself and the relationship breaks down at the first change order.

What is the cone of uncertainty and why does it matter for pricing?

It is a well documented pattern in software estimation: an estimate made at the first concept stage can be off by a factor of four in either direction, and that range only narrows once real decisions about the product have been made. It matters for pricing because it tells you exactly when a number is trustworthy enough to fix, and when fixing it is just guessing with confidence.

Can a project start as a retainer and switch to fixed price later?

Yes, and this is often the right structure for a new build. Early discovery and the first working version run as a retainer, because the goal is still being worked out. Once the goal is stable enough that you could write it down and hand it to someone else, the next phase can be quoted as a fixed price with confidence on both sides.

What is a hybrid pricing model and when should I use it?

A hybrid model fixes the price for the parts of the work that are well defined and keeps the rest on retainer or time-based pricing until it is defined too. Use it when a project has one part you know completely, like rebuilding an existing screen, and another part you are still deciding, like a new feature nobody has used yet. It lets you commit where you can and stay honest where you cannot.

Does a fixed price stop a project growing beyond what was agreed?

Less than people expect. A fixed price forces every new request through a change order, which can slow that growth down, but it also turns each one into a negotiation instead of a shared decision about priorities. A clear outcome and a visible list of what is being built protects a project from growing beyond what was agreed more directly than the contract type does.

How does Reveneau decide which model to use on a build?

We look at how much of the work is already decided. If the requirements are written and stable, we quote a fixed price against them, because at that point a number is a real commitment. If the goal is still being decided, we run it as a retainer until it is stable enough to quote.

How to price an ongoing retainer vs a fixed project: Reveneau

We have had the same conversation on more than one early-stage build. A founder wants a fixed number for the whole project before a single screen is designed, because a fixed number feels like control. We understand why. But a fixed price for a plan that is still changing is a guess written into a contract.

The question that actually decides which pricing model fits is how precisely this work can be described before anyone starts building it, not how big the project is or how much you want to spend. Answer that honestly and the pricing model follows. Here is the rule we use, and the three situations it covers.

The rule: price what you can describe

A fixed price assumes that today's specification will still be the right specification when the work is done. That assumption only holds when the specification is genuinely final: every screen named, every rule written down, every unusual case already thought through. When that is true, a fixed number is a real commitment on both sides.

When it is not true, the same fixed number becomes a hidden estimate with a margin added to cover everything nobody has thought of yet. The margin has to be there. Whoever quotes the work is carrying every unknown alone, so the quote prices in protection against the unknowns, whether or not they ever show up. You pay for risk that might never have existed, or the number turns out too low and the relationship spends the rest of the project arguing over change orders instead of building.

This is a documented pattern in software estimation. Construx's Cone of Uncertainty, built from Steve McConnell's research into how software estimates behave over a project's life, found that an estimate made at the initial concept stage, before requirements are written, can be off by a factor of four in either direction. That is a sixteen-fold range from the low estimate to the high one. The same research found that range narrows to about plus or minus 25 percent once the user interface design is settled, which typically happens around 30 percent of the way into a well-run project. The number does not get more accurate because someone works harder on the spreadsheet. It gets more accurate because the underlying work has stopped changing.

That is the whole decision rule in one sentence: fix the price once the work has stopped changing, and not earlier.

When a fixed price is the right choice

Fixed pricing fits work you could hand to a stranger and get the right result back. If a written brief, a set of screens, and an agreed list of rules would let someone who has never spoken to you build the correct thing, the work is specified enough to price as one number.

This is common for a defined feature added to an existing product, a rebuild of a known workflow, or a scope that has already been through a discovery phase and ended with a real specification. In the work we do, this is where a fixed quote is truly fixed: because the goal is not changing, both sides can commit to the number and mean it. A fixed price here protects the client from cost overrun on work that genuinely will not change, and it protects the team doing the build from being asked, mid-project, to take on the cost of decisions that were never priced in.

The sign that you are in this situation: nobody on either side expects the brief to change. If people are still saying "we will figure that part out as we go," you are not there yet, no matter how much everyone wants the certainty of a number.

When a retainer is the right choice

A retainer fits work where the goal itself is still being shaped. Early-stage product discovery, a build where user feedback will change the next two months of priorities, or an engagement where the client's own leadership has not settled what "done" looks like: all of these suit a retainer, because a fixed price on any of them is a fixed price on a guess.

The retainer gives up certainty of total cost in return for honesty about what is knowable right now. You pay for a defined amount of capacity, usually monthly, and the work that capacity produces adapts as you learn. Nobody adds extra to a number to cover the unknown, because nobody had to commit to covering it. The cost of that honesty is that you do not get a single total figure up front, and some clients see that as a loss of control. In fact you get more control: you can redirect the work every time you learn something new, instead of paying a change-order fee to redirect work that was quoted against last month's assumptions.

A retainer is also the right structure whenever the work itself is genuinely open-ended: ongoing maintenance, an ongoing capability the business expects to keep needing, staff augmentation on a team whose roadmap changes quarter to quarter. There is no "done" to price against, so there should not be a single price pretending one exists.

The middle case: price in phases

Most real projects are not purely one or the other. A build often has one part that is completely settled (rebuild this exact screen, migrate this exact data model) sitting next to a part nobody has decided yet (what the new recommendation feature should actually do). Forcing the whole thing into one pricing model misprices half of it either way.

The fix is to split the engagement where the work itself already divides. Quote the settled part as a fixed price, because it deserves that confidence. Run the undecided part as a retainer until it becomes settled, then requote that piece too. A project rarely carries the same certainty in every part of itself, so this split is the accurate answer for it. We structure a meaningful share of the work we scope this way, because most real products have exactly this structure: a known main part and some unknown parts. Pricing both the same way is where underpricing and overpricing both start.

What this gets you that "we always do fixed price" or "we always do retainer" does not

A single rule for every project solves the wrong problem. Always-fixed protects against cost overrun on the parts of a project that were never at risk of overrunning, while quietly overcharging for the parts that were genuinely unknown when the number was set. Always-retainer gives up the certainty that a client with a truly settled scope has every right to expect, and asks them to pay for flexibility they do not need.

Tying the pricing model to how well the work is actually specified avoids both failure modes at once. It also removes the argument entirely, because the answer is a fact about the state of the plan that both sides can look at and agree on. Either the requirements are written and stable, or they are not yet, and that fact decides the contract.

The people who scope this work well are willing to say, honestly, how much of the plan is still changing, and to let that answer set the terms. Price what you know. Keep paying to find out what you do not, until you do.

Sources

Construx: Software Development's Cone of Uncertainty: documents the 4x estimate variability at the initial concept stage of a software project, narrowing to about plus or minus 25 percent once user interface design is complete, roughly 30 percent into the project timeline.

How to price an ongoing retainer vs a fixed project