How to Write a Scope of Work for a Software Project (2026 Template)

By DevDey Editorial Team · October 24, 2026 · 5 min read

Most software projects that go wrong between a client and a freelancer were never clearly defined in the first place. A scope of work (SOW) fixes that by putting what will be built, how it will be checked and when money changes hands into one document both sides agree to. This guide is for founders and managers hiring a developer for a defined piece of work. It covers each section of an SOW, a fill-in template for a small web app, and the mistakes behind most disputes.

What a scope of work is, and who it protects

An SOW describes one specific piece of work: what gets delivered, by when, to what standard and for how much. It is not the whole contract. Think of it as the schedule that sits alongside your agreement with the developer.

It protects you because you have a written definition of "done" before you pay. It protects the developer because new requests show up as new work instead of quietly piling onto the old price. Good developers like a clear SOW for exactly that reason. If someone resists writing one at all, take note.

The sections every SOW needs

Background and goal. Two or three sentences on the business and what the software should achieve. "Let customers book and pay for classes online so staff stop taking bookings by phone" gives a developer far more to work with than "build a booking site".
Deliverables. The concrete things you receive: features, an admin area, source code in your repository, deployment to your hosting, a short handover note. If you expect it, list it.
Out of scope. What is not included. This list prevents more arguments than any other section. Mobile apps, data migration, copywriting, maintenance and third-party fees are common entries.
Acceptance criteria. How you will decide each deliverable is finished. Each one should be testable by someone who did not write the code: "a customer can book a class, pay by card and receive a confirmation email".
Milestones and payment schedule. Break the work into stages that each end with something you can see and test, and attach a payment to each.
Timeline. A target date per milestone, plus how long you have to review each one. Your review time is part of the schedule.
Assumptions and dependencies. What the estimate relies on: you supply designs by a date, you provide account access, the payment provider approves your account. When a dependency slips, dates move and everyone knows why.
Change process. How new requests are handled. Usually: written request, developer estimates time and cost, you approve in writing before work starts.
Communication. Where you talk, how often you get updates, who signs off each milestone and expected reply times on both sides.

A worked example: a small booking web app

Here is a fill-in outline for a fitness studio that wants online bookings. Replace the brackets with your own details.

1. Background and goal

[Studio name] runs [number] classes a week and takes bookings by phone. Goal: customers book and pay online, and staff manage the timetable without needing a developer.

2. Deliverables

Public timetable, class pages, booking and checkout, working on mobile and desktop browsers.
Customer accounts with booking history and cancellation up to [X] hours before a class.
Admin area to add classes, set capacity and view attendee lists.
Card payments through [payment provider].
Source code in [client]'s repository, deployed to [client]'s hosting, with a one-page setup guide.

3. Out of scope

Native mobile apps, memberships and recurring billing, importing old customer records, marketing copy, hosting and payment fees, and support after a [X]-day fix period.

4. Milestones, acceptance and payment

Timetable and accounts. Accepted when a visitor can browse the timetable and create an account. Payment: [amount].
Booking and payments. Accepted when a test customer can book, pay in test mode, receive a confirmation email and cancel within the rules. Payment: [amount].
Admin and launch. Accepted when staff can create a class and see who booked, and the site takes real payments on the live domain. Payment: [amount].

5. Timeline and assumptions

[X] weeks in total. [Client] reviews each milestone within [X] working days. [Client] supplies logo, colours and the class list by [date], and the payment account is approved before milestone 2 starts.

6. Changes and communication

Changes are requested in writing and estimated before any work starts. Written update every [day], a short demo at each milestone, messages answered within one working day.

How the SOW fits with your contract

The SOW says what is being built. Your contract with the developer covers the legal side: who owns the code and designs once paid, confidentiality, warranties and how either side can end the arrangement. Our contracts, IP and NDA checklist lists what to include. DevDey does not write that contract for you, and it does not process payments: you pay the developer directly, and DevDey takes no commission.

What DevDey does give you is a contract in the product split into milestones, which you mark off as work lands. If your SOW already has clear milestones and acceptance criteria, you can copy them straight in.

Tip: Before you sign, ask the developer to rewrite the acceptance criteria in their own words. Any gap between their version and yours is a dispute you have just avoided.

Common mistakes

Vague acceptance. "Fast", "modern" and "user-friendly" cannot be tested. Replace each with something you could check in five minutes with a browser.
No out-of-scope list. Without one, every assumption you made silently becomes part of the price in your head and not in theirs.
Paying everything upfront. You lose your only lever if the work stalls. Paying everything at the end is unfair the other way. Tie payments to accepted milestones and keep the first one small.
No change process. Small extras add up. Our guide to handling scope creep shows how to keep them visible and priced.
Writing the how instead of the what. Describe outcomes. Unless you have a reason, let the developer choose the tools and explain the choice.

If you cannot test it, you cannot accept it. If you cannot accept it, you should not be paying for it yet.

Next steps

Once your SOW is drafted, most of your job post is already written. Post a job for free, and the guided wizard turns your goal and deliverables into a clear post. You can also browse developers without an account, including DevDey-verified profiles. Before you sign, read up on fixed price versus hourly and keep the scope creep guide to hand.

Frequently asked questions

What is the difference between a scope of work and a contract?

A scope of work describes the project itself: deliverables, acceptance criteria, milestones and timeline. The contract covers the legal relationship, such as payment terms, ownership of the code, confidentiality and termination. Many teams attach the SOW to the contract as a schedule.

How long should a scope of work be for a software project?

For a small build, two to four pages is usually enough. Length matters less than whether every deliverable has acceptance criteria someone can test. A longer SOW full of vague wording protects nobody.

Who should write the scope of work, the client or the developer?

The client should draft the goal, deliverables and out-of-scope list, because only they know what the business needs. The developer should then challenge it, add technical assumptions and estimate each milestone. The final version should be agreed by both in writing.

What should be included in acceptance criteria?

Each criterion should describe a specific action and result that a non-developer can check, such as a customer completing a booking and receiving an email. Include which devices or browsers it must work on and how long you have to review it. Avoid subjective words like fast or modern.