Software development scope of work

SCOPE OF WORK — SOFTWARE DEVELOPMENT

Project: [Project name]
Client: [Client legal entity name]
Supplier: [Your name or studio name]
Prepared: [2026-01-08]  ·  Version: [1.0]
Valid for acceptance until: [2026-01-22]

1. OBJECTIVE
[Client] needs [e.g. "a customer portal where existing account holders
can view invoices, download statements, and update billing details
without contacting support"]. Success is measured by [e.g. "a 30%
reduction in billing-related support tickets within 90 days of launch"],
which this scope aims to enable but does not warrant.

2. IN SCOPE — USER STORIES AND ACCEPTANCE CRITERIA
2.1 Authentication
    As a customer, I can sign in with email and password.
    Accepted when: given a registered email and correct password, the
    user reaches the dashboard; given an incorrect password, an error is
    shown and no session is created; after [5] failed attempts in [15]
    minutes the account is locked for [15] minutes; password reset by
    emailed single-use link expiring in [60] minutes.

2.2 Invoice list
    As a customer, I can see my invoices.
    Accepted when: invoices for the signed-in account only are listed,
    newest first, [25] per page; each row shows number, issue date, due
    date, amount, and status; totals match the source system to the
    cent; no invoice belonging to another account is ever returned.

2.3 Invoice download
    As a customer, I can download an invoice PDF.
    Accepted when: the PDF matches the finance system's copy; download
    links expire after [15] minutes; access is denied for invoices not
    belonging to the signed-in account.

2.4 [Story — e.g. Update billing details]
    Accepted when: [criteria].

2.5 Admin
    As a support agent, I can look up an account and view its invoices
    read-only.
    Accepted when: [criteria], and every lookup is written to an audit
    log with actor, target account, and timestamp.

3. NOT INCLUDED IN THIS SCOPE
3.1 Payments, refunds, and any card handling. The portal is read-only
    with respect to money.
3.2 Single sign-on, SAML, SCIM, and multi-factor authentication.
3.3 Native mobile applications.
3.4 Migration of historical data older than [24] months.
3.5 Changes to [the finance system], which is treated as a read-only
    upstream API.
3.6 Content, copy, translation, and localisation beyond [en-US].
3.7 Load testing, penetration testing, and formal security
    certification. [Supplier] follows the practices in section 7 but is
    not conducting an audit.
3.8 Ongoing hosting costs, monitoring subscriptions, and support after
    the warranty period in section 9.

4. TECHNICAL BASELINE
4.1 Stack: [framework, language, database, hosting platform].
4.2 Supported browsers: current and previous major versions of Chrome,
    Safari, Firefox, and Edge; iOS Safari and Android Chrome on the two
    most recent OS versions. Anything older is out of scope.
4.3 Environments: local, staging, and production. [Client] owns the
    accounts and pays the bills; [Supplier] configures them and holds
    access for the duration of the project.
4.4 Automated tests: unit tests for business logic, plus end-to-end
    tests covering the happy path of each story in section 2.
4.5 Source control in [Client]'s [GitHub] organisation from day one, so
    ownership is never in question.

5. ACCEPTANCE AND UAT
5.1 Each milestone is deployed to staging with release notes listing the
    stories included.
5.2 [Client] has a [10] business day UAT window per milestone.
5.3 A story is accepted when its criteria in section 2 pass, or when the
    UAT window closes without a written defect report.
5.4 Defect severities and response times during UAT and warranty:
    · S1 — Feature unusable, no workaround. Response [1] business day.
    · S2 — Major function impaired, workaround exists. Response [2]
      business days.
    · S3 — Minor issue, cosmetic or edge case. Fixed in the next
      scheduled release.
    · S4 — Change request. Not a defect. Quoted under section 8.
5.5 A report that the software does something the criteria never
    described is an S4, not an S1.

6. CLIENT RESPONSIBILITIES
6.1 Named product owner: [name], [title], available for [2] hours a week
    and empowered to make decisions.
6.2 API credentials, test accounts, and sample data by [date].
6.3 UAT testers available within the windows in 5.2.
6.4 Delays in the above move the dates in section 9 day-for-day; delays
    beyond [10] business days may require re-booking at $[110.00]/hour.

7. SECURITY AND DATA
7.1 Secrets are stored in [secret manager], never in source control.
7.2 Data in transit uses TLS; data at rest uses the platform's
    encryption.
7.3 Every query touching customer data is scoped to the signed-in
    account, and this is covered by an automated test.
7.4 [Supplier] processes [Client]'s data only to deliver this project,
    under [the DPA dated [date]], and deletes working copies within [30]
    days of handover.

8. CHANGE CONTROL
8.1 Changes are quoted in writing as a change request with an hour
    estimate and a schedule impact.
8.2 No work starts on a change request until [Client] approves it in
    writing.
8.3 If an approved estimate is going to be exceeded by more than [10]%,
    work stops and re-approval is sought.

9. MILESTONES, FEES, AND WARRANTY
9.1 M1 — Discovery, architecture, environments, CI.  $[4,000.00]
    M2 — Stories 2.1–2.3.                            $[6,000.00]
    M3 — Stories 2.4–2.5, launch, handover.          $[5,000.00]
9.2 Each milestone is invoiced on acceptance, Net [30].
9.3 Hourly rate for approved change requests: $[110.00].
9.4 Warranty: for [30] days after production launch, [Supplier] fixes
    S1–S3 defects at no charge. The warranty does not cover new
    requirements, third-party service failures, changes made by others,
    or environments outside 4.2.

10. INTELLECTUAL PROPERTY
Custom application code written for this project transfers to [Client]
on payment in full. Open-source components remain under their own
licences. [Supplier]'s pre-existing libraries and boilerplate are
licensed to [Client] perpetually, worldwide, and royalty-free for use in
this project, and are not assigned.

11. ACCEPTANCE OF THIS SCOPE

[Client]                          [Supplier]
Name: ______________________      Name: ______________________
Signature: _________________      Signature: _________________
Date: ______________________      Date: ______________________