A statement of work (SOW) is the only document that should decide whether a software project is done. Slack threads, decks, and "we'll be agile" do not. If the SOW is vague, you have not bought software. You have bought a relationship with an argument at the end.
This is the checklist we use when we write SOWs for Myrafy services - and what you should demand from any senior engineering company, including us.
It sits on top of fixed vs hourly and paid discovery. Billing is how you pay. The SOW is what you are paying for.
The Job of a SOW
A useful SOW does four things:
- Names the outcome in language a non-engineer can test
- Bounds the work so change is visible
- Assigns ownership of decisions, environments, and credentials
- States what happens when reality disagrees (change requests, pause, re-estimate)
It is not a marketing PDF. If half the pages are capability slogans, ask for an appendix with the real list.
Must-Haves (Do Not Sign Without These)
1. Parties, term, and commercial shape
Who is contracting with whom, start date, end date or milestone dates, currency, payment schedule, and whether this is fixed scope, time and materials, retainer, or hybrid. Point at invoices and late-payment terms once; do not hide them in an MSA nobody rereads.
2. Scope as a list, not a paragraph
"Build a portal" is not scope. Scope is:
- User roles
- Screens or API endpoints
- Integrations (system, direction, happy path, who owns vendor access)
- Data in / data out
- Explicit out of scope (mobile app, SSO, historical data migration, 24/7 ops)
If you cannot fit the in-scope list on a page, you need milestones or you need discovery first.
3. Acceptance criteria per milestone
"Looks good" is how disputes start. Prefer:
- Given / when / then, or a short checklist per feature
- Sample payloads or OpenAPI sketches for APIs
- "Done means deployed to staging and demoed," not "code complete"
Hold a weekly demo against that list. The SOW should say so.
4. Environments and operations
Name local, staging, production. Who pays cloud bills. Who holds production credentials. Backup and rollback expectations for anything that touches real data. Secrets must not live in git - put the working rule in the SOW; the practice is in stop committing secrets.
5. Repository, IP, and documentation
Default that you own the Git repository and receive full IP on payment for the deliverable. Source, IaC, and runbooks in your org, not a vendor laptop. Handoff includes how to build, deploy, and who to call for the support window.
We prefer direct contracts for this reason: fewer parties between you and the IP.
6. People and communication
Named roles (product owner on your side; engineering lead on ours). Response expectations (not a fake 24/7 SLA unless you are buying one). Channel (email, ticket, chat). Language and timezone overlap.
If the SOW says "the team" and never names a lead, you are buying a bench.
7. Change control
A one-pager: how an out-of-scope ask is recorded, estimated, and approved. Verbal "quick wins" still go on the log. This is what keeps fixed-price work honest and hourly work from becoming a fog.
Should-Haves (Strong Default)
| Clause | Why |
|---|---|
| Assumptions | "Client provides API keys by week two" prevents silent stalls |
| Dependencies | Vendor X's sandbox, design freeze dates |
| Non-functional bar | Auth, logging, basic automated tests, performance target if it matters |
| Support window | e.g. 30 days of defect fix after acceptance - named severity |
| Subprocessors | Hosting, email, AI APIs - especially for enterprise security review |
| Warranty vs new work | Bugs in scope vs new features |
For AI features, add corpus, eval bar, and fallback - see shipping Production AI. For cloud, add who owns the account and the alarm channel.
Filler You Can Strike
- Volume metrics and logo walls with no named engagement
- "Best practices," "synergy," "world-class" with no test
- Unlimited revisions
- Ownership of your data by the vendor
- Exclusive lock-in that withholds the repo until a final balloon payment with no escrow
Years in the title, CIN/GST blocks, or legal-entity theatre do not make a SOW better. Accurate scope does.
Startup vs Enterprise Wrappers
The engineering SOW can be the same five pages. What grows for enterprise engagements is the wrapper: NDA, security questionnaire, DPAs, invoicing entities, named subprocessors.
Do not let the wrapper replace the five pages. A 40-page MSA with a one-line "develop software as requested" is how you get a surprise.
Startups should not skip acceptance criteria because they are "moving fast." That is how you pay twice.
How This Maps to an Estimate
A free estimate (we aim for one business day when the brief is usable) is a range. A SOW is a commitment. If the gap between them is large, you are missing discovery, not a better salesperson.
Bring: users, v1 must-haves, deadline, budget band, and stack. We will say whether the next artifact is a small discovery SOW or a build SOW.
A One-Page Review Before You Sign
- Can a new engineer list the deliverables without a call?
- Can you fail a milestone for a missing item without a fight?
- Do you have the repo and cloud account in your name?
- Is there a written out-of-scope list?
- Is there a named owner on both sides?
- Do you know how a change is priced?
If any answer is no, do not start the build. Fix the SOW or buy discovery.
The Bottom Line
What belongs in a software SOW is scope you can test, acceptance you can demo, IP in your repo, environments with owners, and a change log. Everything else is either necessary legal wrapper or decoration.
Sign the boring version. It is the one that still works in month four.
Ready to put a build or a discovery into writing? See how we work, browse services, or contact us for a free estimate.