You searched fixed-scope software contract checklist for startups because you are about to sign a Statement of Work (SOW) with a software agency — and you do not want to discover at invoice #3 that “fixed scope” had six hidden escape hatches.
This checklist is not a legal template. It is 15 clauses Wolverine Solution insists on including (or clarifying) in every fixed-scope engagement we sign with US and EU startups, wholesale distributors, and early-stage SaaS founders. We build React / Next.js web apps, React Native and native iOS/Android mobile apps, RAG pipelines on AWS and GCP, and Terraform-managed infrastructure — always on a named scope, never time-and-materials. These clauses come from real disputes we have prevented (or, early in our career, learned the hard way).
Use this as a decision tool, not a copy-paste template. If your agency resists items on this list, treat that resistance as signal.
What does a fixed-scope software contract actually need to cover?
A fixed-scope software contract should define the deliverable precisely enough that both parties can independently determine whether the work is complete. It must name the tech stack, describe each deliverable in testable terms, assign intellectual property to the buyer, specify how scope changes are priced, set acceptance criteria with deadlines, and outline post-launch handoff and warranty. Anything less is a time-and-materials deal wearing a fixed-price costume.
Most startup founders scan the total price and the timeline. That is the wrong place to focus. The clauses below are where projects actually derail — and where a well-drafted SOW saves you tens of thousands.
Clause 1: Scope of Work — deliverable-level specificity, not feature lists
Vague scope is the number one cause of fixed-scope disputes. “Build a customer portal” is not a scope. “Build a customer portal with login (email + SSO via Auth0), order history pulled from NetSuite via SuiteScript RESTlet, PDF invoice download, and an admin dashboard showing order status by branch — 4 screen designs, 7 API integrations” is a scope.
What to check:
- Every deliverable is a named screen, endpoint, or module — not a verb (“integrate,” “build,” “set up”)
- Deliverable count is explicit: X screens, Y API endpoints, Z deployment targets
- Explicit exclusions: “This SOW does not include: data migration from legacy ERP, iOS native push notifications, or third-party payment processing”
Clause 2: Technical stack and infrastructure commitments
If the contract says “cloud-agnostic” but your agency deploys to Heroku and you expected AWS ECS with Terraform, you have a problem that shows up six months later during scaling.
What to check:
- Named runtime and framework versions (React 18.x, Node 20 LTS, Python 3.12)
- Named cloud provider and region (AWS us-east-1, GCP europe-west1)
- Infrastructure-as-code commitment: “Terraform modules delivered in your own AWS account” vs. “hosted on agency’s infrastructure”
- Database engine and version (PostgreSQL 16, MongoDB 7.x, DynamoDB)
- CI/CD target (GitHub Actions, GitLab CI, CircleCI)
How do you define scope clearly enough to avoid disputes?
Define scope through deliverable-level descriptions, named acceptance tests for each deliverable, a written exclusions list, and a change-order process with pre-agreed hourly or per-feature rates. The goal is a contract where both you and the agency can independently answer “is this done?” with the same yes or no.
Clause 3: Acceptance criteria — per-deliverable, not project-wide
“Client will review and approve” is meaningless. Each deliverable should have a short, testable acceptance criterion written before work begins.
What to check:
- Acceptance criterion per deliverable, not a single project-level sign-off
- Written acceptance tests (e.g., “User can log in via email, reset password, and authenticate via Google SSO; verified in staging environment”)
- Acceptance window: “Client has 5 business days to test and reject with written reason; silence after 5 days = implied acceptance”
- Rejection must reference a specific clause in the SOW, not subjective preference
Clause 4: Change order process — how scope changes get priced mid-project
This is where fixed-scope becomes a trap. If the contract has no change-order mechanism, every “small tweak” becomes a negotiation with no anchor price.
What to check:
- Written change-order template referenced in the SOW (form, not email thread)
- Pre-agreed hourly rate for out-of-scope work (e.g., “$150/hr US, 4-hr minimum”)
- Or per-feature pricing for common additions (e.g., “Additional API integration: $2,500–$5,000 depending on complexity, scoped in 2-page addendum”)
- Change orders require written approval from both sides before work starts
- The agency cannot unilaterally reclassify original scope items as “change orders”
What IP and ownership clauses should a startup insist on?
Clause 5: IP assignment — you own the code, period
For a fixed-scope build, you are paying for the deliverable. You should own every line of custom code, every design file, every deployment script. “Work for hire” under copyright law, reinforced by an explicit assignment clause.
What to check:
- “All deliverables are work-for-hire; upon final payment, all IP transfers to Client”
- No “license-back” clauses where the agency retains rights to reuse your code
- Open-source components used in the build are listed (with license type: MIT, Apache 2.0, GPL) — know what you are inheriting
- Design files (Figma, Sketch) are delivered in editable format, not exported JPGs
- Third-party dependencies: who owns the npm packages or PyPI libraries? (Answer: nobody — but know which ones are GPL and what that means for distribution)
Clause 6: Non-compete and non-solicitation scope
Some agencies include broad non-compete clauses that prevent you from hiring their engineers for 12–24 months. For startups, this is a red flag unless narrowly scoped.
What to check:
- Non-compete applies to agency employees specifically engaged on your project, not the agency’s entire team
- Duration is 6–12 months, not 24
- No non-solicitation of the agency’s other clients (yes, this appears in some contracts)
- Carve-out for general hiring (job boards, recruiters) that are not targeted poaching
How should change orders work in a fixed-scope engagement?
See Clause 4 above. The additional nuance: change orders should have a cooling-off period for large additions. If an agency proposes a $20,000 change order on a $5,200 project, you should have 3–5 business days to evaluate, not sign-or-lose-your-slot pressure.
Clause 7: Schedule and milestone payments tied to deliverables — not dates
Calendar-based payment schedules (“30% on signing, 40% at week 6, 30% at launch”) are fine for agencies with predictable velocity. But the better pattern for startups: payments tied to deliverable acceptance, not arbitrary dates. You should not pay 40% at week 6 if the agency missed week 4 milestones.
What to check:
- Payment milestones map to specific deliverables (e.g., “30% on SOW signing, 30% upon design approval, 30% upon staging acceptance, 10% upon production deployment”)
- Late-delivery clause: “If milestone is missed by more than 10 business days without a mutually agreed extension, Client may pause payments until milestone is met”
- Kill clause: “Either party may terminate with 15 days written notice; Client pays for accepted deliverables only”
- Refund mechanism for pre-paid work not yet delivered
What acceptance criteria protect you from paying for unfinished work?
Clause 8: Definition of “done” — staging vs. production
“Done” means different things to agencies and founders. In our experience, the gap is usually between “it works on my machine” and “it runs in production, monitored, with a rollback path.”
What to check:
- “Done” = deployed to named production environment, passing acceptance tests, with monitoring (e.g., Datadog, Sentry, CloudWatch) configured
- Staging environment must mirror production configuration (same Terraform modules, same Docker images, same env vars minus secrets)
- Load-testing expectations stated (e.g., “Dashboard renders in < 2s under 50 concurrent users on t3.medium AWS instance”)
- Security review included: dependency audit (Snyk, npm audit), OWASP Top 10 checklist, secrets not in repo
Clause 9: Bug fix window — what happens when something breaks on day 2
A fixed-scope contract that ends at deployment and offers zero post-launch support is incomplete.
What to check:
- Warranty period: 30–60 days post-launch for bugs against original scope
- Bug definition: “defect in delivered functionality that does not match the acceptance criteria in the SOW” — not “I changed my mind about the layout”
- Response SLA for warranty bugs: “Critical (production down) — 4 business hours; High (feature broken) — 1 business day; Low (cosmetic) — 5 business days”
- What is not covered: new features, performance tuning beyond original spec, third-party API changes
What happens after launch — handoff, support, and warranty clauses?
Clause 10: Documentation and knowledge transfer
You are paying for a product, not a black box. The contract should require deliverables that let another developer pick up the project if you part ways with the agency.
What to check:
- Architecture decision records (ADRs) for non-obvious choices
- README with setup instructions, environment variables, and deployment steps
- API documentation (OpenAPI/Swagger spec if applicable)
- Database schema documentation (ERD diagram or migration history)
- Runbook for common operational tasks (scaling, log access, secret rotation)
Clause 11: Repository and environment ownership
This is a surprisingly common dispute. The code is in the agency’s GitHub organization. The infrastructure is in the agency’s AWS account. You own the IP on paper, but you cannot access anything.
What to check:
- Code repository lives in your GitHub / GitLab / Bitbucket organization from day one (or transfers upon signing)
- Infrastructure deployed to your cloud account (AWS, GCP) — the agency operates within your account via IAM roles, not their own
- CI/CD pipelines live in your repo, not the agency’s
- Domain names and DNS managed by you (agency gets temporary access, not ownership)
Clause 12: Transition support clause
If the engagement ends (amicably or not), the agency should provide a transition window.
What to check:
- 10–20 hours of transition support included in the SOW (or at the pre-agreed hourly rate)
How do you handle payments, termination, and liability in a fixed-scope contract?
A fixed-scope contract should tie payments to accepted deliverables, cap liability at the contract value, and give both parties a termination path that accounts for work already completed. These clauses are not about distrust — they are about removing ambiguity so a disagreement over a feature does not become a legal dispute.
Clause 13: Liability cap and insurance
Your startup should not accept unlimited liability for an agency’s mistakes, and neither should the agency.
What to check:
- Liability cap: “Aggregate liability limited to fees paid under this SOW” — standard
- No consequential damages waiver: “Neither party liable for lost profits, lost revenue, or indirect damages”
- Agency carries professional liability (E&O) insurance and can provide a certificate
- Cyber liability insurance if the agency handles production data
Clause 14: Confidentiality and data protection
Your SOW will contain business logic, customer data, and possibly trade secrets. The contract must protect them — and comply with GDPR if you operate in the EU.
What to check:
- Mutual NDA covering the SOW, not just the MSA
- Data Processing Agreement (DPA) referenced for any handling of personal data
- Sub-processor list: which tools (Slack, Jira, Google Workspace) will the agency use to discuss your project?
- Data deletion: “Upon termination, Agency deletes all Client data from its systems within 30 days and provides written certification”
Clause 15: Governing law and dispute resolution
For cross-border engagements (US agency + EU client or vice versa), this clause determines which legal system you are dealing with.
What to check:
- Named governing law (e.g., “State of Delaware, USA” or “England and Wales”)
- Dispute resolution: mediation before arbitration; arbitration venue agreed in advance (e.g., ICDR, LCIA, JAMS)
- No class action waivers (you are a startup, not a consumer platform)
- Costs: “Each party bears its own legal fees; prevailing party may recover fees in arbitration” — or not, depending on your leverage
FAQ
What is the difference between fixed-scope and time-and-materials contracts?
Fixed-scope means the agency commits to delivering a defined set of features for a set price and deadline. Time-and-materials means you pay for hours worked, regardless of what gets built. Fixed-scope transfers delivery risk to the agency; time-and-materials transfers cost control risk to you. Startups with a clear MVP and a hard budget should prefer fixed-scope.
How do I know if an agency’s fixed-scope quote is realistic?
Ask for a detailed SOW with deliverable-level breakdowns. A realistic quote will name the screens, integrations, and acceptance tests. A vague quote that says “portal with standard features” is a red flag. Cross-check the effort against your
Need this built? Our team does fixed-scope how fixed-scope works — scoped, priced and delivered in weeks.
Mehedi Hasan · Senior Software Engineer