Fixed fee, time and materials, or retainer: how to pay a software agency

The important question in an agency proposal is not simply “How much?” It is “What happens when we learn something new?” A missed integration, a confusing onboarding flow or a newly discovered user need will test the agreement more than the polished proposal does.

Pricing models allocate uncertainty differently. They also create different responsibilities for the buyer. The comparison here is an editorial decision framework. It contains no surveyed agency rates, and the worked numbers are deliberately fictional. Use it alongside a clear software brief so the commercial conversation has a defined starting point.

Compare the three models#

These are broad descriptions, not universal contract definitions. A fixed-fee agreement can allow scope to vary within a fixed budget. A retainer can cover a specified service rather than a bank of hours. Read the actual proposal before assuming what its label means.

Fixed fee: make the finish line observable#

A fixed fee can make planning easier when both sides understand the result. A bounded design sprint, a defined migration or a small release with tested dependencies may be suitable candidates. The proposal should explain what is accepted, what evidence demonstrates acceptance and how unresolved defects are handled.

Problems arise when a fixed number sits on top of a fluid promise. “Build the platform” cannot tell you whether reporting, administration or accessibility work is included. Ask the team to walk through an example change: a new user role, a second payment flow or a delayed data feed. What happens to scope, price and timing?

UK government agile contracting guidance warns that a rigid fixed-price model is less likely to achieve intended outcomes when information is limited and uncertainty is high.^[1] That is a useful principle for founders too, even though private engagements have a different context.

Time and materials: buy visibility with the flexibility#

Paying for effort can support discovery and changing priorities. It also requires an engaged product owner. Agree the rates, who can approve additional time, the reporting cadence and when spending must pause for review. Ask to see working product increments as well as a timesheet; hours used are not the same as useful progress.

Review the forecast to complete the next meaningful outcome. If a team has spent half the budget, you need to know which user journeys work, which dependencies remain and what could be removed. A budget ceiling protects against unapproved spend only if the team stops at it. It cannot make every requested feature fit.

Retainers: define the capacity you can rely on#

A retainer can support a product that needs a continuing rhythm of fixes, small improvements and operational help. The agreement needs to distinguish availability from delivery. A team being available to acknowledge a problem does not necessarily mean it is committed to resolve it within the same period.

Ask what capacity is reserved, which roles are available and how urgent work affects planned work. Establish how requests are prioritised, whether unused capacity expires and what happens when several incidents arrive together. If you need an on-call service, describe its hours and escalation path explicitly. Do not infer it from the word “support”.

Also check whether maintenance of dependencies, infrastructure work and product development share the same allowance. Otherwise every necessary update can appear to consume the time you thought you were buying for new features.

A phased agreement can reduce the initial guesswork#

You do not have to choose one model for the life of the product. One approach is a bounded discovery phase, followed by a delivery agreement suited to the remaining uncertainty, followed by a separate support arrangement. Each phase should leave behind something usable: research findings, tested assumptions, working software or operational documentation.

GOV.UK’s discovery guidance treats understanding the problem and deciding whether to proceed as distinct from building the service.^[2] The relevant lesson is the decision point. A discovery phase that automatically rolls into an undefined build has not given you much control. Agree what evidence would justify proceeding, changing direction or stopping.

Ask these questions before you choose#

• What exact outcome or capacity does this price purchase?
• Which assumptions would change the price or date?
• Who can approve scope changes and additional spending?
• How will we review working progress and remaining effort?
• Who owns the repository, hosting accounts and project materials?
• What support, documentation and handover are included?
• How do we pause or finish the engagement without losing access?

Look for answers specific enough to apply to an awkward week, not just a successful launch. If the commercial terms are important to your business, have the actual agreement reviewed in its own jurisdiction. This comparison explains delivery choices; it does not interpret an individual contract.

Choose the model that matches the work#

Start with a fixed fee when the outcome is sufficiently bounded to describe and verify. Consider time and materials when learning is likely to change the route, and you can make regular decisions. Consider a retainer when the work is ongoing and you can define the service or capacity you need.

Then compare the full operating picture. Our MVP cost guide separates planning scenarios from recurring costs. If you are choosing a supplier, use the UK agency directory as a starting point for research, with its affiliation disclosure in view. A clear agreement makes a good team easier to work with; it does not replace evaluating the team.

Stress-test the model with three changes#

These are prompts for a commercial conversation, not universal contract rules. Ask the supplier to walk through the same scenarios using its proposed terms. If neither party can explain the next step, the model is not yet clear enough for the awkward week when it matters.

Compare an outcome with an outcome#

A fictional fixed proposal of £30,000 cannot be compared meaningfully with “£750 per day” until you know the likely effort and included responsibilities. Forty days at that rate also produce £30,000, but the scope flexibility, overrun treatment and acceptance obligations may differ.

For time and materials, agree a forecast, reporting interval and spending authority before the limit is reached. For a retainer, define usable capacity, response expectations, prioritisation, unused capacity and termination. For a fixed result, clarify dependencies and the distinction between an incomplete agreed feature and a new request.

Keep one change log in every model. Record the request, reason, price/date effect and approver. An informal “small addition” can be commercially important when several accumulate, even if each is easy to describe.

Put this guide to work#

Frequently asked questions#

Sources and methodology#

This guide combines editorial analysis with the linked primary sources. Decision frameworks, worksheets and worked examples are our own; examples are illustrative unless explicitly identified as supplier claims or published research. We have not conducted original interviews, comparative supplier testing or a controlled experiment for this article.

1. Cabinet Office: Contracting for Agile Guidance Note ↗

   Published guidance, updated 20 June 2023. Its public-sector context differs from a private agency engagement.

   Accessed 16 October 2026
2. GOV.UK Service Manual: how the discovery phase works ↗

   Public-service guidance used for its problem-definition principles, not as a startup timetable.

   Accessed 16 October 2026

Source check: 16 October 2026. Platform documentation can change. Published as part of our editorial collection.

Expanded 16 October 2026 with practical decision material, downloads and topic-specific answers. Supplier and platform claims are identified by their linked sources.