Statement of Work vs. Time and Materials: Getting the Contract Right Before Work Starts

Most disputes between software agencies and their clients come down to a mismatch between what was contracted and what was expected. The technical work is often fine. The relationship breaks over scope creep, payment timing, or a disagreement about what “done” means.

The contract structure is not the cause of those disputes, but it determines how they play out. A well-matched contract type absorbs the normal friction of a software project. A mismatched one amplifies it.

The two main models

Statement of Work (SoW) defines a specific deliverable, a timeline, and a price. The agency agrees to build a described thing by a described date for a described fee. If the client asks for something outside that definition, it requires a formal change order. The risk of underestimating sits with the agency. The risk of having no flexibility sits with the client.

Time and Materials (T&M) bills actual hours worked at an agreed rate. The client pays for the work, not the outcome. Risk of scope expansion sits with the client. Risk of the agency underdelivering for the hours billed sits with the client too, which is why T&M works best when the client has enough technical oversight to know whether the hours are productive.

Both models are complete contracts. Neither is a workaround or a compromise. The choice is about which party should hold which risks given what the project actually looks like.

When SoW is the right call

A fixed-price SoW makes sense when:

Requirements are genuinely stable. The client has a specification, the agency can scope against it, and both parties can agree on acceptance criteria before work starts. This is rarer than it sounds. Most clients think they have stable requirements until the first prototype arrives.

The client cannot carry budget uncertainty. A startup raising its first round, a small business owner, or a non-profit with a fixed grant budget may need to know the total cost upfront to proceed at all. SoW is often the only viable commercial structure in these cases.

The project is a known type. A standard e-commerce build, a marketing site with a defined page count, a mobile app with a clear feature list, an API integration between two documented systems. These are projects where an experienced agency can scope accurately enough that a fixed fee is not a gamble.

The agency has done it before. Fixed-price contracts carry estimation risk. The mitigation is depth of experience with that project type. An agency that has built 50 similar projects can absorb that risk because the unknowns are bounded by prior experience. An agency building in an unfamiliar domain is taking on risk that will cost someone.

When T&M is the right call

Time and Materials is the right structure when:

Requirements will evolve. Products that are being discovered during development, integrations with undocumented legacy systems, or projects where the client needs to see a working version before finalizing the next phase. In these cases, a fixed SoW is a fiction, because neither party knows what to fix it to.

The engagement is ongoing. Retainer relationships, maintenance contracts, and long-term product partnerships are naturally T&M. The value of the relationship is in continuous access to a team that knows the product deeply. Trying to repackage that as a series of SoWs adds administrative overhead without adding clarity.

The client wants to control scope dynamically. Some clients, usually ones with technical leadership, prefer to adjust priorities sprint by sprint. They want to be able to say “skip that feature, do this instead” without filing change orders. T&M lets them do that.

Discovery is required. If you are auditing an existing system, scoping a large project, or doing technical research before committing to a build, T&M is the right structure for that phase. You cannot write a fixed-price contract for work whose output you cannot define yet.

The failure mode: wrong model for the project type

The most common problem is a fixed-price SoW on a project that was never actually well-defined.

It goes like this: the client wants budget certainty, the agency wants to close the deal, and neither party pushes hard enough on “do we actually know what we are building?” The SoW is signed with some ambiguity baked in. Development starts. Scope questions arise. The agency issues a change order. The client is surprised (“we thought that was included”). Tension builds. By the third change order, the relationship is damaged.

This is not a bad-faith problem. Both parties wanted the project to work. The structure was just wrong for the actual project.

The solution is a short discovery phase before any fixed-price contract. Two to four weeks of requirements work, prototyping, and specification writing, billed on T&M. At the end of discovery, both parties know enough to sign a meaningful SoW or to agree that T&M is the right structure for the build phase. The discovery investment pays for itself in avoided disputes.

The hybrid: capped T&M

For most mid-sized projects, neither pure model is ideal. The client wants budget certainty but the scope is not fully defined. The agency wants flexibility but also needs the project to be financeable.

A capped T&M contract addresses both. The work is billed at an hourly rate (T&M), but the total is capped at a maximum figure. The client cannot be surprised with a bill beyond the cap. The agency has flexibility to handle scope evolution within the cap.

The cap is not a free unlimited guarantee. The contract should specify:

• What happens when the project is tracking toward the cap (the agency flags it, the parties decide whether to extend, reduce scope, or close out)
• What is excluded from the cap (client-caused delays, third-party integration issues, requirements changes)
• What happens if the project finishes under the cap (the client does not pay the remainder, or they apply it to a next phase)

The capped T&M model works well when the agency commits to honest forecasting. A project that is 80% through the budget at 40% through the scope is not a surprise at the end. It is a conversation in week four. The contract does not help if the agency does not raise the flag.

Acceptance criteria: the part that makes the contract real

Whatever structure you use, the acceptance criteria are what make the contract enforceable.

A SoW that says “build a mobile app” is not a contract in any meaningful sense. A SoW that says “build iOS and Android applications with the features listed in Appendix A, accepted when the client signs off on a test build that passes the checklist in Appendix B” is a contract.

Acceptance criteria should describe:

• What the deliverable does (feature list, user flows, API behaviors)
• What environment it is tested in (staging, production-equivalent, real devices)
• Who signs off and how (a named role, a written approval)
• What happens if feedback arrives after sign-off (change order, or included if it is a bug vs. a new requirement)

Time and Materials contracts need acceptance criteria too. Without them, you cannot tell the client that a phase is complete and billing has moved to the next phase.

Payment structure by contract type

SoW (fixed-price): Milestone payments are standard. A typical structure: 30-50% upfront, 30-40% at a defined midpoint (delivery of a working build, completion of a phase), and the remainder on final acceptance. Never 100% at the end. The agency carries execution risk; the client carries payment risk. Milestone payments balance them.

T&M: Weekly or monthly invoicing against hours logged. Most clients accept 30-day payment terms. Government or enterprise clients may take 45-60 days. Factor this into your cash flow before signing a large T&M engagement.

Capped T&M: Either milestone or periodic billing works, but periodic billing (monthly) is more common because the scope is fluid. The cap means the client is never surprised; the billing frequency means the agency is not carrying the cost for extended periods.

The contracts that make the rest of this work

None of this matters without supporting agreements. Before any work starts, you also need:

A master services agreement (MSA) that covers IP ownership, confidentiality, liability limits, and how disputes are handled. The SoW or T&M addendum lives under it.

An IP assignment clause that is specific about what the client owns (typically the deliverables) and what the agency retains (their tooling, frameworks, methodologies).

A termination clause that specifies what happens if either party walks away. For T&M, this is usually “pay for hours worked.” For SoW, it requires more care around partial completion.

The operational side of client relationships, including how payment terms, SLAs, and retainers work in practice, is covered in detail across agency payment terms and SLA and support contracts. For the proposal stage that happens before any contract is signed, writing a technical proposal covers the process of moving from a client conversation to a written scope.

The one rule that covers most cases

If the client cannot tell you, before work starts, what done looks like and what they will check before they accept it, do not sign a fixed-price SoW. Use T&M or discovery first.

The SoW is a useful structure. It gives the client budget certainty and the agency a clear target. But it only works when both parties can agree on what they are committing to. When they cannot, the paperwork is a formality that delays the inevitable dispute rather than preventing it.