A Statement of Work, commonly called an SOW, is one of the most important documents to establish before a software development project begins.

It defines the work that the development company and client are agreeing to perform, the deliverables expected from the project, the responsibilities of each party, the project timeline, commercial terms, acceptance process, change management and other conditions that determine how the engagement will operate.

An SOW is particularly important because software projects involve many moving parts.

There are requirements.

There is product scope.

There are technical specifications.

There are designs.

There are integrations.

There are client dependencies.

There are approvals.

There are testing activities.

There is deployment.

There is handover.

And throughout the project, there will almost certainly be questions about what was actually agreed.

A strong SOW gives everyone a common reference point.

It should make it possible to answer questions such as:

What are we building?

What work is included?

What is not included?

Who is responsible for what?

How much will the project cost?

When are payments due?

What happens when requirements change?

What constitutes completion?

Who owns the software?

What happens after launch?

The exact structure of an SOW varies from project to project and may form part of a larger contract.

The important principle is simple:

Important project commitments should not depend on memory, assumptions or informal conversations.

They should be documented.

This is the eleventh guide in our pre-development documentation series. We introduced the SOW alongside requirements, scope and specifications in our comparison of the four; this guide goes much deeper into what the SOW itself should actually contain — alongside the rest of the series: the documentation checklist, technical documentation, the architecture document, the requirement document, the scope document, acceptance criteria, what information a client should provide, questions to ask before hiring a development company, and how to compare proposals.

---

Quick Answer: What Should a Software Development SOW Include?

A professional software development SOW should generally cover:

SOW Section	What It Defines
Project Overview	What the engagement is about
Business Objective	Why the project is being undertaken
Services	What work the development company will perform
Scope	What is included in the engagement
Out-of-Scope	What is specifically excluded
Deliverables	What the client will receive
Requirements Reference	Which approved requirements govern the work
Technical Work	Architecture, development and technical implementation
Design Work	UI/UX responsibilities and outputs
Integrations	External systems included
Data Migration	Data work included
Infrastructure	Hosting and environment responsibilities
Testing	QA and validation activities
Deployment	Production release responsibilities
Documentation	Documentation deliverables
Handover	What is transferred at completion
Client Responsibilities	Information, approvals and access the client must provide
Development Team Responsibilities	Work the vendor is responsible for
Dependencies	External conditions affecting delivery
Assumptions	Conditions used to establish the plan
Constraints	Known project limitations
Timeline	Expected project schedule
Milestones	Major delivery stages
Acceptance	How work will be reviewed and accepted
Change Management	How additional or changed work is handled
Commercial Terms	Fees and payment structure
Intellectual Property	Ownership and usage rights
Infrastructure Ownership	Who controls production systems and accounts
Support	Post-launch support obligations
Warranty	Treatment of defects after delivery
Termination	What happens if the engagement ends early
Version Control	How changes to the SOW itself are documented

Not every project needs every section as a separate heading.

The goal is not to make the SOW unnecessarily long.

The goal is to remove ambiguity around the obligations and boundaries of the engagement.

---

What Is a Statement of Work?

A Statement of Work describes the work that will be performed under a software development engagement and the conditions under which that work will be delivered.

In practical terms, it connects:

Business need

to

Project scope

to

Services

to

Deliverables

to

Responsibilities

to

Acceptance

to

Commercial terms

An SOW may stand alone or form part of a broader agreement.

A software development contract may contain legal terms, while the SOW provides the project-specific detail.

The exact legal structure depends on how the engagement is organized.

From a project-management perspective, the SOW should answer:

What exactly are the parties agreeing to do?

---

What an SOW Is Not

Understanding what an SOW is not is equally important.

An SOW is not necessarily:

A complete requirements document

Requirements explain what the software needs to do.

A technical architecture document

Architecture explains how the system is structured.

A detailed design document

Design explains interfaces, user experience and visual behaviour.

A project plan

A project plan may go much deeper into tasks and execution.

A quotation alone

A price without scope and delivery conditions is not a sufficiently detailed SOW.

An SOW can reference these documents rather than duplicating everything inside itself.

---

SOW vs Scope Document

These terms are often confused.

A scope document focuses primarily on:

What is included and excluded from the project?

An SOW is broader.

It can include scope but also establish:

• Services
• Deliverables
• Responsibilities
• Timeline
• Commercial terms
• Payment milestones
• Acceptance
• Change management
• Ownership
• Support
• Termination

So:

Scope can be part of an SOW, but an SOW is more than scope.

---

SOW vs Requirements Document

A requirements document answers:

What does the software need to do?

An SOW answers:

What work are the parties agreeing to perform to deliver the software?

For example:

Requirement

Customers can reset their passwords.

SOW

The development team will implement the agreed authentication functionality, including password reset, as part of the Phase 1 application deliverables.

The requirement defines the product need.

The SOW defines the delivery commitment.

---

SOW vs Technical Specification

A technical specification might say:

The application will provide a password reset workflow using the approved authentication mechanism, with defined expiration and validation behaviour.

The SOW might say:

Authentication functionality, including password reset, will be implemented, tested and deployed as part of the agreed project scope.

Technical specification defines the technical detail.

SOW establishes the work commitment.

---

Why an SOW Matters in Software Development

Software development contains uncertainty.

That does not mean the project should be vague.

A good SOW creates clarity around known commitments while making uncertainty visible through assumptions, dependencies and change mechanisms.

Without a clear SOW, common disagreements can arise:

"We thought that was included."

"That wasn't part of the estimate."

"Deployment was supposed to be included."

"We expected the mobile version too."

"We thought data migration was covered."

"We assumed documentation was part of delivery."

The problem is not always dishonesty.

Often, both parties interpreted an incomplete agreement differently.

A detailed SOW reduces that ambiguity.

---

1. Project Overview

The SOW should begin with a concise project description.

Include:

• Project name
• Client
• Development company
• Product or system
• High-level objective
• Project phase
• Intended outcome

The overview should be understandable without requiring the reader to refer to previous meetings.

---

2. Business Objective

The SOW should explain why the project is being undertaken.

For example:

The project aims to provide customers with a self-service portal for managing appointments, reducing reliance on manual booking and support processes.

This provides business context for the engagement.

---

3. Services to Be Performed

This section describes the services the development company will provide.

Potential services include:

• Discovery
• Business analysis
• Product planning
• UX/UI design
• Architecture
• Frontend development
• Backend development
• API development
• Integration development
• Database implementation
• QA
• Security work
• Infrastructure setup
• Deployment
• Documentation
• Handover

Do not simply write:

Full software development services.

That statement is too broad.

The services should be identifiable.

---

4. Project Scope

The SOW should reference or define the agreed project scope.

For example:

Included

• Customer web application
• Administrator dashboard
• Authentication
• Booking
• Payment integration
• Email notifications
• Production deployment

Excluded

• Native mobile applications
• Advanced analytics
• Multi-language support
• AI assistant

The level of detail should be sufficient to prevent major ambiguity.

---

5. Out-of-Scope Work

The exclusions section deserves deliberate attention.

It should identify important work that is not part of the current engagement.

Examples include:

• Native mobile apps
• Additional third-party integrations
• Major data cleansing
• Advanced analytics
• Future product modules
• Ongoing content creation
• Long-term infrastructure operations

Out-of-scope does not mean unimportant.

It means the work is not included in the current commercial commitment.

---

6. Deliverables

The SOW should identify what the client will receive.

For example:

Product deliverables

• Web application
• Admin application
• Backend API

Technical deliverables

• Database
• Deployment setup
• Architecture documentation
• API documentation

Operational deliverables

• Production deployment
• Monitoring setup
• Handover documentation

A deliverable should be specific enough that both sides can identify whether it exists.

---

7. Requirements Reference

The SOW should reference the approved requirements rather than trying to duplicate every detail.

For example:

Product functionality will be implemented according to the approved Software Requirements Document, version X.

This gives the project a controlled source of truth.

Important changes should then go through the agreed change process.

---

8. Technical Responsibilities

The SOW should define the technical work the development team is responsible for.

This can include:

• Architecture
• Frontend
• Backend
• APIs
• Database
• Integrations
• Authentication
• Infrastructure
• Deployment
• Monitoring

The SOW does not need to reproduce the architecture document.

It should establish what technical work is part of the engagement.

---

9. UI/UX Responsibilities

Design responsibilities should be explicit.

The SOW should establish whether the development company is responsible for:

• User research
• Wireframes
• UI design
• Design system
• Prototypes
• Responsive layouts
• Design revisions

It should also state what the client must provide.

For example:

Client will provide final branding assets, logos and brand guidelines.

or:

Design and visual system creation are included as part of the development engagement.

---

10. Integration Responsibilities

Integrations should be described precisely enough to establish boundaries.

For example:

The project includes integration with the client's existing CRM for customer record synchronization.

Then clarify:

• Which data
• One-way or two-way
• Real-time or scheduled
• Error handling
• Historical data
• Authentication

"CRM integration included" is not detailed enough for a complex system.

---

11. Data Migration

If data migration is included, the SOW should describe the responsibility clearly.

It may define:

• Source systems
• Data scope
• Data volume
• Mapping
• Transformation
• Validation
• Migration testing
• Final migration
• Historical records

For example:

The project includes migration of the client-provided customer dataset from the identified legacy system in the agreed format.

That is much clearer than:

Data migration included.

---

12. Infrastructure Responsibilities

Infrastructure responsibilities should be clearly allocated.

The SOW should establish who handles:

• Cloud configuration
• Hosting
• Database
• Storage
• Networking
• DNS
• SSL
• CI/CD
• Monitoring
• Backups

It should also clarify who pays the infrastructure provider.

Development fees and cloud costs should not be confused.

---

13. Environments

The SOW should identify whether the project includes:

• Development
• Testing
• Staging
• Production

It should also clarify who controls those environments.

This becomes important when the project approaches launch.

---

14. Testing and QA

Testing should be explicitly included or excluded.

The SOW may define:

• Functional QA
• API testing
• Integration testing
• Regression testing
• Browser testing
• Mobile testing
• Performance testing
• Security testing

It should also establish whether specialized testing requires a separate engagement.

For example:

Standard application testing is included. Independent penetration testing is excluded unless separately agreed.

That is a clear commercial boundary.

---

15. Deployment

The SOW should state what deployment means.

For example:

The development team will deploy the approved release to the agreed production environment following completion of acceptance testing.

You may also need to clarify:

• Number of production deployments
• App store submission
• Database migration
• DNS configuration
• Rollback
• Monitoring

"Deployment included" can mean very different things between companies.

---

16. Documentation Deliverables

The SOW should identify documentation that will be delivered.

Examples:

• Requirements documentation
• Architecture document
• API documentation
• Database documentation
• Deployment documentation
• Administrator guide
• Handover documentation

Documentation should be treated as a deliverable where it matters to the project.

---

17. Handover

The SOW should define what project handover includes.

Possible handover items:

• Source code
• Repository access
• Infrastructure access
• Database access
• Deployment instructions
• Technical documentation
• Third-party account access
• Monitoring access
• Backup information
• Administrator credentials

The project should not reach the final day and only then start discussing what "handover" means.

For the complete handover framework, including a downloadable checklist covering all 56 items, see our guide to what should be included in a software development handover document.

---

18. Client Responsibilities

A software project depends on the client too.

The SOW should identify client responsibilities such as:

• Providing business requirements
• Providing content
• Providing branding
• Providing API documentation
• Providing credentials
• Reviewing designs
• Approving requirements
• Providing test data
• Making business decisions
• Participating in acceptance testing

The more dependent the project is on client input, the more important this section becomes.

---

19. Development Company Responsibilities

The development company responsibilities should also be explicit.

Examples:

• Requirements analysis
• Architecture
• Development
• QA
• Deployment
• Documentation
• Handover
• Agreed post-launch support

This prevents responsibility from becoming an assumption.

---

20. Third-Party Responsibilities

Some dependencies belong to neither party.

Examples:

• Payment provider
• Hosting provider
• CRM
• ERP
• Cloud service
• AI model provider
• Identity provider

The SOW should acknowledge that third-party availability and behaviour may affect the project.

A development company can implement an integration.

It cannot necessarily control a third-party provider's API changes or outage.

---

21. Project Dependencies

Dependencies should be identified clearly.

Examples:

• API access
• Design approval
• Data delivery
• Third-party configuration
• Cloud account creation
• Client content
• Legal approval

For each important dependency, determine:

• Who owns it
• When it is required
• What happens if it is delayed

---

22. Assumptions

Assumptions should be written explicitly.

Examples:

Client will provide access to the existing CRM.

Client will provide final content before the relevant development stage.

Third-party API credentials will be available before integration begins.

Requirements will remain within the approved scope unless changed through the formal change process.

Assumptions are not excuses.

They are conditions underlying the project plan.

---

23. Constraints

The SOW should identify major constraints.

Examples include:

• Budget
• Timeline
• Existing technology
• Hosting requirements
• Security restrictions
• Legacy infrastructure
• Required third-party systems

Constraints help explain why certain project decisions exist.

---

24. Project Timeline

The SOW should establish the expected project period.

The timeline may include:

• Start date
• Discovery period
• Design period
• Development period
• QA period
• Acceptance period
• Deployment
• Handover

For a fixed-date launch, the SOW should identify client dependencies that could affect that date.

---

25. Milestones

Major milestones should have identifiable outcomes.

For example:

Milestone 1

Requirements and technical planning approved.

Milestone 2

UI/UX approved.

Milestone 3

Core functionality completed.

Milestone 4

Integrations completed.

Milestone 5

QA completed.

Milestone 6

Client acceptance completed.

Milestone 7

Production deployment completed.

Milestones are especially useful when payments are connected to delivery stages.

---

26. Acceptance Process

The SOW should explain how deliverables will be reviewed and accepted.

It should identify:

• Who reviews
• What documents govern acceptance
• How much review time is allowed
• What constitutes rejection
• How defects are handled
• When a milestone becomes accepted

Acceptance criteria should be referenced where they exist.

---

27. Payment Structure

The SOW should clearly establish how payment works.

Possible structures include:

• Initial deposit
• Milestone payments
• Monthly billing
• Time and materials
• Fixed-price phases

A milestone payment should ideally correspond to something identifiable.

For example:

20% upon completion and acceptance of discovery.

rather than:

20% after two months.

A calendar date does not necessarily represent a meaningful project outcome.

---

28. Additional Costs

The SOW should distinguish development fees from external costs.

Potential external costs include:

• Cloud hosting
• Domain
• Email service
• SMS
• Payment processing
• AI APIs
• Analytics
• Third-party software licenses
• App store fees

The client should know who pays these costs.

---

29. Change Management

This is one of the most important SOW sections.

Software projects change.

The SOW should explain how a change becomes an approved project change.

A practical process is:

1. Change request submitted
2. Scope reviewed
3. Technical impact assessed
4. Timeline impact assessed
5. Cost impact assessed
6. Client approves or rejects
7. SOW or change order updated where necessary
8. Work begins

The important principle is:

A meaningful change should not silently enter the project.

---

30. Change Orders

A change order can be used when a proposed change affects the existing commercial agreement.

It may document:

• New work
• Removed work
• Additional cost
• Reduced cost
• Timeline change
• Updated deliverables
• Revised acceptance criteria

This keeps the original SOW intact while making the project evolution visible.

---

31. Intellectual Property

The SOW or related agreement should clarify intellectual property arrangements.

Questions may include:

• Who owns custom source code?
• When does ownership transfer?
• What happens to reusable libraries?
• What third-party components are included?
• Are there open-source components?
• What licenses apply?

This section should align with the actual legal agreement governing the project.

---

32. Source Code Ownership

The SOW should make source-code ownership unambiguous.

Clarify:

• Who owns the repository
• Who has access
• When ownership transfers
• Whether the client receives the full source code
• Whether any components are excluded from transfer

Do not rely on:

"You will own the software."

That statement may still leave important questions unanswered.

---

33. Infrastructure Ownership

The same principle applies to infrastructure.

Clarify ownership and control of:

• Cloud accounts
• Domains
• DNS
• Databases
• Storage
• Monitoring
• CI/CD
• Third-party service accounts

Where practical, client-owned accounts can simplify long-term control.

The actual arrangement should match the project and contractual agreement.

---

34. Third-Party Licenses

The SOW should distinguish custom work from external software.

Potential components include:

• Commercial libraries
• SaaS services
• APIs
• Fonts
• Design assets
• Open-source packages

The client should know which items depend on third-party licensing or ongoing subscriptions.

---

35. Security Responsibilities

Security responsibility should not be described vaguely.

The SOW should establish:

• Who implements application security controls
• Who manages infrastructure
• Who manages production credentials
• Who controls privileged access
• Who is responsible for security testing
• What happens if a third-party dependency creates a vulnerability

The level of detail should reflect the sensitivity of the project.

---

36. Confidentiality and Data Handling

Where the project involves confidential business information or sensitive data, the governing agreement should establish the applicable confidentiality and data-handling obligations.

The SOW can reference those obligations rather than duplicating the entire legal framework.

The important point is to make sure the project-specific responsibilities are understood.

---

37. Warranty and Bug-Fix Period

The SOW should distinguish between:

Defects in delivered functionality

and

New functionality requested after delivery.

For example:

The development team will correct defects that cause delivered functionality to fail to meet the approved requirements during the agreed warranty period.

This is very different from:

All changes are covered after launch.

New features should normally follow the project's change or enhancement process.

---

38. Post-Launch Support

The SOW should explain whether post-launch support is included.

Possible arrangements include:

• No ongoing support
• Defined bug-fix period
• Monthly maintenance
• Retainer
• Managed support
• Incident response

The exact arrangement depends on the project.

It should be documented before launch.

---

39. Service Levels

For projects involving ongoing support, the agreement may define response expectations.

These can cover:

• Critical incidents
• High-priority issues
• Normal defects
• Support requests

Do not assume:

24/7 support.

Ask what response and resolution expectations actually apply.

---

40. Project Delays

The SOW should identify how delays caused by different parties are handled.

For example:

If required client information is delayed, the project schedule may need to move.

If a third-party integration becomes unavailable, the development plan may need to change.

The SOW should establish how these situations are handled rather than leaving them to informal negotiation.

---

41. Termination

The agreement should explain what happens if the project ends before completion.

Questions include:

• How is termination initiated?
• What happens to completed work?
• What happens to in-progress work?
• What payment is due?
• What happens to source code?
• What documentation is transferred?
• What happens to infrastructure?
• How are client data and credentials handled?

This is not pessimism.

It is responsible project planning.

---

42. Project Pause

Projects may also be paused rather than terminated.

A pause may happen because:

• Business priorities changed
• Funding is delayed
• A dependency is unavailable
• The client needs additional time
• The product strategy changed

The SOW should establish how a pause affects:

• Timeline
• Team allocation
• Costs
• Infrastructure
• Project restart

---

43. Force Majeure and External Events

Some events may be outside either party's control.

Depending on the governing agreement, the contract may address events such as:

• Major service outages
• Natural disasters
• Government restrictions
• Significant third-party failures

The SOW should align with the broader contractual terms.

---

44. Version Control for the SOW

Projects change.

Therefore, the SOW itself should have version control.

For example:

SOW v1.0

Original agreement.

SOW v1.1

Updated integration scope.

SOW v1.2

Revised timeline.

The project should be able to determine which version was approved at each stage.

---

45. What Should Never Be Written as "As Agreed"

Some phrases are common but dangerously vague.

Avoid:

Development as discussed.

Better:

Development of the customer portal, administrator dashboard and backend services listed in the approved scope.

Avoid:

Standard testing included.

Better:

Functional, integration and regression testing for the application features included in the approved scope.

Avoid:

Deployment included.

Better:

One production deployment to the client-controlled production environment after successful acceptance testing.

Avoid:

Documentation will be provided.

Better:

The project includes architecture documentation, API documentation and deployment instructions.

Avoid:

Support included.

Better:

The development team will provide defect correction for delivered functionality for the defined post-launch support period.

Avoid:

Integration with CRM included.

Better:

The project includes one-way synchronization of the specified customer and contact data between the application and the identified CRM using the agreed API.

Specific language reduces arguments later.

---

46. A Simple Software Development SOW Structure

A practical SOW can follow this structure:

1. Parties

Client and development company.

2. Project Overview

What is being built and why.

3. Business Objective

Expected business outcome.

4. Services

Work the development company will perform.

5. Scope

Included functionality and work.

6. Out-of-Scope

Explicit exclusions.

7. Deliverables

What will be handed over.

8. Requirements Reference

Approved requirements and supporting documents.

9. Technical Responsibilities

Architecture, development, infrastructure and related work.

10. Design Responsibilities

UI/UX and design scope.

11. Integrations

External systems included.

12. Data

Migration, import and transformation.

13. Testing

QA and validation.

14. Deployment

Production release responsibilities.

15. Documentation

Required documents.

16. Handover

Access, source code and knowledge transfer.

17. Client Responsibilities

Inputs, approvals and dependencies.

18. Development Company Responsibilities

Delivery obligations.

19. Assumptions

Conditions underlying the estimate.

20. Dependencies

External factors affecting delivery.

21. Timeline

Project dates.

22. Milestones

Major delivery stages.

23. Acceptance

Review and acceptance process.

24. Commercial Terms

Fees and payment schedule.

25. Change Management

Change requests and change orders.

26. Ownership

IP, source code, infrastructure and data.

27. Support

Post-launch services.

28. Warranty

Defect correction period.

29. Termination

Early termination process.

30. Version History

Approved SOW changes.

---

Practical Software Development SOW Sample Template

The following is a practical starting template for a software development Statement of Work.

It is intentionally written in plain language. The sections can be expanded or simplified based on the project.

This is a project-document template, not a substitute for legal review.

---

1. Project Information

Project Name: [Project Name]

Client: [Client Legal Name]

Development Company: [Development Company Legal Name]

SOW Version: [Version Number]

SOW Date: [Date]

Expected Start Date: [Date]

Expected Completion Date: [Date]

Project Owner: [Name / Role]

---

2. Project Overview

Project Description

[Briefly describe what is being built and who it is for.]

Business Objective

[Explain the business problem or opportunity the software is intended to address.]

Expected Outcome

[Describe what successful project completion should achieve.]

---

3. Services Included

The development company will provide the following services:

• Discovery and requirements clarification
• Product and functional planning
• UI/UX design
• Software architecture
• Frontend development
• Backend development
• API development
• Database implementation
• Third-party integrations
• Quality assurance and testing
• Deployment
• Technical documentation
• Handover

Remove or modify any service that does not apply to the project.

---

4. Project Scope

In Scope

The project includes:

• [Feature / Module 1]
• [Feature / Module 2]
• [Feature / Module 3]
• [Platform]
• [Integration]
• [Administration functionality]
• [Reporting]
• [Other agreed deliverables]

Out of Scope

The project does not include:

• [Excluded feature]
• [Excluded platform]
• [Additional integration]
• [Advanced functionality]
• [Future-phase functionality]

Any work not expressly included in the agreed scope will be evaluated through the project's change-management process.

---

5. Requirements Reference

The software will be developed according to:

Requirements Document: [Document Name / Version]

Technical Specification: [Document Name / Version]

Architecture Document: [Document Name / Version]

Design Document: [Document Name / Version]

Where these documents are updated through an approved change process, the latest approved version will apply.

---

6. Deliverables

The development company will deliver:

Product

• [Web application]
• [Mobile application]
• [Admin portal]
• [API]
• [Other software]

Technical

• Source code
• Database implementation
• Deployment configuration
• Architecture documentation
• API documentation

Operational

• Production deployment
• Monitoring configuration
• Backup configuration
• Handover documentation

---

7. UI/UX Responsibilities

Development Company

The development company will:

• Create agreed user flows
• Create UI designs
• Implement responsive layouts
• Apply approved design changes

Client

The client will:

• Provide branding assets
• Provide logos and required content
• Review designs
• Provide approvals within the agreed review period

---

8. Technical Scope

The technical implementation includes:

Frontend: [Technology / Platform]

Backend: [Technology / Platform]

Database: [Technology]

Authentication: [Approach]

Infrastructure: [Cloud / Hosting]

APIs: [API approach]

Deployment: [Deployment approach]

The final technical implementation will follow the approved architecture and technical specification.

---

9. Integration Scope

The project includes the following integrations:

Integration 1

System: [System Name]

Purpose: [Purpose]

Data: [Data exchanged]

Direction: [One-way / Two-way]

Method: [API / Webhook / Other]

Integration 2

[Repeat as required.]

Any integration not specifically identified in the agreed scope will be treated as additional work unless otherwise agreed.

---

10. Data Migration

Included

• [Data source]
• [Data type]
• [Approximate volume]
• [Migration process]

Excluded

• [Data cleansing]
• [Historical data]
• [Legacy system cleanup]
• [Other exclusions]

The client is responsible for providing the agreed source data in the required format unless otherwise specified.

---

11. Testing and Quality Assurance

The project includes:

• Functional testing
• Integration testing
• Regression testing
• API testing
• Supported browser testing
• Responsive testing

Additional testing such as independent penetration testing, specialized load testing or third-party certification is:

[Included / Excluded / Separately Quoted]

---

12. Deployment

The development company will:

• Configure the agreed deployment environment
• Deploy the approved release
• Perform agreed production checks
• Complete the agreed production deployment

The deployment includes:

[One / Multiple] production deployments.

The following are excluded unless specifically stated:

• [Infrastructure operations]
• [Ongoing DevOps]
• [App store management]
• [Post-launch environment management]

---

13. Documentation

The project includes the following documentation:

• Requirements documentation
• Architecture documentation
• API documentation
• Deployment documentation
• Administrator documentation
• Handover documentation

Any documentation not listed above is not automatically included.

---

14. Client Responsibilities

The client will be responsible for:

• Providing accurate business requirements
• Providing required content
• Providing branding assets
• Providing system and API access
• Providing third-party credentials
• Reviewing deliverables
• Providing timely approvals
• Providing test data where required
• Making business decisions
• Participating in acceptance testing

Delays in required client inputs may affect the project schedule.

---

15. Development Company Responsibilities

The development company will be responsible for:

• Technical planning
• Architecture
• Development
• Agreed UI/UX work
• Testing
• Deployment
• Documentation
• Handover

The development company will perform the agreed services using the approved project requirements and scope.

---

16. Dependencies

The project depends on:

• [Third-party API availability]
• [Client-provided credentials]
• [Client data]
• [Design approval]
• [Existing system access]
• [Cloud account availability]

Where a dependency is delayed or changed by a party outside the development team's control, the impact on the project schedule and cost will be assessed.

---

17. Assumptions

The project estimate and timeline are based on the following assumptions:

• Client will provide required information within agreed timeframes.
• Required third-party APIs will remain available.
• Approved scope will remain stable unless changed through the agreed process.
• Required design and content will be supplied on time.
• Existing data will be provided in the agreed format.

If a material assumption changes, the project impact may need to be reassessed.

---

18. Milestones

Milestone	Deliverable	Target Date	Acceptance
1	Discovery and requirements	[Date]	Client approval
2	UI/UX	[Date]	Design approval
3	Core development	[Date]	Feature acceptance
4	Integrations	[Date]	Integration acceptance
5	QA	[Date]	QA completion
6	User acceptance	[Date]	Client acceptance
7	Production deployment	[Date]	Production release
8	Handover	[Date]	Handover acceptance

Dates should be reviewed when dependencies or approved scope changes affect the schedule.

---

19. Acceptance

A deliverable or milestone will be considered accepted when:

• The agreed requirements have been implemented.
• Applicable acceptance criteria have been satisfied.
• Required testing has been completed.
• No unresolved critical defects prevent use of the agreed functionality.
• The designated client representative provides approval.

The project should reference the applicable acceptance criteria rather than relying on subjective approval.

---

20. Change Management

Changes to the approved scope will follow this process:

1. Change request submitted.
2. Request reviewed.
3. Technical impact assessed.
4. Timeline impact assessed.
5. Cost impact assessed.
6. Client approves or rejects the change.
7. Relevant project documentation is updated.
8. Approved work is scheduled.

No material scope change should be treated as included simply because it was mentioned informally during a meeting or message.

---

21. Commercial Terms

Total Project Fee: [Amount]

Currency: [Currency]

Payment Schedule:

Payment	Trigger	Amount
1	Project commencement	[Amount]
2	Discovery approval	[Amount]
3	Development milestone	[Amount]
4	QA / UAT	[Amount]
5	Production deployment	[Amount]

Third-party costs such as hosting, APIs, software licenses, payment fees or other external services are:

[Included / Excluded / Billed Separately]

---

22. Intellectual Property and Ownership

The agreement should define ownership of:

• Custom source code
• Design files
• Documentation
• Database
• Project data
• Deployment configuration

The treatment of pre-existing code, reusable components and third-party software should also be stated.

The parties should ensure these provisions are consistent with the governing contract.

---

23. Infrastructure and Account Ownership

The following accounts will be owned or controlled by:

Asset	Owner / Controller
Source Repository	[Party]
Cloud Account	[Party]
Domain	[Party]
DNS	[Party]
Database	[Party]
Storage	[Party]
Monitoring	[Party]
Third-party APIs	[Party]

This section should eliminate ambiguity about who controls production assets after the project.

---

24. Warranty and Post-Launch Support

Warranty Period

[Number] days from production acceptance.

During this period, the development company will address defects where delivered functionality does not meet the approved requirements.

The warranty does not automatically include:

• New features
• Major changes
• New integrations
• Changes caused by third-party systems
• Changes to requirements after acceptance

Post-Launch Support

Support after the warranty period will be:

[Not Included / Available on Request / Monthly Retainer / Managed Support]

---

25. Termination or Project Pause

If the project is paused or terminated, the parties will determine:

• Work completed to date
• Payment due
• Source code transfer
• Documentation transfer
• Infrastructure access
• Data handling
• Outstanding obligations

The exact process should align with the governing agreement.

---

26. Version History

Version	Date	Change	Approved By
1.0	[Date]	Initial SOW	[Names]
1.1	[Date]	[Change]	[Names]
1.2	[Date]	[Change]	[Names]

Only approved versions should be treated as governing project documents.

---

27. Approval

Client

Name: [Name]

Title: [Title]

Signature: __________________

Date: __________________

Development Company

Name: [Name]

Title: [Title]

Signature: __________________

Date: __________________

---

Before Using This Template

Do not copy this template into a contract and assume the project is protected.

Replace every placeholder with project-specific information.

In particular, pay close attention to:

Scope

Exclusions

Deliverables

Client responsibilities

Dependencies

Assumptions

Acceptance criteria

Payment milestones

Ownership

Change management

Support

Termination

These are the areas most likely to create confusion when they are left vague.

For complex projects, the SOW should also be reviewed alongside the applicable commercial agreement and, where appropriate, by qualified legal counsel.

---

Example: A Small Software Project SOW

Consider a business building a customer booking application.

A simplified SOW might define:

Project

Responsive web application for customer appointment booking.

Included

• Customer registration
• Login
• Service browsing
• Appointment booking
• Cancellation
• Email confirmation
• Administrator dashboard
• Basic reporting

Technical

• Frontend application
• Backend API
• Database
• Authentication
• Email integration
• Production deployment

Documentation

• Architecture document
• API documentation
• Deployment instructions
• Handover documentation

Excluded

• Native mobile applications
• SMS notifications
• Advanced analytics
• Loyalty program
• AI assistant

Client responsibilities

• Provide branding
• Provide service information
• Provide email provider access
• Approve designs
• Review acceptance testing

Development company responsibilities

• Design
• Development
• Testing
• Deployment
• Documentation
• Handover

Acceptance

Deliverables are accepted when the approved requirements and acceptance criteria have been satisfied and critical defects are resolved.

That is already far more useful than a one-page proposal saying:

Build booking platform for $X.

---

How Detailed Should an SOW Be?

The SOW should be detailed enough to define the commercial and delivery boundaries without becoming an unnecessary copy of every technical document.

A useful rule is:

The more expensive, complex or risky the project, the more precisely the SOW should define the work.

For a small internal application, a concise SOW may be sufficient.

For a complex enterprise system, the SOW may need to reference multiple supporting documents.

The goal is clarity, not document length.

---

How the SOW Works With Other Project Documents

The SOW should fit into the broader documentation structure.

A useful relationship is:

Business Objective

↓

Requirements

↓

Scope

↓

Specifications

↓

Architecture

↓

SOW

↓

Development

↓

Acceptance

↓

Handover

The SOW does not replace the other documents.

It establishes the formal delivery framework around them.

---

What Happens When the SOW and Requirements Conflict?

This should not be left ambiguous.

The project agreement should establish which documents govern which matters.

For example:

SOW

Controls commercial and contractual commitments.

Scope

Controls project delivery boundaries.

Requirements

Controls product behaviour.

Specifications

Controls detailed technical or functional behaviour.

The exact precedence should be established in the project agreement.

When an inconsistency is discovered, it should be resolved and documented rather than ignored.

---

The Ortem SOW Readiness Framework

At Ortem Technologies, a practical way to judge whether an SOW is ready is to ask six questions:

1. What are we agreeing to build?

The deliverables and scope must be clear.

2. What are we agreeing not to build?

Important exclusions must be explicit.

3. Who is responsible for what?

Client, development company and third-party responsibilities must be defined.

4. What assumptions and dependencies affect delivery?

These should be visible.

5. How will completion be determined?

Acceptance and milestone conditions must be clear.

6. What happens when something changes?

The change-management process must be documented.

If these six questions have clear answers, the SOW is significantly less likely to create avoidable project disputes.

---

SOW Review Checklist Before Signing

Before approving an SOW, review:

Project

• Is the project objective clear?
• Is the product clearly identified?

Scope

• Is everything included clearly described?
• Are important exclusions listed?

Deliverables

• Are final deliverables identifiable?

Technical

• Is the major technical work included?
• Are integrations clearly defined?
• Is infrastructure responsibility clear?

Design

• Is UI/UX work defined?
• Are client-provided assets identified?

Data

• Is migration included or excluded?
• Are data responsibilities clear?

Testing

• What QA is included?
• What specialized testing is excluded?

Deployment

• Is production deployment included?
• Who controls the production environment?

Documentation

• What documentation will be delivered?

Handover

• What access and knowledge will be transferred?

Responsibilities

• What must the client provide?
• What will the development company provide?

Timeline

• Are milestones defined?
• Are dependencies reflected in the schedule?

Commercial

• Is the total fee clear?
• Are payment milestones clear?
• Are external costs identified?

Changes

• Is there a formal change process?

Ownership

• Who owns code?
• Who owns infrastructure?
• Who owns data?
• What third-party licenses apply?

Support

• What happens after launch?
• What constitutes a defect?
• How long is the warranty or support period?

Exit

• What happens if the project is paused or terminated?

If any of these answers are unclear, clarify them before the project begins.

---

Final Takeaway

A Statement of Work is not just paperwork attached to a software project.

It is the document that turns a general intention to build software into a defined delivery commitment.

A strong SOW should make clear:

What the project is.

Why it exists.

What services will be performed.

What is included.

What is excluded.

What will be delivered.

Who is responsible for what.

What assumptions and dependencies exist.

What the timeline and milestones are.

How acceptance works.

How changes are handled.

What the project costs.

How payments work.

Who owns the software and infrastructure.

What documentation and handover will be provided.

What happens after launch.

What happens if the project is paused or terminated.

The most important thing is not making the SOW extremely long.

It is making the important commitments extremely clear.

Statements such as:

Development as discussed.

Testing included.

Deployment included.

Documentation provided.

Support available.

may sound acceptable during a sales conversation.

They are weak project definitions.

A better SOW replaces vague language with specific deliverables, responsibilities and conditions.

At Ortem Technologies, we believe a good SOW should allow both sides to read the document independently and reach the same understanding of what is being delivered.

That is the real test.

Not whether the document is long.

Not whether it looks formal.

Not whether it contains impressive legal language.

The test is whether it answers the practical questions before they become project disputes:

What are we building?

Who is doing what?

What exactly will be delivered?

What is not included?

How will we decide that the work is complete?

What happens when something changes?

Who owns the result?

If those questions are clearly answered, the project has a much stronger foundation before development even begins.

Want an SOW built to this standard for your next engagement? That is the default for every custom software development contract we write.

Get an SOW built this way →