Fixed price vs time and materials

Fixed price works where scope genuinely can be pinned down: a standard site, a landing page, an integration with a known API, an extension within clear bounds. Certainty is paid for with a risk premium, usually 20-40% on top of an honest estimate, because the contractor prices in the unknown. The second property matters more than the first: every scope change goes through a contract amendment. That imposes discipline but makes the project rigid, and if a month in it turns out users need something else, the change runs through negotiation instead of through prioritisation.

Time and materials fits where the scope is not knowable in advance: product development, long-running system evolution, research tasks, an MVP built to test hypotheses. The client pays for actual hours and gains the key advantage, the ability to reprioritise every sprint without re-signing anything. In exchange the client takes on management: if nobody on the business side makes decisions and watches scope, T&M becomes an open-ended process. The working practice is a budget cap per period, a regular demo of working software, and reporting against tasks rather than abstract hours.

In practice most healthy commercial projects run a hybrid, and that is a deliberate design rather than a compromise. Discovery and design go at a fixed price, because their scope is predictable and the output is tangible. Development runs on time and materials with a quarterly cap and a stated rate. Support runs on a retainer with an agreed SLA. That distributes risk across the stages where it actually lives, instead of pretending the whole project is equally predictable from the first day to the last.

A useful test when choosing a contractor: ask what happens when requirements change. An answer of "on fixed price nothing changes, it is all in the contract" means you will receive exactly what you described six months ago, mistakes included. An answer of "on T&M we just add a sprint" with no mention of budget or priorities means there is no management. A healthy answer describes a procedure: how a change is estimated, who decides, what leaves the scope in exchange, and how that gets recorded.

Related terms

• Technical specificationA technical specification is the document that fixes what exactly will be built and on what grounds the work counts as accepted: goals, roles, scenarios, screen-level requirements, integrations, non-functional requirements and an explicit out-of-scope section.
• DiscoveryDiscovery is a one to three week pre-project phase that frames the problem, studies users and competitors, describes scenarios and constraints, and produces a prototype, a specification and an estimate with a justified range instead of a number pulled from the air.
• SLAAn SLA is a service level agreement: it fixes system availability as a percentage, response and resolution times by incident severity, the hours support operates, and the compensation owed when the provider fails to meet those numbers.
• Outsourcing vs in-houseOutsourcing and in-house are two ways to cover a development need: contract an external team at an agreed hourly rate, or build a staff team where salaries come with payroll taxes, recruitment, equipment and management on top.
• Product backlogA product backlog is a priority-ordered list of everything that could be built into a product: it is not a dated plan, it is continuously revised, and one person, the product owner, is accountable for the order of it.

Related services

• IT consulting and product auditThe most expensive mistakes in software happen before the first line of code: a misread problem, a stack chosen out of a contractor’s habit, and a specification that does not exist. Consulting exists to settle all of that before the development meter starts running: what to build, out of what, at what cost and in which order. The result is a document, not an opinion on a call.
• Website development, end to endWe build sites that still hold up a year later: from a one-page CMS build to a store or a web application on React and Next.js. One team for design, code, integrations and launch.
• Web app and Telegram Mini App developmentFor when a site is no longer enough and you need a product: an account area, a dashboard, an internal tool or a Mini App inside Telegram. We design the architecture, write the backend and frontend, and take it to release.

Read more

• How to Choose a Development Contractor: The Question List and the Red FlagsA practical guide to choosing a development vendor: who needs a freelancer and who needs an integrator, the 25 questions for the first call, how to verify portfolio cases and what belongs in the contract.
• What a Website Actually Costs in 2026: The Estimate, Line by LineA practical breakdown of a web development estimate: what analytics, design, front end, back end and integrations actually cost, which expenses always show up after launch, and where cutting the budget is safe.
• The Technical Specification: Structure, a Worked Template and the Usual MistakesA specification is not bureaucracy, it is leverage: anything that does not match it gets fixed by the vendor at no charge. Here is the section structure, a filled-in example for a corporate site and how to write acceptance criteria somebody can actually test.