Guide · Hiring, contracts & ownership

Software development contract and SOW template: a plain-English version for founders

A plain-English software development contract and SOW template: scope, milestones, acceptance, change requests, IP and handover. Not legal advice.

By Akash Bansal, founding engineerUpdated 5 November 20267 min read

Not legal advice. I'm an engineer, not a lawyer. What follows is the plain-English structure I'd want in any software contract as a founder, and the terms I offer on my own builds. Have a lawyer in your country review anything you sign.

Most contract templates online are written by lawyers for lawyers. They're thorough on liability and silent on the things that actually sink founder projects: what "done" means, what happens when you change your mind in week four, and whose name is on the cloud account. Those live in the statement of work, and you're the only one who can write it.

What goes in a software development contract?

Two documents. A master services agreement (MSA) carries the legal terms that rarely change. A statement of work (SOW) describes one specific project. You sign the MSA once and add a new SOW per phase, so a second build doesn't mean renegotiating liability.

Some freelancers combine both into one short agreement. That's fine for small jobs, as long as every item below appears somewhere.

Which clauses matter most for a founder?

Five clauses decide whether a build goes well: scope, acceptance, change requests, payment milestones and IP. Each one prevents a specific, common failure.

I wrote about how missing clauses like these cost founders money in why founders waste $50K on agencies. This article is the constructive half: what to put in instead.

Why isn't "work for hire" enough to own the code?

Because, in US law, a contractor's work only counts as "work made for hire" in nine specific categories, such as a contribution to a collective work or a translation. The US Copyright Office's Circular 30 lists them, and software written by an independent contractor isn't clearly among them. So contracts that rely on the phrase alone can leave ownership with the developer.

The usual fix is a belt-and-braces clause: the work is a work made for hire where the law allows, and otherwise the developer assigns all rights to your company. A copyright transfer has to be in writing and signed (17 U.S.C. § 204). Other countries have their own rules, which is one reason to have a lawyer look at this clause.

Legal ownership is half of it. Practical control (the repository, the cloud account, the domain, the app-store and payment accounts) is the other half, and I go through both in who owns the code: a founder's checklist.

A plain-English statement of work template

Copy this, replace everything in [brackets], and delete what doesn't apply. It's written for a fixed-price build; for hourly work, replace section 6 with a rate, a monthly cap and a weekly report.

1. Parties and summary

This statement of work is between [Your Company Ltd] ("Client") and [Builder name or company] ("Builder") under the master agreement dated [date]. Builder will design, build and launch [product name], [one sentence: who it's for and what it does].

2. Goal

The goal of this phase is: [the outcome, not the features. Example: "a booking app that lets studio members book and pay for classes, live in the App Store and Google Play"]. Success at launch means: [one measurable thing, e.g. "a member can book and pay for a class in under two minutes"].

3. In scope

1. [User type 1, e.g. Member]: [what they can do, in plain verbs: sign up, browse classes, book, pay, cancel].
2. [User type 2, e.g. Admin]: [create classes, see bookings, issue refunds].
3. Platforms: [web / iOS / Android], built as [one cross-platform app / web app].
4. Integrations: [payment provider, email provider, any other system].
5. The detailed requirements are in [PRD title and version, attached], which forms part of this SOW.

4. Out of scope

Not included in this SOW: [brand and logo design; marketing site copy; data migration; languages other than English; features listed under "later" in the PRD; legal pages; third-party fees]. Anything not listed in section 3 is out of scope unless added through section 8.

5. Deliverables and milestones

Builder will show working software every [week] and share a written progress note.

6. Price

The fixed price for this SOW is [amount and currency], payable per the milestones in section 5. The price excludes third-party fees (hosting, app stores, payment processing, AI usage), which Client pays directly on Client's own accounts. Invoices are due within [14] days.

7. Acceptance

For each milestone, Builder will tell Client in writing that it's ready for review. Client has [5] business days to test it against the acceptance criteria in the PRD and either accept it or list specific defects. Builder fixes listed defects and resubmits. If Client doesn't respond within the review window, the milestone is accepted. A defect is something that doesn't meet the written criteria; a new idea is a change request.

8. Change requests

Either party can propose a change in writing. Before any work starts, Builder replies with the effect on price and dates. Client may: approve it; swap it for an in-scope item of similar size at no cost; or defer it to a later phase. No change is billable without written approval.

9. Ownership, code and accounts

1. All code, designs and documents made for this SOW are assigned to Client on payment of each milestone, and are a work made for hire to the extent the law allows.
2. The code lives in a repository owned by Client from day one. Builder works in it with access Client can revoke.
3. Cloud, domain, app-store, payment and email accounts are created in Client's name. Builder gets access as a user, not ownership.
4. Builder may use pre-existing tools and open-source libraries, which stay under their own licences. Builder will list any that carry obligations for Client.

10. Handover

At M3, Builder delivers: setup and deployment instructions another engineer can follow; an architecture overview; a list of every account and service used; and a [1-hour] recorded walkthrough. Handover is complete when [Client or Client's engineer] has deployed the app from the instructions.

11. Support after launch

For [30] days after launch, Builder fixes defects against the acceptance criteria at no charge. After that, support is [a separate agreement / hourly at [rate] / not included].

12. Ending early

Either party may end this SOW with [14] days' written notice. Client pays for accepted milestones and for work done on the current milestone pro rata; Builder hands over all code and documents for work paid for.

What are the red flags in a software development contract?

Read the builder's draft with these in mind. Any one of them is worth a conversation before you sign.

• Most of the price due upfront, or payment tied to dates rather than working software.
• No acceptance criteria, or acceptance at the builder's sole discretion.
• IP that transfers only "on final payment" of the whole project. Per-milestone assignment is fairer to both sides.
• The builder's cloud or store accounts hosting your product.
• "Time and materials" with no cap on a project you could have scoped.
• No handover clause. You'll find out what's missing when you try to hire your next engineer.
• A liability cap and warranty that cover nothing. Your lawyer should read this part.

How do my own terms compare?

On my builds, the fixed quote comes after scoping, with a written design doc; you see working software every week; the code, repositories and cloud accounts are yours from day one; and the build ends with a handover. The template above is that, written down so you can ask anyone for it. Whether a fixed price is right for your project at all is in fixed price vs time and materials.

The SOW is only as good as the scope it points to. Section 3 says "the detailed requirements are in the PRD", and if you don't have one yet, here's how to write a PRD for an app, with a template.

If you'd like a builder who starts from these terms, here's how I work.