Fixed-Price vs Retainer: Choosing an Engagement Model

The engagement model shapes a software project more than the hourly rate does. Good projects go wrong under fixed-price contracts and under monthly retainers alike, and the usual cause is a model that does not fit the work, not bad faith on either side. This post sets out what each model is good at, how scoping and change requests should work, which contract terms to look for, and how our own three models fit in. This is general information, not legal advice. Have a lawyer review any contract before you sign it.

What Each Model Optimizes For

Fixed price trades flexibility for certainty. You get a defined scope, a defined price and a defined date. In exchange, every deviation from that scope becomes a formal conversation. The vendor carries the delivery risk, so a sensible vendor prices that risk into the bid as contingency. That premium for predictability is often worth paying. Public procurement rules make the same point: the US Federal Acquisition Regulation describes firm-fixed-price contracts as suitable when requirements are well defined and as placing the cost risk on the contractor.

A retainer (a monthly team or monthly developers) trades certainty for flexibility. You buy a stable share of a team’s capacity, for example two engineers and part of a designer’s time each month, and direct it wherever the product needs it. Priorities can change every sprint without a contract amendment. The risk moves to you: if the work is directed poorly, the month is spent and the invoice still arrives.

Neither model is cheaper in general. Fixed price costs less when the scope holds, and monthly work costs less when requirements keep moving. The useful question is which risk you would prefer to own.

When Fixed Price Is the Right Call

• The scope is knowable. A marketing site rebuild, a well-specified integration, or an MVP with a written requirements document and finished designs. If you can write the acceptance criteria today, fixed price works. Our guide to scoping an MVP shows how to get a scope to that point.
• You need budget certainty for approval. Boards and procurement teams approve amounts, not velocity. Sometimes a fixed bid is the only way a project gets funded, and that is a legitimate reason to choose the model.
• You are trying a new vendor. A small fixed-scope project lets both sides see how the other communicates, estimates and handles surprises, with a capped downside.

There is a caveat. Fixed price gives the vendor an incentive to do the minimum that satisfies the letter of the specification. A good vendor resists that pull, but the incentive exists. A bid far below the others deserves questions too: a vendor may be planning to recover the difference through change orders. Our breakdown of what a custom web app costs in 2026 can help you judge whether a number is plausible.

When a Monthly Model Is the Right Call

• The product is live. Products with real users produce a steady stream of insight that should change the roadmap. Freezing that roadmap into fixed scopes means paying negotiation overhead on every lesson.
• Discovery is part of the work. AI features are the clearest current example: how well retrieval performs on your data, or how much prompt iteration a workflow needs, cannot be known in advance. A fixed price on experimental work pushes the vendor to pad heavily or the client to accept frequent change orders.
• Response time matters more than the cost of each response. A team that already knows your codebase can ship a critical fix quickly. Setting up a new fixed-scope engagement for the same fix adds paperwork before any code is written.

The weakness of monthly work is drift: months in which the team stays busy but the product does not visibly advance. The defense is cadence and measurement, and the vendor should propose both. Agile guidance such as the Scrum Guide and the UK government’s Service Manual on agile delivery rests on the same idea: short cycles, working software shown regularly, and priorities reviewed in the open. If a vendor reports hours and activity but not what was delivered, treat that as an early warning.

How Scoping Should Work

For a fixed-price bid, ask to see the decomposition: the feature list broken into pieces that can be estimated, with assumptions stated. Useful assumptions include which third-party APIs are expected to work as documented, what content the client provides, and how many design revision rounds are included. Every unstated assumption is a possible dispute later.

Some work cannot be estimated responsibly at the start. A common answer is a short paid discovery phase with its own small fixed price, producing a technical spike, a scoped backlog and a firm bid for the build. Ask whether the discovery output is yours to take to other vendors for competing bids. It should be.

How Change Requests Should Be Handled

Change requests are where fixed-price relationships most often sour, so the process matters as much as the price. Look for these terms:

1. A written impact assessment before any commitment, covering what the change costs in money and schedule and what it displaces, delivered in days.
2. A distinction between clarifications and changes. If the specification was ambiguous and the vendor guessed wrong, that is usually the vendor’s cost. If the requirement changed, that is a change order. Watch how a vendor handles the first ambiguity.
3. Some tolerance for small changes. Many contracts let cosmetic or equal-effort swaps be absorbed without paperwork. A vendor who writes a change order for every button color is optimizing for billing.
4. No blocked delivery. A dispute over a change should not stop the agreed scope from shipping.

Common Market Terms to Look for in Monthly Contracts

The terms below are common in the market. They are not a description of our contract, and the right values depend on your situation.

• Capacity, not hour buckets. Agreements defined as named people at set allocations keep the conversation on outcomes and give you continuity. Buckets of hours invite both padding and penny-counting.
• Rollover of unused time. Some contracts let a limited share of unused capacity carry into the next month. Unlimited rollover causes a capacity crunch when a client tries to spend several banked months at once, so expect a cap.
• A ramp-down path. Products mature. A contract that lets you step the allocation down with notice, and not only terminate, fits that better than an all-or-nothing choice.
• A warranty or defect-fix period after acceptance. Many fixed-price contracts include a defined window in which defects against the agreed scope are fixed at no charge. Check the length and what counts as a defect.

Red Flags in Agency Contracts

• IP terms that give the vendor excessive leverage. It is normal for ownership to transfer when the work is paid for. Be wary of clauses that let a vendor withhold the whole codebase over a small disputed invoice, and make sure the assignment is in writing. In the US, software written by a contractor is not automatically a “work made for hire”, as the Copyright Office explains in Circular 30, so a written assignment matters.
• No way out. Long lock-ins with no termination-for-convenience clause are how weak vendors keep clients they could not keep on merit.
• Vague acceptance criteria. If the contract says “delivery of the application” without defining acceptance testing and a remediation window, the vendor decides when the work is done.
• Hosting, accounts and repositories in the vendor’s name. These should live in accounts you own, with the vendor invited as a collaborator. A vendor who insists on owning your infrastructure is creating a switching cost.
• A fixed bid that implies a rate well below the vendor’s own monthly rate. The difference tends to come back as change orders.

How Our Three Models Fit

We offer three engagement models. A Fixed-Price Project covers the agreed scope, nothing more, and suits work that can be specified up front. A Dedicated Team and Individual Developers are the monthly models: month to month with a one-month minimum, then 30 days’ notice. Ongoing AI work runs under one of the two monthly models. If a developer is not the right fit in the first two weeks, we replace them at no cost, and if you plan to interview the people yourself, our guide on how to vet senior engineers may help.

Some things are the same under all three. You have access to the repository from the first commit, and full ownership of the code and all intellectual property transfers to you once it is paid for. We sign an NDA on request, before you share anything confidential. You get a written update every week and a demo of working software every two weeks.

A pattern that works well for a new product is a Fixed-Price Project for a tightly scoped first version, followed by a monthly model once real users start changing the roadmap. How We Work explains the three models in more detail. To talk through a scope, get a quote; we send a written proposal within 48 hours of the scoping call.