Delivery
Ten things to check in an ecommerce agency’s statement of work before you sign
By DEQIO · October 2026 · 6 min read
In short
Most replatform disputes are settled by the statement of work, months before anyone disagrees. Ten clauses decide whether a delay, a defect or a change of mind costs you or the agency. Check them before you sign, while you still have leverage.
Why the statement of work matters more than the proposal
The proposal sells the project. The statement of work (SOW) defines it. When a project overruns, nobody reads the proposal again; both sides read the SOW, line by line.
We’ve written these documents as the supplier and signed them as the client. Good agencies aren’t trying to trap you. But a SOW is written by the side that knows where projects go wrong, and its defaults protect that side. These are the ten things we check, in order of how often they cause trouble.
1. The assumptions list
Every fixed price rests on assumptions: “client supplies product data in the agreed template”, “no more than two rounds of design revisions”, “ERP API is stable and documented”. Each one that turns out false becomes a change request.
Check: that the assumptions are listed in one place, that you understand each one, and that you can actually meet them. Challenge any you can’t.
2. Acceptance criteria and “deemed acceptance”
What does “done” mean for each deliverable, and how long do you have to test it? Watch for deemed acceptance: wording that treats a deliverable as accepted if you don’t reject it within, say, five working days.
Check: acceptance criteria written per deliverable, a testing window that fits your team’s real availability, and deemed acceptance only after a reasonable period with a written notice first.
3. Change control
Change is normal. Unpriced change is the problem. The SOW should say how a change is estimated, who can approve it, and at what rate.
Check: a rate card attached, a named approver on your side, a written estimate before any change work starts, and a threshold above which your board or finance lead signs off.
4. Payment milestones
Payments tied to dates reward time passing. Payments tied to accepted deliverables reward progress.
Check: milestones linked to acceptance (design signed off, UAT passed, go-live), with a meaningful final payment, typically 10–20%, held until after go-live and hypercare.
5. What is actually fixed
“Fixed price” often covers build only, with integrations, data migration or project management on time and materials. Capped time and materials can be a fair middle ground, if the cap means something.
Check: a clear table of which workstreams are fixed, capped or time-and-materials, and what happens when a cap is reached.
Get the Replatform Decision Checklist
The questions to answer before you commit six figures.
6. Key people
The team in the pitch is not always the team on the project.
Check: the lead developer, solution architect and project manager named in the SOW, a commitment on their time, and your right to approve replacements.
7. Defects and warranty
After go-live, who pays to fix bugs? Without a warranty clause, a defect found in week three can be billed as support.
Check: defect severity levels defined, response and fix times for each, and a warranty period (commonly 30–90 days after go-live) where defects in delivered work are fixed at no charge.
8. Ownership and access
You should own what you pay for, and be able to take it elsewhere.
Check: that you own the custom code and designs on payment; that you have access to the code repository from day one; and that platform, hosting, domain, payment and extension accounts are in your company’s name, not the agency’s.
9. Your dependencies
The SOW will list what you must provide: data, content, decisions, test resource, third-party access. If you’re late, the agency’s timeline moves and the cost may too.
Check: each dependency has a date and an owner on your side, and the dates are realistic alongside your team’s day jobs. This is the clause clients most often sign without reading.
10. Exit and handover
Nobody plans to part ways mid-project, which is why it’s worth agreeing how now.
Check: your right to end the contract with reasonable notice, payment only for work accepted to that point, and a handover obligation covering code, documentation, credentials and a short transition period.
The one-page version
| # | Clause | Ask before you sign |
|---|---|---|
| 1 | Assumptions | Are they listed, and can we meet every one? |
| 2 | Acceptance | Is “done” defined per deliverable, with a fair testing window? |
| 3 | Change control | Rate card, written estimates, named approver? |
| 4 | Payments | Linked to acceptance, with a final retention? |
| 5 | Pricing model | Which workstreams are fixed, capped or time and materials? |
| 6 | Key people | Named, committed, replacements approved by us? |
| 7 | Warranty | Severity levels, fix times, free fixes for 30–90 days? |
| 8 | Ownership | Our code, our repo, accounts in our name? |
| 9 | Dependencies | Dated, owned and realistic? |
| 10 | Exit | Notice period, pay for accepted work, full handover? |
This is a practical checklist, not legal advice. Have a solicitor review the final contract.
If you’re choosing between agencies, these clauses are worth comparing as carefully as price. Our Platform & Agency Selection service includes a full commercial and SOW review. Once you’ve signed, Programme Assurance keeps both sides to it.
About DEQIO
Independent ecommerce leadership with 20 years on both the client and supplier side. No platforms, no builds, no referral fees. About DEQIO →
About to sign with an agency?
An independent review of the contract, from people who’ve sat on both sides of the table.