# Scoping Document — Template
**Source:** Routiine LLC Sprint Scope deliverable · published at routiine.io/forge
**Purpose:** A fixed-scope, fixed-price software engagement brief. The document that is signed before any build work begins.
**License:** Use freely. Attribution appreciated, not required.

---

## 1 · Executive Summary

**Client:** [Legal entity name]
**Engagement:** [One-sentence engagement name]
**Tier:** Launch | Platform | System | Fractional CTO
**Fixed Price:** $[total]
**Timeline:** [start date] – [ship date]
**Primary Contact:** [Client side — name + role + email]
**Routiine Owner:** [James Ross Jr., or designated lead]

---

## 2 · Business Context

One page on why this engagement exists. No more.

- What does the client's business do?
- What is the strategic goal this engagement supports?
- What is the cost of not doing this engagement?
- What changes for the client on the day we ship?

If this section cannot fit on one page, the engagement is not yet scoped. Go back to discovery.

---

## 3 · In Scope — Deliverables

A numbered, itemized list of every artifact that will be delivered. Each item:
- Is concrete enough that either side can call "done or not done" on it without interpretation
- Ships with defined acceptance criteria
- Maps to a FORGE quality gate

### 3.1 [Deliverable 1 name]
- Description: [2-3 sentences]
- Acceptance: [Measurable criteria — user can do X, system responds in Y, metric reaches Z]
- FORGE gate coverage: [Which of the 10 quality gates validate this]

### 3.2 [Deliverable 2 name]
[Same structure]

[Continue for every deliverable]

---

## 4 · Out of Scope

Everything the client might expect but is not included. This section is not optional. An unambiguous out-of-scope list prevents 80% of engagement drift.

- [Specific feature explicitly excluded]
- [Specific integration explicitly excluded]
- [Specific vertical of work the client might assume is included]

If in doubt, write it down as out of scope. The client can always ask for it in a change order.

---

## 5 · Architecture Summary

High-level only. Full architecture lives in the ADR log.

- Frontend: [framework, stack]
- Backend: [language, framework, notable libraries]
- Database: [engine, ORM, hosting]
- Auth: [provider, pattern]
- AI: [models, SDKs, integration pattern]
- Hosting: [deploy target]
- Observability: [logging, error tracking, analytics]

Each item above should have a corresponding ADR in the engagement's `/docs/adr/` directory by week two of the build.

---

## 6 · Timeline — Weekly Milestones

| Week | Milestone | Deliverable | Gate |
|---|---|---|---|
| 1 | Kickoff + Discovery | Confirmed requirements, final ADR list | — |
| 2 | Architecture lock | Full ADR log, schema freeze | Build gate |
| 3 | [Milestone] | [Deliverable] | [Gate] |
| ... | ... | ... | ... |
| N | Handoff | Ownership transfer document signed | Handoff gate |

Milestones are written in writing, not implied. A weekly cadence that does not ship a reviewable artifact per week is a weekly cadence that will drift.

---

## 7 · Quality Gates (All Ten Apply)

Every Routiine engagement enforces all ten gates before handoff:

1. **Build** — Zero errors, zero warnings where feasible
2. **Test** — All tests pass; coverage threshold per domain
3. **Lint** — Zero lint errors, no ignored rules without justification
4. **Type** — Strict TypeScript, zero `any`, zero `@ts-ignore` without ADR
5. **Security** — OWASP Top 10 review, dependency audit clean
6. **Review** — Code-reviewer sign-off on every PR
7. **Performance** — Core Web Vitals ≥ 90 for client-facing pages
8. **Env** — Every variable documented in `.env.example`
9. **Migration** — Migrations run clean, rollback path verified
10. **Handoff** — README, ADR log, runbook all current

Any gate amendment for this engagement requires a written ADR in this document before the build starts.

---

## 8 · Ownership Transfer

What the client receives on the handoff day:

- Full source code repository, licensed to the client
- ADR log for every architectural decision made during the build
- Runbooks covering deploy, rollback, routine maintenance
- Every account credential (cloud, DNS, analytics, third-party services)
- Thirty days of post-launch support at no additional cost

---

## 9 · Price & Payment Terms

- **Total:** $[amount]
- **Schedule:** 50% on signature, 50% on handoff
- **Sprint Scope Credit:** $2,500 of the total reflects credit for the paid scoping engagement
- **Payment method:** [ACH preferred; credit card accepted; wire available for international clients]
- **Net terms:** Net 15 on final invoice

---

## 10 · Ship-or-Pay Guarantee

If Routiine misses the agreed scope as defined in Section 3 on the agreed timeline as defined in Section 6, the final balance invoice is waived. The deposit is retained against work completed to the point of the miss; no additional charge will be issued.

This guarantee is founder-backed and written into every Routiine engagement contract.

---

## 11 · Change Orders

Scope additions after signature require a written change order including:
- New deliverable description
- Impact on timeline
- Incremental fixed price
- Client countersignature

No work begins on a change order until both parties have countersigned. This is the structural discipline that keeps engagements on the agreed-at-signature Ship-or-Pay terms.

---

## 12 · Signatures

**Client:** [Name, role, date, signature]
**Routiine LLC:** [James Ross Jr., Founder, date, signature]

---

*This template is part of the Routiine LLC Resource Hub at routiine.io/resources. The full FORGE methodology is published at routiine.io/forge.*