Scope of Work Template for Software Development

Software development is expensive. A medium-complexity web application costs anywhere from £10,000 to £100,000+. At those price points, building without a scope of work is building without a foundation.

The consequences are familiar: the client requests features that were never discussed, the developer builds something the client did not expect, timelines stretch from months to years, and budgets double. These problems are not caused by bad developers or unreasonable clients — they are caused by undefined scope.

A scope of work for software development defines what is being built, with which technologies, to what level of quality, on what timeline, and who owns the result. It is the most important document in any software project.

This guide covers every section your software development SOW needs, explains common pitfalls, and provides a complete template.

Why Software Projects Fail Without a SOW

The Standish Group’s research consistently shows that the majority of software projects exceed their budget, run over schedule, or deliver fewer features than planned. The primary causes are not technical — they are scope-related:

• Requirements were not fully understood before development began
• Scope changed continuously with no change control process
• Stakeholder expectations differed from what was documented (or nothing was documented)
• Testing and deployment were afterthoughts, not planned deliverables
• “Done” was never defined, so the project never ended

A thorough SOW addresses every one of these problems. It forces both parties to think through the project before writing a single line of code.

Essential Sections for a Software Development SOW

1. Project Overview and Objectives

Describe what the software will do and why it needs to exist. This section should be understandable by a non-technical stakeholder.

Include:

• The business problem the software solves
• The target users
• The high-level capabilities (not detailed features yet — that comes later)
• Success criteria (how both parties will know the project succeeded)
• Any constraints (budget ceiling, hard launch date, regulatory requirements)

2. Technology Stack

Document every technology decision:

Frontend:

• Framework (React, Vue, Angular, Svelte, etc.)
• CSS framework or component library
• State management approach

Backend:

• Language and framework (Node.js/Express, Python/Django, Ruby/Rails, Go, etc.)
• API architecture (REST, GraphQL)
• Authentication method (JWT, OAuth 2.0, session-based)

Database:

• Database system (PostgreSQL, MySQL, MongoDB, etc.)
• ORM or query builder
• Migration strategy

Infrastructure:

• Hosting platform (AWS, Azure, GCP, Vercel, etc.)
• CI/CD pipeline
• Monitoring and logging tools
• CDN and caching strategy

Third-party services:

• Payment processing (Stripe, PayPal)
• Email service (SendGrid, SES)
• File storage (S3, Cloudflare R2)
• Any other APIs or integrations

Why does this matter? Because technology choices have long-term cost implications. If the client later wants to hire an in-house team, they need to hire developers who know the chosen stack. If the project uses a niche framework, that hiring pool is smaller and more expensive.

3. Features and User Stories

This is the core of the SOW. There are two approaches:

Feature list approach (simpler projects):

Feature	Description	Priority
User registration	Email/password signup with email verification	Must have
User login	Email/password login with session management	Must have
Password reset	Forgot password flow via email	Must have
User profile	Edit name, email, avatar	Must have
Dashboard	Overview of user’s data with charts	Must have
Export data	Download data as CSV	Should have
Dark mode	Toggle between light and dark UI	Nice to have

User story approach (complex projects):

Each feature is broken into user stories following the format: “As a [user type], I can [action] so that [benefit].”

Epic: User Authentication

• As a new user, I can create an account with my email and a password so that I can access the platform
• As a registered user, I can log in with my email and password so that I can access my account
• As a logged-in user, I can log out so that my session is terminated
• As a user who forgot my password, I can request a password reset email so that I can regain access to my account
• As an admin, I can view all registered users so that I can manage the user base

Each user story should include acceptance criteria — specific conditions that must be true for the story to be considered complete.

Use MoSCoW prioritisation:

• Must have: Features required for launch. The project fails without them.
• Should have: Important features that can be added shortly after launch if needed.
• Could have: Desirable features that improve the product but are not critical.
• Won’t have (this phase): Features explicitly excluded from this scope but noted for future phases.

The “Won’t have” list is as important as the “Must have” list. It prevents assumptions about what is included.

4. Environments

Software projects need multiple environments. Specify each:

• Development: Where active development happens. Accessible only to the development team.
• Staging: A production-like environment for testing and client review. Updated before each milestone delivery.
• Production: The live environment used by end users. Only updated through the deployment process.

Include:

• Who has access to each environment
• How deployments are triggered (manual, automated CI/CD)
• Environment-specific configurations (API keys, database connections)
• Data management (is staging data real or synthetic?)

5. Testing and Quality Assurance

Define the testing strategy:

Unit testing:

• Minimum code coverage percentage (e.g., 80%)
• Testing framework (Jest, PyTest, RSpec, etc.)
• What is and is not covered by unit tests

Integration testing:

• API endpoint testing
• Database query testing
• Third-party service integration testing

End-to-end testing:

• Critical user flows that must be tested (registration, checkout, etc.)
• Testing tool (Cypress, Playwright, Selenium)
• Browser and device coverage

User acceptance testing (UAT):

• Who performs UAT (client, end users, or both)
• UAT environment (staging)
• How bugs are reported and tracked
• UAT duration and sign-off process

Performance testing:

• Load testing requirements (e.g., must handle 1,000 concurrent users)
• Page load time targets (e.g., under 3 seconds on 4G)
• Stress testing scenarios

Security testing:

• OWASP Top 10 compliance
• Penetration testing (included or excluded)
• Data encryption requirements (at rest and in transit)

6. Documentation

Specify what documentation is delivered:

• Technical documentation: Architecture overview, API reference, database schema
• Deployment documentation: Step-by-step deployment guide for each environment
• User documentation: End-user guides or in-app help (if applicable)
• Admin documentation: How to manage users, configure settings, and troubleshoot
• Code documentation: Inline code comments and README files

Documentation is often treated as an afterthought. If it is listed as a deliverable in the SOW, it gets done. If it is not, it does not.

7. Deployment

Define the deployment process:

• How code gets from development to production (CI/CD pipeline, manual deployment)
• Who has deployment access
• Rollback procedure (what happens if a deployment introduces a critical bug)
• Deployment schedule (continuous, weekly, milestone-based)
• Domain and DNS configuration (who manages this)
• SSL certificate setup

8. Timeline and Milestones

Break the project into phases with measurable deliverables:

Phase	Duration	Deliverables	Payment Milestone
Discovery	2 weeks	Technical spec, wireframes, project plan	20% deposit
Phase 1: Core Features	4 weeks	User auth, dashboard, core CRUD	20% on milestone delivery
Phase 2: Advanced Features	4 weeks	Integrations, reporting, exports	20% on milestone delivery
Phase 3: Polish and Testing	2 weeks	UAT fixes, performance optimisation	20% on milestone delivery
Launch	1 week	Production deployment, monitoring setup	20% on go-live

Each milestone should include:

• A demo or review meeting with the client
• Client approval before proceeding to the next phase
• A clear list of what “complete” means for that phase

9. Maintenance and Support Period

Define post-launch support:

Warranty period (typically 30-90 days):

• Bug fixes at no additional cost
• A bug is defined as: the software does not behave as specified in this SOW
• A bug is not: a feature request, a design change, a change to requirements, or an issue caused by a third-party service
• Response time: critical bugs within 4 hours, non-critical within 24 hours

Post-warranty support (optional, quoted separately):

• Monthly retainer for ongoing maintenance
• Hourly rate for ad-hoc changes
• Service Level Agreement (SLA) with uptime guarantees

10. Intellectual Property and Ownership

This section has legal implications. Be precise:

Client owns:

• All custom application code written specifically for this project
• All custom designs, graphics, and UI elements
• The database and all stored data
• All documentation

Developer retains:

• The right to reuse general-purpose code, utilities, and libraries developed independently
• Open-source contributions made during the project
• Knowledge and expertise gained (no non-compete on technology)

Third-party code:

• Open-source libraries remain subject to their licences (MIT, Apache, GPL, etc.)
• Third-party APIs and services remain subject to their terms of service
• Licensed software (if any) requires the client to maintain their own licence

IP transfer timing: Ownership transfers upon receipt of final payment. Until full payment, all work remains the developer’s property.

11. Communication and Project Management

• Project management tool: [Jira, Linear, Trello, Asana, GitHub Issues]
• Communication channels: [Slack, email, scheduled video calls]
• Status updates: [Weekly written update every Friday / Daily standup notes in Slack]
• Review meetings: [Bi-weekly video call, 30 minutes]
• Decision authority: Who on the client side can approve features, designs, and milestones

12. Payment Terms

Milestone	Percentage	Amount	Trigger
Project start	20%	£[amount]	Upon signing SOW
Discovery complete	—	—	Included in deposit
Phase 1 delivery	20%	£[amount]	Phase 1 milestone approved
Phase 2 delivery	20%	£[amount]	Phase 2 milestone approved
Phase 3 delivery	20%	£[amount]	Phase 3 milestone approved
Launch	20%	£[amount]	Production deployment

Total project fee: £[amount] Payment method: Bank transfer Payment terms: Due within 14 days of invoice Late payment: 2% monthly interest Cancellation: Client pays for all completed phases plus 25% of the current incomplete phase

Full Software Development Scope of Work Template

---

SCOPE OF WORK — SOFTWARE DEVELOPMENT PROJECT

Date: [Date] Reference: [SD-2026-001]

Client: [Client Business Name] Contact: [Name, Email, Phone]

Developer: [Your Business / Agency Name] Contact: [Name, Email, Phone]

---

1. Project Summary

[Developer] will design, develop, test, and deploy [brief description — e.g., “a web-based project management application”] for [Client]. The application will [one-sentence description of core purpose].

Project Duration: [Start date] to [Estimated end date] Total Fee: £[Amount]

---

2. Technology Stack

Layer	Technology
Frontend	[React / Vue / Angular / Next.js]
Backend	[Node.js / Python / Go / Ruby] + [Express / Django / Gin / Rails]
Database	[PostgreSQL / MySQL / MongoDB]
Hosting	[AWS / Azure / GCP / Vercel / Cloudflare]
CI/CD	[GitHub Actions / GitLab CI / CircleCI]
Authentication	[JWT / OAuth 2.0 / Auth0 / Clerk]
Payments	[Stripe / PayPal / none]
Email	[SendGrid / SES / Resend]
File Storage	[S3 / R2 / local]

---

3. Features

Must Have (Required for Launch):

ID	Feature	Description	Acceptance Criteria
F1	User registration	Email/password signup	User receives verification email, can verify and log in
F2	User login	Email/password auth	Valid credentials grant access, invalid show error
F3	[Feature]	[Description]	[Criteria]
F4	[Feature]	[Description]	[Criteria]

Should Have (High Priority, Post-Launch OK):

ID	Feature	Description
F10	[Feature]	[Description]
F11	[Feature]	[Description]

Won’t Have (Excluded from This Phase):

• [Feature explicitly excluded]
• [Feature explicitly excluded]

---

4. Environments

Environment	Purpose	URL	Access
Development	Active development	localhost / dev server	Dev team only
Staging	Client review and UAT	[staging URL]	Dev team + client
Production	Live users	[production URL]	Public

---

5. Testing

• Unit test coverage: minimum [80]%
• Integration tests for all API endpoints
• End-to-end tests for critical user flows: [list flows]
• UAT period: [2] weeks on staging environment
• UAT bugs tracked in [tool] and resolved before launch
• Performance: Application must load in under [3] seconds and handle [X] concurrent users

---

6. Documentation

Delivered with the final project:

• Technical architecture document
• API documentation (auto-generated from code + manual additions)
• Database schema documentation
• Deployment guide (step-by-step)
• Admin user guide
• [End-user guide / in-app help]

---

7. Timeline

Phase	Weeks	Deliverables	Client Review
Discovery & Planning	[2]	Tech spec, wireframes, project plan	Review and approve
Phase 1: [Name]	[4]	[Features F1-F4]	Demo + approval
Phase 2: [Name]	[4]	[Features F5-F9]	Demo + approval
Testing & QA	[2]	Full test suite, UAT	UAT participation
Deployment & Launch	[1]	Production go-live	Final sign-off

Total estimated duration: [13] weeks

---

8. Post-Launch Support

Warranty period: [60] days from launch

• Bug fixes at no additional cost
• Bug = software does not meet specifications in this SOW
• Not a bug = feature requests, design changes, third-party issues
• Critical bug response: [4] hours
• Non-critical bug response: [1] business day

Ongoing support (optional):

• Available at [£rate/hour] or [£rate/month] retainer
• Separate agreement required

---

9. Intellectual Property

• Upon full payment, [Client] owns all custom code, designs, and documentation
• [Developer] retains rights to reuse general-purpose libraries and utilities
• Open-source dependencies retain their original licences
• Until full payment, all IP remains with [Developer]
• [Developer] may reference the project in their portfolio (without revealing confidential business logic)

---

10. Communication

• Project tool: [Linear / Jira / GitHub Issues]
• Chat: [Slack channel / email]
• Status updates: Weekly written summary every [Friday]
• Review meetings: Bi-weekly, [30] minutes, via [Zoom / Google Meet]
• Client decision maker: [Name] — all approvals and priority decisions

---

11. Payment

Milestone	Amount	Trigger
Deposit	[20%] — £[amount]	SOW signed
Phase 1 complete	[20%] — £[amount]	Phase 1 approved
Phase 2 complete	[20%] — £[amount]	Phase 2 approved
Testing complete	[20%] — £[amount]	UAT sign-off
Launch	[20%] — £[amount]	Production deployment

Total: £[amount] Payment method: Bank transfer / [other] Terms: Due within [14] days of invoice Late payment: [2]% per month Cancellation: All completed phases billed in full + [25]% of current phase

---

12. Change Requests

1. Either party submits a change request in [project tool]
2. [Developer] estimates the impact on timeline and budget within [3] business days
3. Client approves or declines in writing
4. Approved changes are added to the SOW as an amendment
5. [Optional: X% of total budget reserved as a change budget]

---

Signatures

Client: _________________________ Date: _____________

Developer: _________________________ Date: _____________

---

Common Mistakes in Software Development SOWs

Not defining “done.” Without acceptance criteria, every feature is subject to interpretation. “User authentication” could mean email/password login or it could mean SSO with Google, Apple, Facebook, and magic links. Be specific about what done looks like.

Skipping the “won’t have” list. Clients assume features are included unless told otherwise. If you are building an e-commerce platform and the client expects AI-powered product recommendations but you are building basic category filtering, that needs to be in the “won’t have” list.

No change budget. Requirements will change. That is the nature of software development. Instead of pretending they will not, reserve 10-15% of the budget for approved changes. This gives both parties flexibility without blowing up the project.

Underestimating testing. Testing is not something that happens in the last week. It should be woven through the entire project. Your SOW should allocate 20-30% of the timeline to testing and QA.

Vague IP terms. “The client owns everything” sounds straightforward until the developer has used a utility library they built for previous clients. Define what the client owns (custom application code) and what the developer retains (general-purpose tools and pre-existing IP).

Connecting to Related Documents

Your SOW is the foundation. From it, you build:

• Invoices tied to each milestone — use our contractor invoice template as a starting point
• Change request documents for scope changes
• Technical specifications that expand on the feature descriptions

For the fundamentals of scoping any project, see our how to write a scope of work guide. For examples across industries beyond software, browse our scope of work examples collection.