Write the Statement of Work Before the First Invoice
An MSA does not say what the engineer will do in your repository. The statement of work does. If it only says senior backend help, you will argue about the invoice in month three.
Companies sign a master services agreement, a data processing addendum, and an NDA, then start a Slack channel. The work is “help with the backend.” Three months later the contractor has been in every incident, the roadmap has not moved, and finance asks what the days were for. Nobody is lying. The document that should have named the work was never written.
A statement of work is that document. It is not the MSA. The MSA says how you contract, who owns what is produced, how invoices work, and how either side stops. The statement of work says what this engagement is for, how many days, what is in, what is out, and what will be true at the end that is not true now. For a senior backend contractor, that is a few pages. If it is twenty, it is a specification pretending to be certainty you do not have.
I work this way, on a B2B engagement at €300/day, so treat the commercial shape as one example. The structure is the part worth copying even if you hire someone else.
The outcome, written so a stranger can test it
“Improve the backend” cannot be tested. These can:
- PHP 8.3 in production, the current framework line you named, and a deploy you would run on a Thursday.
- One Go consumer on the invoice queue, PHP consumer still deployable, duplicates measured at zero for a week.
- p95 of
POST /checkoutunder the number you wrote down, with the query plan attached, whether or not the language changed. - A written decision that nothing should be extracted, and the three indexes or package replacements that were the actual work.
Pick one primary outcome for the period the statement covers. A quarter can have a secondary. It cannot have twelve. Twelve outcomes is a team you did not hire.
Attach how you will know. A dashboard, a tag in production, a document merged to the repository. “The team feels faster” is a hope. It can sit in the preamble. It cannot be the acceptance line.
Name the repository. “The backend” is often four services and a script on a VM. The statement should say which ones the contractor is expected to change, and which ones they may read and must not deploy. This is how you avoid a helpful pull request against the billing service nobody asked them to touch.
Days, overlap, and who reviews
State the cadence as days, not as a vague retainer. Up to five days a week is a different product from two. The day rate only means something next to the calendar. Write the expected days per week, the notice to change the cadence, and that unused days are not a debt you bank forever unless you truly want that.
Write the overlap. CET/CEST hours, or whichever window your team actually reviews code. A contractor who is excellent and present at 1 a.m. your time will still stall if review only happens in your stand-up. The statement should say they attend the stand-up, or that they do not. Both are valid. Silence is how people get surprised.
Name the reviewer. One engineer internally who can merge, who will look at pull requests within an agreed number of working days, and who tells the contractor when the answer is “we will not merge that.” A contractor blocked on review is not idle by choice. If you cannot name the reviewer, you are not ready to buy days.
Name the tools they will use: your Git host, your issue tracker, your chat. “They will also introduce their own workflow” is a no, unless the outcome is a new workflow you asked for.
In, and especially out
In scope is the outcome and the engineering actions that obviously serve it: reading the code, writing the change, the tests that make the change reviewable, the short note in the repository that explains a decision, production diagnosis when the change misbehaves.
Out of scope should be a list you are willing to say aloud:
- People management, hiring, and performance reviews.
- A second product, a mobile client, or a design system.
- On-call as a permanent rotation, unless you are buying that and paying for the constraint on their other days.
- Rewriting the system in a new language because it came up in a meeting.
- Unlimited Slack archaeology with no path to a change.
Incidents deserve one sentence. Either “production incidents in the systems listed are in scope up to N days in a month, and they displace the outcome” or “incidents are out of scope; we will agree a separate day if we want you in one.” The first is honest for an embedded engineer. The second is honest for a fixed piece of work. The unwritten version is how a migration dies inside an on-call calendar.
A fractional week needs the out-of-scope list even more. Two days a week cannot absorb “also look at this” without losing the outcome. The statement is how you protect the two days.
The pilot is part of the statement, not a vibe
The first period should be a paid pilot with a length (ten working days is the one I use) and a piece of work from the real backlog. The statement should say what those ten days produce: a merged change, a written map of the risk, or a decision to stop. “We will see how it feels” is how you slide into month four without deciding.
Say that either side can stop at the end of the pilot without a kill fee, or with whatever notice your MSA already requires. Say what happens to half-finished branches. Usually they stay in your repository; you paid for them.
After the pilot, the statement can renew by a short written confirmation of the next outcome and the next block of days. Do not rely on a rolling “until further notice” if finance needs a horizon. A month or a quarter, renewed on purpose, is enough. A permanent contractor who is secretly a hiring freeze with no date is a different decision, and it belongs to the comparison of contractor versus full-time hire, not to an evergreen SOW.
Access, secrecy, and stopping
List access as a predecessor, not as a hope. Repository, staging, logs, error tracker, a database role that is not production-admin by default, and a laptop policy if you require one. If access takes three weeks, the pilot has not started, and the statement should say the clock starts when access works, or you will pay for days of waiting. Paying for waiting is sometimes fair. Pretending those days were engineering is not.
Confidentiality is usually in the NDA. The statement should still say whether production data is allowed on a machine you do not administer. For most backend work, a staging dump with personal data removed is enough. A production connection is a separate, narrower grant.
Intellectual property should already be in the MSA: you own the code committed to your repository. The statement should not re-negotiate that in a paragraph someone will not read. It should say the contractor will not place copyleft surprises in the codebase without telling you, and will not reuse your private code elsewhere. Their pre-existing tools stay theirs. That distinction matters if they bring a script. Write one sentence. Do not attach a licence lecture.
Invoices: monthly, days worked, EUR, the rate, the payment term. Expenses only if you pre-approve them. No success fee that encourages a rewrite. The rate discussion is easier when the statement points at days and an outcome rather than at a blended “senior resource.”
Termination: notice in days, what is delivered on the last day (open pull requests described, access revoked, a short handover note of what is mid-flight). A handover note is not a knowledge-transfer programme. If you needed a permanent owner, hire one. The note should say where the decisions were written inside the repository, so the note can be short.
Sentences that cause the drift
Replace these when you see them.
“Own the backend.” Ownership without a boundary is on-call plus roadmap plus every argument. Name the system and the outcome.
“Do whatever the team needs.” The team needs different things every Tuesday. The reviewer named above can sequence that inside the outcome. The sentence cannot.
“Senior guidance and hands-on coding, as required.” Pick the mix. Guidance without commits is a different engagement from commits without a seat in the design conversation. An embedded engineer does both, in the repository, with review. Say that, and say they are not an agency account team. If what you need is a project manager and three specialists, the contractor versus agency choice matters more than the SOW template.
“Best efforts to modernise.” Best efforts is what remains after the outcome was deleted. Put the outcome back.
“The contractor will transfer all knowledge before leaving.” They can write decisions down as they go. They cannot download a decade from a monolith in the notice period. Require the decisions in the repo during the engagement, not a heroic final week.
A one-page statement with an outcome, a repository, a cadence, a reviewer, a pilot, and a stop will outperform a template that covers every clause your last agency marked up. The MSA is allowed to be the long document. The statement of work is the one the engineer and the engineering manager both use.
If you want that page filled in against a real backlog rather than a sample, the commercial form I use is the senior backend contractor engagement: €300/day, up to five days a week, CET/CEST overlap, B2B, EUR, ten paid days first. Bring the outcome you care about. The first draft of the statement can be that outcome plus the list of what I will not touch.