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 shift 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 edge 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 there.

Is a fixed price always cheaper than a retainer?

No, and comparing the two on price alone misses the point. 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 tax 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 eats the risk 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 shape 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 target 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 cold, 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 protect me from scope creep?

Less than people expect. A fixed price forces every new request through a change order, which can slow scope creep 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 scope creep 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 shaped, we run it as a retainer until the shape 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 the instinct. But a price fixed against a plan that is still changing is a guess wearing 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 is a bet that today's specification will still be the right specification when the work is done. That bet only pays off when the specification is genuinely locked: every screen named, every rule written down, every edge case already thought through. When that is true, a fixed number is a real commitment on both sides, not a hope.

When it is not true, the same fixed number stops being a commitment and becomes a hidden estimate with a margin baked in 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 fighting over change orders instead of building.

This is a documented pattern in software estimation, not a hunch. 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 shape.

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

When a fixed price is the right call

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 come out the other side with a real specification. In the work we do, this is where a fixed quote earns its name: because the target is not moving, 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 absorb decisions that were never priced in.

The tell that you are in this zone: 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 call

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 are retainer territory, because a fixed price on any of them is a fixed price on a guess.

The retainer trades certainty of total cost 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 is padding 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 read that as a loss of control. It is closer to the opposite: you get to 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 shape whenever the work itself is genuinely open-ended: ongoing maintenance, a standing capability the business expects to keep needing, staff augmentation on a team whose roadmap shifts 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 along the line the work itself already has. Quote the settled part as a fixed price, because it earns 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 shape: a known core and an unknown edge. 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 blanket rule in either direction 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 not the ones with the strongest opinion about fixed price versus retainer. They are the ones willing to say, honestly, how much of the plan is still moving, 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.