Skip to content

Stage briefs — DELIVER (Onboarding → Delivery & Handover)

Before designing any asset here, read ../00-business-primer.md and ../01-brand-system.md.

Assets in this file: PA17–PA21. These are what the client experiences during the engagement. They matter for retention: a client who feels a smooth, professional delivery renews the retainer and expands. Several of these are generated by SnowOps tools — the design job is a theme/template the generator renders into, not a one-off document.

PA17 — Kickoff / welcome deck

  • Stage: 6 Onboarding — the first meeting after signing.
  • Audience: the client's team who will work with SnowOps during delivery (founder + engineers).
  • Job-to-be-done: start the engagement with clarity and confidence — who does what, the plan, the timeline, what SnowOps needs from them, and how they'll know it's going well.
  • Format & spec: short slide deck (~8–10 slides), 16:9, PDF + editable.
  • Source content: Y11-cs-expansion.md (onboarding/handoff), the milestone structure in docs/client-guides/, and CLAUDE.md milestone definitions (docs/context/08-milestones.md).
  • Content outline: welcome + the goal restated in the client's words · the delivery plan (milestones M2a → M2b → …) and timeline · roles & responsibilities (SnowOps vs. client) · what SnowOps needs to start (access, prerequisites — links to PA18) · communication cadence & where things live (git, tickets) · definition of done / how handover works · Q&A.
  • Design direction: reuse the PA06 deck master. Warmer than the sales deck — this is a partnership kickoff. A clear timeline/milestone graphic is the centerpiece.
  • Priority: P1 · Depends on: PA00, PA06. · State: ⬜

PA18 — Onboarding & access-request guide (client checklist)

  • Stage: 6 Onboarding.
  • Audience: the client engineer who has to grant SnowOps the access and prerequisites to begin.
  • Job-to-be-done: make it effortless and reassuring for the client to satisfy prerequisites and grant correctly-scoped access — removing the #1 source of onboarding delay.
  • Format & spec: designed checklist document (PDF) + could be a web page. Actionable, step-by-step, with copy-paste commands where relevant.
  • Source content: apps/client-bootstrap/ (B6 — the client prerequisite checker + Azure permission validator) and its README; the access model from the cloud-access authorization (PA16).
  • Content outline: prerequisites checklist (Azure subscription, GitHub org, etc.) · exactly what access SnowOps needs and why (scoped, least-privilege, time-boxed) · step-by-step grant instructions · how to verify with the bootstrap checker · how to revoke later (reinforces no-lock-in).
  • Design direction: clean, task-oriented, checkbox-driven. Commands in the mono font (brand system §4). Emphasize the reassurance angle — the client is granting cloud access to a vendor; the design should make the least-privilege/time-boxed/revocable story visible. Uses the document master.
  • Priority: P1 · Depends on: PA00. · State: 🟨 (tool + content exist)

PA19 — Milestone handover guides

  • Stage: 7 Delivery & handover — delivered at each milestone (Definition of Done #10 requires a client-facing guide per milestone).
  • Audience: the client's team who will operate what was delivered; also read by their future security/platform hire.
  • Job-to-be-done: hand over each milestone so the client can operate it, understand how it maps to compliance frameworks, and exit cleanly if they ever want to — proving the "code you own, no lock-in" promise.
  • Format & spec: designed multi-page PDF template applied to each existing guide (there are several; more will be written as milestones ship). Must render from markdown that contains real file paths and code.
  • Source content: docs/client-guides/ — currently: quickstart-quality-gates.md, m2a-greenfield-baseline-handover.md, m2b-compliance-monitoring-handover.md, brownfield-adoption.md, brownfield-in-place.md. (Advanced/M4 guide to come.)
  • Content outline (per the guides' own convention): what was delivered (real module/workflow paths) · how to operate it · compliance mapping · verification checklist · failure modes · removal / offboarding path.
  • Design direction: a documentation template, not a marketing piece — think excellent technical docs (clear hierarchy, code blocks in mono, callouts for verification/warnings, a compliance-mapping table style). Prioritize legibility of code and paths. Consistent cover + footer with the document master. This template applies to all current and future guides, so make it robust to variable length and heavy code.
  • Priority: P1 · Depends on: PA00. · State: 🟨 (content ready)

PA20 — Architecture-diagram deliverable (from the V2 tool)

  • Stage: 7 Delivery (also feeds proposals PA13 and QBRs PA22).
  • Audience: the client's engineers — the living diagram of what was actually deployed.
  • Job-to-be-done: give the client an accurate, good-looking architecture diagram of their deployed platform, generated from real Terraform outputs (so it never goes stale).
  • Format & spec: a diagram theme/style applied to the generator's output. apps/diagram-generator/ (V2) turns Terraform outputs into a d2lang diagram → SVG. The design job is the d2 theme / SVG styling so generated diagrams match the SnowOps diagram language — not hand-drawing a diagram.
  • Source content: apps/diagram-generator/ (V2) output; the diagram style defined in brand system §5 and PA13.
  • Design direction: must be consistent with PA13's reference-architecture style so a client's actual diagram looks like the reference they were sold. Define d2lang theme tokens (colors, shapes, fonts) that map to the brand. Legible when embedded in a PDF or projected.
  • Priority: P1 · Depends on: PA00, PA13 (shared diagram language). · State: 🟨 (tool exists; needs themed styling)

PA21 — Operational runbook pack (from the V3 tool)

  • Stage: 7 Delivery.
  • Audience: the client's on-call/ops engineers.
  • Job-to-be-done: deliver the operational runbooks (how to operate/recover the platform) as a clean, navigable pack the client actually uses under pressure.
  • Format & spec: a theme/template applied to generator output. apps/runbook-generator/ (V3) turns Terraform outputs into operational markdown. The design job is a styled PDF or static-site theme for that generated markdown.
  • Source content: apps/runbook-generator/ (V3) output.
  • Content outline: per-runbook — purpose, procedure (numbered steps, commands in mono), verification, rollback, escalation.
  • Design direction: optimized for use under stress — high legibility, obvious step numbering, commands unmistakable in mono, warnings/verification as consistent callouts. Could be a searchable static site (nicer for on-call) or a PDF pack. Same documentation template family as PA19.
  • Priority: P2 · Depends on: PA00, ideally PA19 (shared docs template). · State: 🟨 (tool exists; needs themed styling)

Stage-3 sequencing note

PA19 (handover template) is the reusable workhorse — build it once and every current and future milestone guide inherits it; PA20 reuses PA13's diagram language; PA21 reuses PA19's docs template. So the real new design work here is PA17 (kickoff deck), PA18 (onboarding guide), and PA19 (docs template) — the rest are themes layered on those foundations.