Short answer
Fixed-scope and time-and-materials are the two standard ways to price software work. A fixed-scope engagement quotes one price for a defined deliverable, placing estimation risk on the studio; time-and-materials bills for hours worked, placing that risk on the client and allowing the specification to change mid-build.
Also called: Fixed-price contract, Fixed-bid project, Time and materials, T&M
The trade is certainty against flexibility. A fixed price is genuinely useful when a budget must be approved in advance, and it carries two costs: a risk premium priced into the number, and a rigid change process, since every deviation from the specification becomes a change order. Time-and-materials removes the friction around change and replaces it with an open-ended total, which is why caps, stage gates and a regular burn report matter more than the hourly rate.
Fit follows from how well the work is understood. Bounded, well-specified work that follows a discovery phase prices cleanly as fixed scope. Exploratory work, ongoing product development, and anything depending on a third-party system nobody has integrated with before does not, and a fixed quote for it is usually either padded or optimistic. A common middle path is a fixed-price discovery that produces a specification, then a build priced against that specification.
Common questions
Which pricing model is cheaper?
Neither reliably. Fixed scope costs more when the work goes smoothly, because the risk premium is paid either way, and less when it does not. Time-and-materials tracks actual effort, so it is cheaper on a well-run project and unbounded on a badly-run one. The larger cost driver is how clearly the scope is understood, not the model chosen.
Where this comes up in our work
Related terms
Discovery Phase
A discovery phase is a short, paid engagement that precedes a build and produces the artefacts a build needs: a written scope, user flows, a technical approach, and an estimate grounded in something other than a guess.
Scope Creep
Scope creep is the gradual expansion of a project’s requirements after the scope is agreed, usually through small additions that each seem too minor to renegotiate.
Software Requirements Specification (SRS)
A software requirements specification is the written document defining what a system must do: functional requirements as testable statements, non-functional requirements such as performance and access control, plus constraints and assumptions.
Sprint
A sprint is a fixed working period, commonly one or two weeks, in which a development team commits to a defined set of work and ends with something demonstrable.
Reading definitions because you are scoping a project? Skip ahead and just ask.