# Ownership Transfer — Handoff Checklist
**Source:** Routiine LLC FORGE methodology · published at routiine.io/forge
**Purpose:** The document the client receives on day 90 (or handoff day, whichever comes first). The full list of what transfers from Routiine to the client.
**License:** Use freely. Attribution appreciated, not required.

---

## 1 · Source Code

- [ ] GitHub organization transferred or client added as owner
- [ ] Full git history preserved — no squash or rewrite that destroys provenance
- [ ] License file in the repo clearly identifies the client as the copyright holder
- [ ] `.gitignore` reviewed — no secrets, no local-only configs committed
- [ ] README includes setup, build, test, deploy, and troubleshoot sections
- [ ] Architecture diagram in `/docs/architecture.md` (C4 or equivalent)

## 2 · Architecture Decision Records

- [ ] Full ADR log in `/docs/adr/`
- [ ] Every non-obvious technical decision has a corresponding ADR
- [ ] Each ADR names the author, the date, the status, and the review trigger
- [ ] Cross-references between ADRs are complete (no dangling `Supersedes ADR-NNNN`)

## 3 · Runbooks

- [ ] Deploy runbook — how to ship a change to production
- [ ] Rollback runbook — how to revert a bad release
- [ ] Common operations — database migration, cache flush, secret rotation
- [ ] On-call runbook — what to do when paged
- [ ] Third-party vendor runbook — who to contact at each vendor, what the SLA is, what the escalation path looks like

## 4 · Cloud & Hosting

- [ ] Vercel / Railway / AWS / GCP account owned by the client entity, not by Routiine
- [ ] Billing moved to client's payment method
- [ ] Routiine removed as owner or demoted to read-only (if continuing retainer)
- [ ] DNS records documented — every CNAME, A, MX, TXT accounted for

## 5 · Domain & DNS

- [ ] Domain registration transferred to client's registrar account
- [ ] DNS provider account owned by client
- [ ] SSL certificates renewed and on auto-renewal
- [ ] Email (MX, SPF, DKIM, DMARC) records documented

## 6 · Third-Party Services

For each service the project depends on (Stripe, Supabase, Auth provider, Resend, etc.):
- [ ] Account transferred to client entity OR client added as owner
- [ ] Billing on client's payment method
- [ ] API keys and secrets rotated to ones the client owns
- [ ] Routiine access reduced to read-only or removed

## 7 · Data & Database

- [ ] Production database dump delivered (or pointer to a client-controlled backup system)
- [ ] Backup and restore procedure tested end-to-end
- [ ] Schema migrations are in the repo, not in vendor UI
- [ ] Sensitive-data inventory documented (what PII/PHI/PCI exists, where)

## 8 · Analytics & Observability

- [ ] Google Analytics, PostHog, or equivalent ownership transferred
- [ ] Sentry / Better Stack / observability provider ownership transferred
- [ ] Dashboards identified and documented
- [ ] Alert destinations updated from Routiine's on-call to client's on-call

## 9 · AI & API Credentials

- [ ] Anthropic / OpenAI / other LLM API keys rotated to client-owned
- [ ] Rate limits and budget alarms documented
- [ ] Model choices and prompts committed to the repo, not in vendor UI
- [ ] Fallback / degradation behavior documented for LLM outages

## 10 · Social, Marketing, SEO Assets

- [ ] Google Business Profile transferred
- [ ] Google Search Console ownership transferred
- [ ] Social media account access delivered (credentials + 2FA recovery)
- [ ] SEO tooling (Ahrefs, SEMrush, BrightLocal) account access transferred or client subscription in place
- [ ] Brand assets delivered (logo source files, design system tokens, photography originals)

## 11 · Documentation

- [ ] `/docs/` in the repo is current as of handoff day
- [ ] Customer-facing docs (help center, API reference) are live and current
- [ ] Internal docs (team wiki, operations manual) exist
- [ ] Onboarding doc for the next engineer who joins

## 12 · Support Window

- [ ] Thirty days of post-launch support confirmed in writing
- [ ] Bug reporting channel defined (email, Linear, shared Slack)
- [ ] Response-time commitment documented
- [ ] Post-support transition plan — who owns the system on day 31

---

## The Signature Block

**Routiine LLC certifies** that every item on this checklist has been completed, documented, and transferred to the client as of the handoff date. If any item is intentionally omitted, it is listed explicitly in the "Known Omissions" section below with the reason and the proposed remediation.

**Client acknowledges** that they now own the system in full and assume operational responsibility from the transition date defined below.

**Transition Date:** [YYYY-MM-DD]
**Routiine LLC:** [James Ross Jr., Founder, signature, date]
**Client:** [Name, role, signature, date]

### Known Omissions
(List any checklist items intentionally not transferred, the reason, and the remediation plan. An empty section is acceptable.)

---

*This checklist is part of the Routiine LLC Resource Hub at routiine.io/resources. See routiine.io/forge for the full methodology and routiine.io/work for the Founding Client Program.*