Project Scoping Contracts | SOW, Milestones, Acceptance Criteria | California

Q: What's the best way to define acceptance criteria for software?

Make acceptance criteria binary and testable. Instead of 'the app should be fast,' write 'pages load within 3 seconds on 4G connection.' Reference specific user stories or requirements documents. Limit acceptance review to scope compliance, not subjective preferences.

California Law Focus for Project Scoping

California law provides specific remedies and deadlines that affect how you structure payment terms and enforce project contracts. Understanding these rules helps you write stronger SOWs and collect payment faster.

Civil Code 3287/3289 - Prejudgment Interest

Under CC 3287(a), you're entitled to 10% annual prejudgment interest on contract damages from the day the amount becomes due. For unpaid invoices with a specific amount (liquidated damages), interest accrues automatically. Include this in your payment terms to incentivize timely payment and increase recovery if you litigate.

California Prompt Payment Act

While primarily applicable to government contracts and construction, the Prompt Payment Act principles influence commercial payment practices. Private contracts commonly adopt 30-day payment terms. Late payments give you leverage to pause work, withhold deliverables, or accelerate collection. Your SOW should specify payment deadlines and consequences for late payment.

CCP 337 - 4-Year Statute of Limitations

Written contracts in California have a 4-year statute of limitations (CCP 337). Oral contracts only get 2 years (CCP 339). This is why you ALWAYS want a written SOW: you have twice as long to enforce it. The clock starts when the breach occurs - typically when payment was due or when deliverables should have been accepted.

Payment Default Strategy If a client misses a milestone payment: (1) Send written notice demanding payment within 10 days, (2) Suspend further work until paid, (3) Document the default date for interest calculation, (4) Reserve the right to retain deliverables until payment. Your SOW should authorize all of these actions.

Statement of Work Essentials

A Statement of Work (SOW) defines what you're building, how long it takes, how much it costs, and how the client accepts delivery. It's the single most important document for preventing scope disputes.

Required SOW Elements

Project Description: High-level summary of what you're building and why
Scope of Work: Detailed list of features, functionality, and deliverables
Out of Scope: Explicit list of what's NOT included (prevents scope creep)
Deliverables: Specific items you'll hand over (code, documentation, assets)
Timeline: Project phases with start/end dates
Milestones: Key checkpoints with acceptance criteria
Pricing: Total cost, payment schedule, invoicing terms
Acceptance Process: How client reviews and approves deliverables
Assumptions: What must be true for estimates to hold (client availability, API access, etc.)
Change Order Process: How to handle scope changes

SOW vs. MSA Relationship

If you have a Master Services Agreement (MSA), your SOW should reference it. The MSA contains general terms (IP ownership, liability, confidentiality), while the SOW contains project-specific details. The SOW typically says "governed by the MSA dated [X]" and addresses conflicts by specifying which document controls.

Pro Tip: Standalone vs. MSA+SOW For one-time projects, use a standalone project agreement that includes both general and project-specific terms. For ongoing client relationships, use MSA + multiple SOWs. The MSA+SOW structure lets you start new projects faster without renegotiating payment terms and liability caps each time.

Fixed-Price vs. T&M vs. Hybrid Structures

Your pricing model determines risk allocation. Fixed-price puts risk on you (scope creep eats your margin). Time & Materials puts risk on the client (costs can balloon). Hybrid structures balance both.

Model	Best For	Risk Profile	SOW Requirements
Fixed-Price	Well-defined scope, clear requirements	Agency bears overrun risk	Ultra-detailed scope, explicit exclusions
Time & Materials (T&M)	Evolving requirements, R&D, discovery	Client bears cost uncertainty	Hourly rates, estimate range, weekly reporting
Capped T&M	Uncertain scope with budget constraints	Shared risk up to cap	T&M rates + not-to-exceed amount
Fixed + T&M Phases	Discovery phase + implementation	Risk shifts per phase	Separate pricing for each phase
Retainer	Ongoing support, maintenance	Predictable for both parties	Monthly hours, rollover policy, overage rates

Choosing the Right Model

Fixed-Price: Use when scope is crystal clear, you've built similar projects before, and the client has finalized requirements. Pad estimates by 20-30% for unknowns.
T&M: Use for early-stage startups, R&D projects, or when requirements will evolve. Require weekly status reports and burn rate updates.
Hybrid: Start with T&M discovery/design phase, then switch to fixed-price for implementation once scope is defined.

Fixed-Price Warning Never agree to fixed-price on vague requirements. If the client can't articulate exactly what they want, use T&M for discovery first. Unclear scope + fixed-price = guaranteed disputes.

Milestone Payment Schedules

Milestone payments align cash flow with project progress. You get paid as you deliver, reducing financial risk. Clients pay for value received, reducing their risk of paying for unfinished work.

Typical Milestone Structures

Milestone	Payment %	Deliverable
Project Kickoff	20-30%	Signed SOW, project plan
Design Complete	15-25%	Wireframes, UI designs, architecture docs
Development Complete	25-35%	Feature-complete code in staging
UAT Complete	15-20%	Client testing sign-off
Go-Live/Final Delivery	10-15%	Production deployment, source code

Milestone Best Practices

Front-load payments: Never have more than 15% at final delivery. You want to be mostly paid before the client has all deliverables.
Tie to client actions: "Design Complete" means client has approved designs. Make acceptance explicit.
Include auto-acceptance: "Deliverable is deemed accepted if Client provides no written objection within 5 business days."
Reserve code until paid: "Source code delivered to Client's repository upon receipt of final payment."

Acceptance Criteria Best Practices

Acceptance criteria define what "done" looks like. Without clear criteria, clients can reject deliverables indefinitely or withhold payment based on subjective complaints. Objective, testable criteria protect you.

Writing Testable Acceptance Criteria

Be specific: "User can log in" is vague. "User can log in with email/password, receiving a session token valid for 24 hours" is testable.
Define test conditions: "Shopping cart calculates tax correctly" + "using California tax rates for shipping addresses in CA."
Set performance thresholds: "Page loads within 3 seconds on desktop Chrome with 10Mbps connection."
Specify browser/device support: "Responsive design supporting Chrome, Safari, Firefox (latest 2 versions) and iOS/Android mobile browsers."
Reference requirements doc: "Acceptance criteria per Requirements Document v2.1 attached as Exhibit A."

Acceptance Process

Delivery notice: You notify client that milestone is ready for review
Review period: Client has X business days to test against acceptance criteria
Accept or reject: Client must provide written acceptance OR specific deficiency list
Cure period: You fix deficiencies within Y days, re-submit
Auto-acceptance: If client doesn't respond within review period, deliverable is accepted
Payment trigger: Acceptance triggers milestone payment due date

Scope vs. Quality Acceptance criteria should test whether you built what was specified (scope), not whether the client likes it (subjective). "Button should be blue" is scope. "Design should be beautiful" is subjective and unenforceable.

"Definition of Done" Language

A Definition of Done (DoD) is a checklist that every deliverable must pass before it's considered complete. It's borrowed from Agile methodology but works in any project structure. Including DoD in your SOW sets clear expectations for code quality.

Typical Definition of Done Checklist

Code compiles without errors
All unit tests pass
Code reviewed by at least one other developer
No known high-severity bugs
Documentation updated (API docs, README)
Feature deployed to staging environment
Acceptance criteria verified in staging
Performance meets specified thresholds
Security scan shows no critical vulnerabilities

DoD in Contracts

Include DoD as an exhibit to your SOW. This accomplishes two things: (1) clients know what quality standards to expect, and (2) you have objective criteria to point to if clients claim deliverables are "not done." You can also exclude items from DoD explicitly (e.g., "Security penetration testing not included in DoD for this project").

Sample Contract Clauses

Copy these California-compliant clauses into your SOWs and project agreements. Each is designed to protect your interests while remaining fair to clients.

Fixed-Price Milestone Payment Table

PAYMENT SCHEDULE

The total fixed price for the Project is $[AMOUNT]. Payments shall be made according to the following milestone schedule:

| Milestone                | Amount      | Due Upon                           |
|--------------------------|-------------|-------------------------------------|
| Project Kickoff          | $[XX,XXX]   | Execution of this SOW              |
| Design Approval          | $[XX,XXX]   | Client approval of design mockups  |
| Development Complete     | $[XX,XXX]   | Feature-complete code in staging   |
| User Acceptance Testing  | $[XX,XXX]   | Client sign-off on UAT             |
| Final Delivery           | $[XX,XXX]   | Production deployment complete     |

TOTAL:                      $[AMOUNT]

All invoices are due within fifteen (15) days of invoice date. Late payments shall accrue interest at ten percent (10%) per annum pursuant to California Civil Code Section 3289.

Acceptance Criteria Clause

ACCEPTANCE PROCESS

(a) Delivery Notice. Upon completion of each Milestone deliverable, Developer shall provide Client written notice that the deliverable is ready for acceptance review.

(b) Review Period. Client shall have five (5) business days from receipt of Delivery Notice to review the deliverable against the applicable Acceptance Criteria set forth in Exhibit A.

(c) Acceptance or Rejection. Within the Review Period, Client shall provide written notice either (i) accepting the deliverable, or (ii) rejecting the deliverable with a detailed list of specific deficiencies referencing the Acceptance Criteria not met.

(d) Cure Period. If Client rejects a deliverable, Developer shall have ten (10) business days to cure the identified deficiencies and resubmit.

(e) Deemed Acceptance. If Client fails to provide written acceptance or rejection within the Review Period, the deliverable shall be deemed accepted.

(f) Scope of Review. Rejection may only be based on failure to meet the specific Acceptance Criteria. Requests for changes to scope, features, or functionality not specified in the Acceptance Criteria shall be handled through the Change Order process.

Definition of Done Language

DEFINITION OF DONE

A deliverable shall be considered "Done" when it meets all of the following criteria:

1. CODE QUALITY
   - Code compiles and builds without errors
   - All automated unit tests pass with 80% or greater code coverage
   - Code has been peer-reviewed by at least one other developer
   - No known Severity 1 (Critical) or Severity 2 (High) bugs

2. DOCUMENTATION
   - API documentation is complete and accurate
   - README file updated with setup and deployment instructions
   - Inline code comments for complex logic

3. DEPLOYMENT
   - Successfully deployed to staging environment
   - All features functional in staging environment
   - Performance meets thresholds specified in Exhibit A

4. SECURITY
   - No critical or high-severity vulnerabilities per automated security scan
   - Authentication and authorization functioning as specified

Items explicitly excluded from Definition of Done for this Project: [LIST EXCLUSIONS OR "None"]

Payment Terms with California Late Fee

PAYMENT TERMS

(a) Invoicing. Developer shall invoice Client upon achievement of each Milestone as set forth in the Payment Schedule. Invoices shall be sent via email to [CLIENT EMAIL].

(b) Payment Due Date. All invoices are due and payable within fifteen (15) days of invoice date ("Due Date").

(c) Late Payment Interest. Any amount not paid by the Due Date shall bear interest at the rate of ten percent (10%) per annum from the Due Date until paid in full, pursuant to California Civil Code Sections 3287 and 3289.

(d) Work Suspension. If any invoice remains unpaid for more than ten (10) days past the Due Date, Developer may, upon five (5) days' written notice, suspend all work on the Project until payment is received. Such suspension shall not constitute breach by Developer and shall extend all Project deadlines by the duration of the suspension.

(e) Deliverable Retention. Developer shall not be obligated to deliver source code, documentation, or other Project deliverables until all outstanding invoices are paid in full.

(f) Collection Costs. Client shall pay all costs of collection, including reasonable attorneys' fees, incurred by Developer in collecting overdue amounts.

Out-of-Scope Work Clause

OUT-OF-SCOPE WORK

(a) Scope Definition. The scope of the Project is limited to the deliverables and functionality expressly described in this Statement of Work. Any work, features, or functionality not explicitly included is out of scope.

(b) Explicit Exclusions. The following items are explicitly OUT OF SCOPE for this Project:
    - [LIST SPECIFIC EXCLUSIONS, e.g., "Mobile native apps"]
    - [e.g., "Third-party API integrations beyond those specified"]
    - [e.g., "Content creation, copywriting, or data entry"]
    - [e.g., "Ongoing maintenance after Warranty Period"]
    - [e.g., "Training beyond the sessions specified in Section X"]

(c) Change Order Required. Any request by Client for work outside the defined scope shall require a written Change Order signed by both parties before Developer is obligated to perform such work.

(d) No Implied Features. Developer shall not be required to implement features that are "industry standard," "obviously necessary," or "implied" unless such features are expressly listed in the Scope of Work or Acceptance Criteria.

(e) Out-of-Scope Pricing. Out-of-scope work requested via Change Order shall be priced at Developer's then-current hourly rate of $[RATE]/hour, or as otherwise agreed in the Change Order.

Project Timeline Clause

PROJECT TIMELINE

(a) Schedule. The Project shall be completed according to the following schedule:

    Phase 1 - Discovery & Design:     [START DATE] - [END DATE] ([X] weeks)
    Phase 2 - Development:            [START DATE] - [END DATE] ([X] weeks)
    Phase 3 - Testing & QA:           [START DATE] - [END DATE] ([X] weeks)
    Phase 4 - Deployment & Launch:    [START DATE] - [END DATE] ([X] weeks)

    Estimated Project Completion:     [DATE]

(b) Client Dependencies. The timeline assumes Client will meet the following obligations within the timeframes specified:
    - Provide all content, assets, and brand materials within [X] days of request
    - Respond to questions and requests for clarification within [X] business days
    - Complete review of deliverables within the Review Period specified
    - Provide access to required systems, APIs, and accounts by [DATE]

(c) Timeline Extensions. The Project timeline shall be extended day-for-day for any delays caused by:
    - Client's failure to meet the obligations in subsection (b)
    - Changes to scope requested by Client via Change Order
    - Force majeure events beyond Developer's reasonable control

(d) Schedule Not Guaranteed. All dates are estimates based on information available at SOW execution. Developer shall use commercially reasonable efforts to meet the schedule but does not guarantee specific completion dates unless expressly stated as "firm deadlines."

SOW Generator

Generate a customized Statement of Work using our interactive tool. Fill in your project details, select your pricing model, and download a California-compliant SOW.

Statement of Work Generator

Create a complete SOW with scope, milestones, acceptance criteria, and payment terms. Includes California late-fee language.

Generate SOW

Frequently Asked Questions

What should I include in a Statement of Work that isn't in the MSA?

The SOW should contain project-specific details: scope of work, deliverables list, timeline with dates, milestones and payment schedule, acceptance criteria, assumptions, and any project-specific terms that differ from the MSA. The MSA covers general terms like IP ownership, liability caps, confidentiality, and termination rights that apply to all projects. Think of it as: MSA = "how we work together generally," SOW = "what we're building this time."

How do I structure milestones to minimize payment risk?

Front-load your milestone payments. Get 25-30% at project kickoff before you write a line of code. Keep final delivery payment to 10-15% max. Never have more money due after delivery than you can afford to lose. Also include: (1) auto-acceptance clauses if client doesn't respond, (2) work suspension rights for non-payment, and (3) code retention until final payment. You want to be substantially paid before the client has everything they need to walk away.

What's the best way to define acceptance criteria for software?

Make acceptance criteria binary and testable. Instead of "the app should be fast," write "pages load within 3 seconds on 4G connection." Reference specific user stories or requirements documents. Include browser/device support explicitly. For complex projects, create a separate Acceptance Criteria exhibit with a checklist the client signs off on. Most importantly, limit acceptance review to scope compliance, not subjective preferences. The client shouldn't be able to reject because they "don't like the design" if the design matches approved mockups.

How do I handle a client who keeps requesting changes mid-project?

Your SOW should require signed Change Orders for any out-of-scope work. When a client requests changes: (1) Acknowledge the request in writing, (2) Prepare a Change Order with cost and timeline impact, (3) Do NOT start the work until the CO is signed. If the client resists the CO process, point to the contract. If they insist you do it anyway, document that you're doing it "under protest pending Change Order approval." For chronic scope-creepers, consider T&M pricing instead of fixed-price.

Can I charge the 10% California interest rate on late payments?

Yes. California Civil Code 3287 entitles you to prejudgment interest at 10% per annum (CC 3289 rate) on contract damages where the amount is certain. For unpaid invoices with a specific dollar amount, interest accrues from the due date. Include this in your payment terms clause so clients know upfront. Note: you can't charge compound interest or penalty fees that exceed actual damages, but 10% simple interest is fully enforceable. This also applies if you have to sue - you'll recover interest from the due date, not just from judgment.