🏠 Jxing Tech: Delivery SOP Wiki

Purpose: The single source of truth for how a project moves from a signed proposal to a live, handed-over product. If a brief or proposal is signed, this wiki tells you exactly what happens next, who does it, what "done" means, and how we spot bottlenecks before they hurt the timeline.

Applies to: All client projects (web, mobile, custom software) Team size assumption: 2-8 people per project, people may wear multiple hats Tooling: Notion (docs, client-facing pages, and task tracking), GitHub (code, CI/CD), Google Stitch + Figma (design), Google Chat (comms) Owner of this wiki: Delivery Lead; review quarterly Version: 1.0 · Last updated: 2026-07-12

📖 How to use this wiki

1. A proposal just got signed? Start at Phase 0: Proposal Intake & Kickoff and follow the phases in order.
2. Mid-project and unsure what's next? Find your current phase below; every page ends with Exit Criteria: until all are checked, the project does not move forward.
3. Want to check health of a project? Go to Progress Monitoring & Bottleneck Management.
4. Need a template? Everything lives in Templates & Checklists.

🗺️ The Delivery Lifecycle at a Glance

 SIGNED PROPOSAL
       │
       ▼
 ┌─────────────────┐   ┌─────────────────┐   ┌─────────────────┐
 │ PHASE 0         │   │ PHASE 1         │   │ PHASE 2         │
 │ Intake &        │──▶│ Discovery &     │──▶│ UX/UI           │
 │ Kickoff         │   │ Requirements    │   │ Design          │
 │ (2-4 days)      │   │ (3-10 days)     │   │ (1-4 weeks)     │
 └─────────────────┘   └─────────────────┘   └─────────────────┘
                                                      │
       ┌──────────────────────────────────────────────┘
       ▼
 ┌─────────────────┐   ┌─────────────────┐   ┌─────────────────┐
 │ PHASE 3         │   │ PHASE 4         │   │ PHASE 5         │
 │ Development     │──▶│ QA &            │──▶│ Deployment &    │
 │ (sprints)       │   │ UAT             │   │ Handover        │
 │                 │◀──│ (continuous)    │   │ + Warranty      │
 └─────────────────┘   └─────────────────┘   └─────────────────┘

QA is not a phase that only happens at the end; it runs continuously inside every sprint (see Phase 4). The diagram shows where the formal QA/UAT gate sits.

📚 Wiki Pages

🚦 Project Status Vocabulary

Every project has exactly one status at any time, tracked in the Notion "Projects" database.

Rule: a status change is a real event. Announce it in the project's Google Chat space and update the Notion database the same day.

⛩️ Phase Gates (the "you shall not pass" rules)

Each phase ends with a gate: a short list of exit criteria on that phase's page. The gate rules:

1. The phase owner (see Roles & RACI) checks every exit criterion and posts the completed checklist in the project Google Chat space.
2. The Delivery Lead confirms with a ✅ reaction or comments what's missing. This is deliberately lightweight; it should take minutes, not meetings.
3. Client-facing gates (end of Discovery, Design, UAT) additionally require written client sign-off (email or Notion comment counts; a verbal "looks good" does not).
4. Skipping a gate requires an explicit, written risk acceptance from the Delivery Lead in the project channel. It should be rare and it is never silent.

🧭 Quick answers

• "The client just signed. What do I do right now?" → Phase 0, Step 1
• "Design is done, how do I hand it to devs?" → Design → Dev Handoff
• "How do I report a bug properly?" → Bug workflow
• "We're deploying Friday. Checklist?" → Don't deploy Friday. Then see Release checklist
• "Project feels stuck. Now what?" → Bottleneck playbook

Phase 0: Proposal Intake & Kickoff

← Home · Next: Discovery & Requirements →

Trigger: Client signs the proposal / contract / SOW. Phase owner: Delivery Lead Target duration: 2-4 business days from signature to internal kickoff done Project status: Intake

Why this phase exists

The most expensive mistakes happen in the first week: wrong assumptions carried from sales into delivery, missing access, no clear owner. This phase converts a sales artifact (the proposal) into a delivery-ready project with an owner, a workspace, and a shared understanding of scope.

Step 1: The first 24 hours

Owner: Delivery Lead

1. Acknowledge the signature. Whoever closed the deal (sales/founder) posts the signed proposal PDF in the Delivery Intake space on Google Chat the same day it's signed.
2. Assign the core team. Delivery Lead assigns, at minimum:
3. Project Manager (PM): accountable for the project day-to-day (may be the Delivery Lead on small projects)
4. Tech Lead: accountable for technical decisions
5. Designer: if the project has any UX/UI scope
6. QA owner: a named person, even if part-time (if "everyone tests", nobody tests)
7. Create the project record in the Notion "Projects" database with: client name, project name, signed date, contract value bracket, target go-live from the proposal, assigned team, status Intake.
8. Create the Google Chat space proj-<client>-<shortname> and invite the team. All project comms happen here, not in DMs. Pin the proposal.

⛔ Anti-pattern: starting design or dev work "to get ahead" before the intake review (Step 2). Sales proposals almost always contain ambiguity that must be surfaced first.

Step 2: Internal intake review (within 48 hours)

Owner: PM · Attendees: person who sold the deal, PM, Tech Lead, Designer

A 60-minute working meeting. The goal: everyone who will build the thing understands what was actually sold.

Walk through the proposal and fill in the Intake Review doc (template):

Output: Intake Review doc in the project's Notion space, with an explicit list of open questions for the client: this feeds the kickoff meeting.

Step 3: Project workspace setup (parallel with Step 2)

Owner: PM (Notion), Tech Lead (GitHub)

• ☐ Notion: create the project space from the "Project Home" template: Overview page, Intake Review, PRD placeholder, Meeting Notes, Decisions Log, Client Deliverables tracker.
• ☐ Notion Tasks database: create the project's Tasks database from the team template: statuses Backlog → Todo → In Progress → In Review → QA → Done, tag / estimate / milestone / due-date properties, a Unique ID property (e.g. JX-123), plus saved views for the sprint board and blocked tasks. Set the target date from the proposal and create milestone placeholders (Discovery done, Design approved, Feature complete, UAT sign-off, Go-live).
• ☐ GitHub: create the repo(s) from the org template (branch protection, PR template, CI workflow stub, CODEOWNERS). Private by default. See Development.
• ☐ Design workspace: create the Figma project file from the team template (cover, pages for Research / Wireframes / UI / Prototype / Handoff) and a Google Stitch project for early concept exploration.
• ☐ Shared drive / credentials vault: create the client folder; record where client-provided assets and credentials will live (never in Google Chat messages).

Step 4: Client kickoff meeting (within 4 business days of signing)

Owner: PM · Attendees: client stakeholders, PM, Tech Lead, Designer

Send the agenda 24h before (template). The meeting covers:

1. Introductions and single points of contact on both sides. Get the name of the client-side person who can approve deliverables (the "sign-off person"). If they say "the whole team decides", flag this as a risk in the Decisions Log.
2. Walk through scope as WE understand it (from the Intake Review); surface mismatches now.
3. Resolve the open questions list from Step 2.
4. Agree on the communication contract: weekly update format and day, demo cadence, response-time expectations (we commit to ≤ 1 business day; ask the same of them), escalation contacts.
5. Agree the client dependencies calendar: content, brand assets, API access, third-party accounts, legal/compliance reviews, each with a named owner and date.
6. Explain the phase gates and that Design and UAT require their written sign-off.

Output: Kickoff notes in Notion within 24h, shared with the client. Client dependencies entered into the Notion Tasks database with due dates, tagged client-dependency.

✅ Exit criteria (gate to Phase 1)

• ☐ Core team assigned and aware (PM, Tech Lead, Designer, QA owner)
• ☐ Notion project space + Tasks database, GitHub repo, Figma/Stitch files, Google Chat space all created and cross-linked
• ☐ Intake Review doc completed; out-of-scope list written
• ☐ Client kickoff held; notes shared; sign-off person named in writing
• ☐ Client dependencies logged in the Notion Tasks database with owners and due dates
• ☐ Project status moved to Discovery

Common bottleneck at this gate: client can't schedule kickoff. Rule: if the kickoff can't happen within 7 business days of signing, the Delivery Lead emails the client that the timeline shifts day-for-day, and the project status stays Intake (visible on the dashboard; see Monitoring).

← Home · Next: Discovery & Requirements →

Phase 1: Discovery & Requirements

← Phase 0 · Home · Next: UX/UI Design →

Trigger: Phase 0 gate passed. Phase owner: PM (with Tech Lead for technical discovery) Target duration: 3-10 business days depending on project size Project status: Discovery

Why this phase exists

The proposal says what was sold; discovery defines what will be built, precisely enough that design and development can estimate and execute without guessing. Skipping or rushing discovery is the root cause of most mid-project scope fights and rework.

Scale it to the project: a 3-week landing page project needs a 1-page PRD and a half-day of discovery. A 4-month platform build needs the full treatment below. The PM decides and records the decision in the Decisions Log.

Step 1: Requirements gathering

Owner: PM

Sources, in priority order:

1. The signed proposal and Intake Review (baseline scope)
2. Kickoff meeting outcomes and answered questions
3. 1-2 structured stakeholder interviews with the client (use the discovery question bank)
4. Existing systems: request read access to anything we integrate with or replace (current site/app, APIs, databases, analytics)
5. Reference products the client likes or competes with

Step 2: Write the PRD

Owner: PM · Reviewers: Tech Lead, Designer

Write the PRD in Notion from the PRD template. Required sections:

Acceptance criteria rule: every Must-have feature gets acceptance criteria before development starts. They don't need to be perfect now, but a feature without acceptance criteria cannot enter a sprint (see Development).

Step 3: Technical discovery

Owner: Tech Lead

• ☐ Choose/confirm the stack and record it in a short Technical Design Note in Notion (architecture sketch, hosting, key libraries, data model outline). One page is usually enough for small projects.
• ☐ Spike anything risky: unfamiliar API, unclear data migration, performance-sensitive feature. Time-box spikes to 1-2 days each and create them as Notion tasks tagged spike.
• ☐ Verify every integration is actually accessible: request sandbox credentials NOW, not in the sprint that needs them. Each pending credential is a task tagged client-dependency in Notion.
• ☐ Define environments plan (dev / staging / production); details in Deployment.

Step 4: Estimate and plan

Owner: PM + Tech Lead + Designer

1. Break the Must/Should features into epics; estimate at epic level (t-shirt sizes or ideal days; pick one and be consistent).
2. Build the milestone plan backwards from the contractual go-live: Design approved → Feature complete → UAT sign-off → Go-live. Add ≥ 15% buffer on dev estimates and put the buffer before UAT, not after.
3. Update the milestone dates in the Notion Tasks database to match.
4. If the estimate doesn't fit the sold budget/timeline: stop and escalate to the Delivery Lead before the client review. Options: cut Should/Could scope, phase the delivery, or renegotiate. Never silently absorb the gap.

Step 5: Client review & sign-off

Owner: PM

1. Send the PRD to the client sign-off person at least 2 business days before a walkthrough call.
2. Hold a walkthrough (screen share, section by section; do not just email a doc and hope).
3. Incorporate feedback; log any scope changes vs the proposal in the Change Log (template) with cost/time impact even if the impact is zero.
4. Get written sign-off on the PRD (email or Notion comment: "Approved").

✅ Exit criteria (gate to Phase 2)

• ☐ PRD written, reviewed internally by Tech Lead + Designer
• ☐ All Must features have acceptance criteria (draft quality OK)
• ☐ Technical Design Note done; risky items spiked or scheduled as spikes
• ☐ All integrations confirmed accessible or logged as client-dependency with dates
• ☐ Milestone plan agreed internally, milestones set in the Notion Tasks database
• ☐ Estimate fits budget, or the gap has been escalated and resolved
• ☐ Client written sign-off on the PRD
• ☐ Project status moved to Design

Common bottlenecks at this gate: slow client feedback on the PRD (apply the client-dependency playbook); estimate exceeds budget (escalate immediately, never at the deadline).

← Phase 0 · Home · Next: UX/UI Design →

Phase 2: UX/UI Design

← Phase 1 · Home · Next: Development →

Trigger: PRD signed off. Phase owner: Designer (PM accountable for client approvals and timeline) Target duration: 1-4 weeks depending on scope Project status: Design

Why this phase exists

Design is where the client "sees" the product for the first time; it is also where unlimited revision loops kill timelines. This phase produces developer-ready designs with a controlled number of revision rounds, and starts development de-risking in parallel.

Revision policy (default, adjust per contract): 2 revision rounds per deliverable (wireframes, hi-fi). Additional rounds are change requests. State this in the kickoff and repeat it when sharing each deliverable.

Step 1: UX foundation (skip for tiny projects, record the skip)

Owner: Designer

• ☐ Map the key user flows from the PRD into flow diagrams (FigJam or Figma page "Research").
• ☐ Define the information architecture: sitemap for websites, screen map for apps.
• ☐ Review with PM + Tech Lead (30 min): does every PRD Must-feature appear in a flow? Is anything technically awkward?

Step 2: Wireframes (lo-fi)

Owner: Designer

1. Wireframe every unique screen/template for the Must scope. Google Stitch is the default for fast first-pass concepts; bring the chosen direction into Figma to refine. Reuse patterns aggressively; don't wireframe 40 near-identical pages.
2. Annotate behavior that isn't obvious: empty states, error states, loading, responsive breakpoints intent.
3. Internal review with Tech Lead before the client sees anything. Feasibility problems caught here cost minutes; caught after client approval they cost apologies.
4. Client review round(s): walk through on a call, capture feedback in Figma comments, consolidate into a single revision. Get written wireframe approval.

Step 3: Visual direction

Owner: Designer

• If the client has a brand system: audit what exists (logos, fonts, colors, guidelines); request missing assets as client-dependency issues.
• If not: produce 1-2 style directions (a "style tile" or one key screen in alternative treatments, not the whole app twice); Google Stitch is useful for exploring directions quickly. Client picks one, in writing.

Step 4: High-fidelity UI

Owner: Designer

1. Design hi-fi screens from approved wireframes and the chosen direction.
2. Build/extend the design system in Figma: color tokens, type scale, spacing, components with variants (buttons, inputs, cards, nav). Devs will consume this; sloppy components mean sloppy handoff.
3. Cover the unglamorous states: empty, error, loading, long-content overflow, smallest supported viewport.
4. Internal review: Tech Lead (feasibility) + PM (scope match against PRD).
5. Client review round(s) → written hi-fi approval. Scope changes discovered here (client "just remembered" a feature) go through the change request flow, always.

Step 5: Prototype & usability sanity check (Should-have for most projects)

Owner: Designer

Clickable Figma prototype of the 2-3 critical flows. At minimum, hallway-test it internally with someone not on the project; for UX-critical products, test with 3-5 real users. Log findings; fix what's cheap now.

Step 6: Developer handoff

Owner: Designer + Tech Lead · This is a meeting, not a link dump.

1. Designer prepares the Figma "Handoff" page: final screens only, organized by flow, marked with statuses (✅ final / 🚧 in progress). Dev Mode enabled.
2. Handoff meeting (60-90 min): Designer walks devs through every flow. Devs ask about interactions, edge cases, animation intent, responsive behavior. Unanswered questions become Figma comments assigned to the Designer with a due date.
3. Fill the Design Handoff checklist:
4. ☐ All screens for the milestone are final-marked
5. ☐ Components use the design system (no detached one-offs without a reason)
6. ☐ All states covered: empty / error / loading / success
7. ☐ Responsive behavior specified per breakpoint
8. ☐ Assets exportable (icons, images) and fonts licensed for web/app use
9. ☐ Microcopy final or explicitly marked placeholder with an owner
10. Tech Lead confirms in the project channel: "Design handoff accepted for milestone X."

Parallelization rule: development of backend, infrastructure, and design-independent features starts during Step 4; do not hold all dev work hostage to final pixels. The PM decides the split at the Phase 1 → 2 boundary and reflects it in the Notion Tasks database.

✅ Exit criteria (gate to Phase 3)

• ☐ Wireframes and hi-fi designs approved by client in writing
• ☐ Design system components built in Figma
• ☐ All states designed (empty/error/loading) for Must-scope screens
• ☐ Handoff meeting held; Design Handoff checklist complete; Tech Lead accepted
• ☐ Any scope changes from design routed through change requests
• ☐ Project status moved to In Development (may happen earlier for parallel tracks; note it in the Decisions Log)

Common bottlenecks at this gate: endless client revisions (enforce the revision policy; escalate per the approval-stall playbook); design approved but assets/fonts/content missing (they're client-dependency issues; chase with dates).

← Phase 1 · Home · Next: Development →

Phase 3: Development

← Phase 2 · Home · Next: QA & UAT →

Trigger: Design handoff accepted (or parallel track approved by PM). Phase owner: Tech Lead (PM accountable for scope/timeline) Cadence: 1- or 2-week sprints (pick per project, keep it fixed) Project status: In Development

Sprint workflow

Sprint rituals (keep them short, never skip them)

Standup may be async in Google Chat (thread in the project space, same three questions) for distributed days, but blockers still get called out explicitly with @ mentions.

Notion task conventions

• Hierarchy: Project → Milestones → Epics (a tag or parent task) → Tasks → Sub-tasks, all in the project's Notion Tasks database.
• Task statuses: Backlog → Todo → In Progress → In Review → QA → Done. QA means deployed to staging and awaiting verification; see QA & UAT.
• Every task must have: a clear description, acceptance criteria (copy from PRD or write them), an estimate, and a milestone. No "fix stuff" tasks.
• One owner per task. Pairing is fine; ownership is singular.
• WIP limit: max 2 tasks In Progress per person. Finishing beats starting.
• Tags that matter: bug, client-dependency, blocked (+ a comment saying blocked by what and since when), spike, change-request, tech-debt.

Definition of Ready (task may enter a sprint only if…)

• ☐ Acceptance criteria written
• ☐ Design final for this issue (or explicitly not needed)
• ☐ Dependencies available (API keys, content, upstream issues done)
• ☐ Estimated
• ☐ Small enough to finish within one sprint; otherwise split it

Definition of Done (task may be closed only if…)

• ☐ Acceptance criteria met, demonstrated on staging
• ☐ Code reviewed and merged (see below)
• ☐ Tests written/updated per the testing policy; CI green
• ☐ No new errors in staging logs/monitoring for the touched area
• ☐ QA verified (status passed through QA, verified by the QA owner, not the author)
• ☐ Docs updated if behavior/config changed (README, env vars, API docs)

Repository conventions

Branching (GitHub Flow, plus a develop branch when a staging train helps)

main        ← always deployable; every merge = release candidate
  └── feature/JX-123-short-description
  └── fix/JX-456-short-description
  └── hotfix/JX-789-short-description   (branched from main, fast-tracked)

• Branch names include the Notion task's unique ID (JX-123); paste the PR link into the task so code and task stay connected.
• Commits: conventional-ish, present tense, reference the task (feat: add invoice export (JX-123)).
• No direct pushes to main. Branch protection enforces PR + green CI + ≥ 1 approval.

Pull requests

• Small PRs: target ≤ 400 changed lines; split otherwise. Big PRs get slow, shallow reviews.
• Use the repo PR template: what/why, screenshots for UI, testing done, breaking changes, checklist.
• Author is responsible for getting the PR merged; chase your reviewer.
• Review SLA: 1 business day. A PR waiting longer is a bottleneck; say so in standup, and the Tech Lead reassigns the review.
• Review checklist: correctness, security (input validation, authz, secrets), matches design, tests present, readable. Nitpicks are prefixed nit: and never block.

CI/CD baseline (set up in Phase 0-1, non-negotiable)

• CI on every PR: lint, type-check, build, unit tests. Red CI = no merge, no exceptions.
• Auto-deploy main (or develop) to staging on merge.
• Production deploys are manual-trigger with approval; see Deployment.
• Secrets in the platform's secret store, never in the repo. .env.example kept current.

Testing policy (default; Tech Lead may tighten per project)

Scope change during development

Any request that isn't in the signed PRD (from the client, OR gold-plating from inside the team):

1. Log it as a Notion task tagged change-request, status Backlog.
2. PM estimates impact with the Tech Lead (days, cost, milestone effect).
3. PM sends the change request form to the client sign-off person: approve (timeline/cost adjusts), defer to a later phase, or drop.
4. Nothing enters a sprint without a written decision. "It's small, I'll just do it" is how fixed-price projects die.

Milestone: Feature Complete

Development ends at feature complete: all Must-scope tasks Done, deployed to staging. Declare it explicitly in the project channel; it triggers the formal QA cycle in Phase 4.

✅ Exit criteria (gate to Phase 4)

• ☐ All Must-scope tasks Done (per Definition of Done) on staging
• ☐ All approved change requests done or explicitly moved to a later phase
• ☐ E2E suite green on staging
• ☐ Known-issues list written (anything shipped with warts, agreed with PM)
• ☐ No blocked tasks remaining in the milestone
• ☐ Project status moved to QA / UAT

Common bottlenecks in this phase: PRs stuck in review (SLA + reassignment), unclear acceptance criteria discovered mid-sprint (the task goes back to Todo and the PM clarifies; never guess), client dependencies arriving late (playbook), and scope creep (change request flow). Detection signals for all of these: Monitoring.

← Phase 2 · Home · Next: QA & UAT →

Phase 4: QA & UAT

← Phase 3 · Home · Next: Deployment & Release →

Phase owner: QA owner (PM accountable for UAT logistics and sign-off) Project status: QA / UAT Reality check: QA runs continuously inside every sprint. This page covers both the in-sprint QA loop and the formal pre-release cycle that starts at feature complete.

In-sprint QA (continuous)

Every task passes through the QA status in the Notion Tasks database before Done:

1. Dev merges → auto-deploys to staging → dev moves the task to QA with a note on how to verify.
2. QA owner verifies against the acceptance criteria plus basic exploratory poking (weird inputs, back button, refresh mid-action, mobile viewport).
3. Pass → Done. Fail → back to In Progress with a comment; this is not a new bug ticket, it's the same task unfinished.
4. Author never verifies their own task. On a 2-person project, the other dev or the PM verifies.

Formal QA cycle (starts at feature complete)

Duration: typically 3-10 business days. Plan it in the milestone plan; it is not buffer to be eaten.

Step 1: Test plan

QA owner writes a short test plan (Notion, template): scope, environments/devices/browsers matrix (from PRD non-functional requirements), test data needs, schedule, who tests what.

Step 2: Execute

• ☐ Run the full manual test suite: every Must feature against its acceptance criteria
• ☐ Run the E2E automation suite
• ☐ Cross-browser / cross-device pass per the support matrix
• ☐ Non-functional checks: page performance (e.g., Lighthouse targets from the PRD), accessibility scan, basic security hygiene (authz on every protected route, no secrets in client bundles, forms validated server-side)
• ☐ Content/proofread pass (real content, not lorem ipsum, before UAT)

Step 3: Bug fixing loop

Devs fix by severity order (below). QA re-verifies every fix and runs a regression pass on affected areas. Repeat until exit criteria met.

Bug lifecycle & triage

All bugs are Notion tasks tagged bug with: steps to reproduce, expected vs actual, environment/browser, screenshot or recording, severity. Use the bug report template. A bug that can't be reproduced from its own description gets bounced back to the reporter.

Severity levels

Triage: QA owner assigns severity; PM + Tech Lead can re-triage in a daily 10-min bug triage during the formal cycle. Severity measures user impact, not effort.

Release rule

Zero known S1/S2 bugs. S3s ship only with a written known-issues list the client has seen. No exceptions without Delivery Lead sign-off in writing.

UAT (client acceptance)

UAT is the client verifying the product does what they bought: on staging, against the PRD, within a time box.

Step 1: Prepare

• ☐ Internal QA exit criteria met FIRST (never start UAT on a build with known S1/S2; it torches trust)
• ☐ UAT script prepared: a guided checklist of scenarios per key flow (template); never just a URL and silence
• ☐ Test accounts and realistic data set up
• ☐ UAT window agreed: default 5 business days, named client testers, kickoff call to walk them through the script and how to report issues

Step 2: Run

• Client reports issues in a single agreed channel (Notion database form or a shared sheet, one place only).
• PM triages daily: bug (we fix, severity rules apply) vs change request (not in PRD → CR flow). This distinction, made politely and immediately, is what keeps UAT from becoming a second design phase.
• Daily short sync with the client during UAT if issue volume is high.

Step 3: Sign off

• All UAT bugs S1/S2 fixed and re-verified; S3/S4 dispositioned in writing.
• Client signs the UAT acceptance (email or the sign-off block in the UAT doc): "We accept the build for release, subject to the known-issues list."
• Stall rule: if the client goes quiet, PM reminds at day 3; at the end of the window +2 days, Delivery Lead sends the deemed-acceptance notice per contract (or escalates). Track it; silent UAT is a top-3 bottleneck (playbook).

✅ Exit criteria (gate to Phase 5)

• ☐ Full test suite executed; results recorded in the test plan doc
• ☐ Zero known S1/S2 bugs
• ☐ S3/S4 known-issues list written and shared with the client
• ☐ E2E suite green
• ☐ Client UAT sign-off in writing
• ☐ Project status moved to Ready for Release

← Phase 3 · Home · Next: Deployment & Release →

Phase 5: Deployment & Release

← Phase 4 · Home · Next: Handover & Warranty →

Trigger: UAT signed off; status Ready for Release. Phase owner: Tech Lead (PM accountable for client comms and go-live timing)

Environments

Rules: staging is never "roughly like prod": same runtime versions, same env-var names, same third-party modes (sandbox keys clearly separated). Nobody tests in production. Client demos happen on staging, never on a dev's laptop.

Release checklist

Run this as a copy of the release checklist template in Notion; check items off for real, don't rubber-stamp.

T-minus 3+ days

• ☐ Go-live date/time agreed with client in writing. Default window: Tue-Thu, morning, team's working hours. Never Friday afternoon, never before a holiday.
• ☐ DNS / domain / SSL plan confirmed (who controls DNS? TTL lowered 24-48h ahead if cutover involves DNS)
• ☐ Production third-party services live-mode ready: payment keys, email/SMS providers with production quotas, OAuth redirect URLs, webhooks
• ☐ Production environment provisioned; env vars set and diffed against .env.example
• ☐ Data migration plan (if any) rehearsed on staging with a copy of real data; timings measured
• ☐ Rollback plan written (below) and understood by everyone on the release
• ☐ Monitoring in place: error tracking (e.g., Sentry), uptime check, log access; alerts wired to Google Chat

T-minus 1 day

• ☐ Code freeze: only S1 fixes merge
• ☐ Final regression: E2E green on staging; smoke checklist walked manually
• ☐ Database backup taken and restore actually tested (a backup that's never been restored is a hope, not a plan)
• ☐ Client informed of the go-live window and any expected downtime
• ☐ Release notes / changelog drafted

Go-live (the runbook)

1. Announce start in the project channel: "🚀 Release of starting."
2. Enable maintenance mode if downtime is expected.
3. Run migrations (with the measured timings from rehearsal; abort threshold agreed in advance).
4. Deploy the tagged release (git tag vX.Y.Z) via the CD pipeline.
5. Smoke test in production (15-30 min, two people): critical flows from the UAT script, a real payment in the smallest amount if payments exist (then refund), forms actually send email, analytics firing.
6. DNS cutover if applicable; verify propagation, SSL, redirects (www/non-www, http→https), old URLs 301'd per the redirect map.
7. Announce completion + release notes in the channel; PM informs the client.

T-plus (hypercare)

• ☐ Active monitoring for the first 24-72 h (named person per day, in the release checklist)
• ☐ Error budget: any new production S1 → hotfix; S2 within 2 business days
• ☐ T+3 days: short internal review: anything to add to this checklist for next time?

Rollback plan (written before every release)

Must answer, concretely, for THIS release:

1. Trigger: what failure means we roll back (e.g., checkout broken > 15 min, error rate > X%)? Who decides? (Default: Tech Lead decides, PM informs the client.)
2. Code: how to redeploy the previous tag; how long it takes.
3. Data: if migrations ran, what's the down-migration or restore path? What data written after go-live would be lost, and is that acceptable?
4. DNS: if cutover happened, what's the revert and its TTL delay?

If any of those four has no good answer, that's a release risk the Delivery Lead must accept in writing before go-live.

Hotfix process (production S1 at any time)

1. Declare in the project channel: "🔥 HOTFIX:
   ". Tech Lead is incident owner; PM handles client comms.
2. Branch hotfix/JX-xxx from main; smallest possible fix.
3. Fast-track review (one senior review, CI must still be green) → deploy → smoke test.
4. Post-incident note within 2 business days: what broke, why, prevention. Goes in the project retro and, if generally applicable, into this wiki.

✅ Exit criteria (gate to Handover)

• ☐ Deployed to production; smoke test passed and recorded
• ☐ Monitoring/alerting live; hypercare rota named
• ☐ Release notes shared with the client
• ☐ Rollback plan archived with the release record
• ☐ Project status moved to Live (Warranty)

← Phase 4 · Home · Next: Handover & Warranty →

Phase 6: Handover & Warranty

← Phase 5 · Home · Next: Monitoring & Bottlenecks →

Trigger: Successful go-live; status Live (Warranty). Phase owner: PM Warranty default: 30 days from go-live (defects only; see below), unless the contract says otherwise.

Step 1: Handover package (within 5 business days of go-live)

Assemble in the project Notion space and export/share per contract (template):

• ☐ Access & credentials transfer: hosting, domain/DNS, repo access (transfer or grant per contract), third-party accounts, admin users. Transferred via a password manager share, never email or Google Chat.
• ☐ Technical documentation: architecture overview, environment setup (README must let a competent outside dev run the project), env vars documented, deploy process, backup/restore procedure.
• ☐ User documentation: admin/CMS guide with screenshots for everything the client will operate themselves.
• ☐ Known-issues list (final, from UAT) and the release notes.
• ☐ Ownership map: what Jxing continues to host/maintain vs what the client now owns. Ambiguity here creates unpaid support work; write it down.

Step 2: Client training

1-2 recorded training sessions covering the admin/user documentation. Recordings linked in the handover package. Q&A gets appended to the user docs.

Step 3: Warranty period

Covered: defects: behavior that contradicts the signed PRD/UAT acceptance. Not covered: new features, content changes, changes of mind, third-party breakage outside our control. These are change requests or a support/maintenance contract.

Process: client reports via the agreed channel → PM triages within 1 business day using the same severity levels → S1 hotfix path, S2 within 3 business days, S3/S4 batched. Every warranty ticket is a Notion task tagged warranty.

Step 4: Project close

• ☐ Warranty window ended; open S3/S4 dispositioned with the client in writing
• ☐ Internal retrospective (60 min, whole team): what went well / what hurt / what changes. Every "what changes" becomes either a Notion task or an edit to this wiki. This is how the SOP improves: retro actions that touch process must be PR'd into these pages.
• ☐ Close-out email to the client: warranty ended, support/maintenance options, ask for a testimonial/referral while goodwill is at its peak
• ☐ Financial close: final invoices sent; actual hours vs estimate recorded in the Notion project record (feeds future estimation)
• ☐ Archive: Notion Tasks database closed out, repo tagged, Google Chat space archived after 2 quiet weeks
• ☐ Project status moved to Closed

✅ Exit criteria

• ☐ Handover package delivered and acknowledged by the client
• ☐ Training delivered, recordings shared
• ☐ Warranty completed; tickets resolved or dispositioned
• ☐ Retro held; actions assigned; SOP updates merged
• ☐ Status Closed

← Phase 5 · Home · Next: Monitoring & Bottlenecks →

Progress Monitoring & Bottleneck Management

← Handover · Home · Next: Roles & RACI →

Owner: Delivery Lead (portfolio level), PM (project level) Principle: you can't manage what nobody looks at. Monitoring here is a small set of rituals and signals, checked on a fixed cadence, with pre-agreed responses. No new tools required; Notion already holds the data.

The monitoring stack

RAG health (set weekly by the PM, honestly)

• 🟢 Green: on track for the next milestone date.
• 🟡 Amber: risk to the next milestone; mitigation exists and is being executed. Amber requires a written one-liner: risk + mitigation + date it resolves.
• 🔴 Red: next milestone will be missed without intervention. Red auto-triggers the escalation path.

Culture rule: Amber is information, not failure. A PM who flags Amber early gets help; a project that jumps Green → Red gets questions about why nobody saw it. Never punish honest Amber.

Weekly rhythm

Weekly client update (PM, every week, same day, even when there's little news)

Template (full version):

✅ Done this week
🔜 Next week
⚠️ Risks / decisions we need from you (with dates)
📅 Milestone tracker: <milestone> · <target date> · on track / at risk

Rule: anything the client owes us appears in every update until delivered, with the original due date visible. Politely relentless.

Weekly portfolio review (Delivery Lead + PMs, 30 min)

Walk the portfolio view: every 🔴 first, then 🟡, Greens get 10 seconds each. For each non-green: what's the blocker, what's the plan, what does the PM need. Decisions logged in Notion.

Blocker handling

A blocker is anything stopping a task from progressing for more than a few hours.

1. Flag immediately: tag the task blocked in Notion, comment what blocks it, who can unblock, since when. Say it in standup or the channel; don't wait for tomorrow's standup.
2. Owner: the PM owns every blocker's resolution path (not necessarily the resolution itself).
3. Aging rules (the heart of bottleneck detection):

A saved Notion view (tasks across all projects filtered to tag blocked, sorted by oldest last-edit) is the bottleneck dashboard. The Delivery Lead checks it across all projects twice a week.

Early warning signals

Leading indicators, checked at standup/sprint review. Each has a response; a signal you don't act on is decoration.

Bottleneck playbooks

Playbook 1: Client dependency stall

Symptom: content, assets, credentials, or answers overdue; tasks tagged client-dependency aging.

1. Same-day reminder in writing referencing the agreed date, restating what exactly is needed, in the smallest possible ask.
2. Offer to unblock differently: placeholder content, sandbox credentials, a 15-min call to extract the answer verbally and write it up ourselves.
3. Reorder the plan to keep the team productive; tell the client which milestone slips day-for-day from today.
4. Persisting > 5 days: Delivery Lead emails the client sign-off person with the day-for-day impact statement. Never eat the delay silently; silence converts their delay into our fault.

Playbook 2: Approval stall

Symptom: PRD, design, or UAT sign-off pending; revision rounds multiplying; "one more stakeholder" keeps appearing.

1. Re-anchor on the named sign-off person from kickoff. New stakeholders' feedback flows through that person.
2. Convert open-ended review into a deadline: "We'll treat the design as approved on unless we hear otherwise" (check contract wording first; the Delivery Lead sends this one).
3. Feedback beyond the included revision rounds → change request with cost/time. This usually focuses minds fast.

Playbook 3: Technical rabbit hole

Symptom: a task or spike keeps growing; "almost done" for a week.

1. Time-box: 1 more day, then a mandatory 30-min session with the Tech Lead + one other dev.
2. Decide: simplify the approach, buy instead of build, descope the edge cases, or re-estimate honestly and re-plan.
3. If it re-estimates > 3× original: PM treats it as a scope event: re-plan the milestone, inform the client if dates move.

Playbook 4: Review/QA pile-up (internal capacity)

Symptom: work done but waiting on one person (reviews, QA verification, design answers).

1. Make the queue visible: post the waiting list in the channel.
2. Redistribute: any competent senior can review; any non-author can QA-verify.
3. If chronic: it's a staffing/skills problem, not a process problem; the Delivery Lead addresses it at the portfolio level (hire, train, or rebalance projects).

Playbook 5: Person overloaded / single point of failure

Symptom: one person on the critical path for everything; their queue = the project's speed.

1. WIP-limit them harder (finish before starting), strip their non-critical work.
2. Pair a second person into their area; it costs speed for a week and buys resilience forever.
3. Document their tribal knowledge as they go (decision log, README) so this stops recurring.

Escalation path

Issue owner → PM → Delivery Lead → Client executive contact
   (hours)     (≤ 2 days)   (≤ 5 days)      (contract-level)

Escalation is a service, not a betrayal: it means "this needs more authority than I have," and the person escalating did their job. What gets escalated must arrive with: the facts, what's been tried, and a recommended option.

Metrics worth tracking (and no more)

Reviewed monthly by the Delivery Lead; recorded per project at close (Notion project record):

• Cycle time (task In Progress → Done; a last-status-change date property in Notion makes this cheap to track); the trend matters, not the absolute number
• Milestone slip (actual vs planned dates, per milestone); it feeds honest future estimates
• Blocker days (sum of days tasks wore the blocked tag, by cause: client / internal / vendor); the single best bottleneck lens: if 60% of blocker days are client-caused, fix contracts and kickoff expectations, not the dev team
• Reopen rate (tasks bounced back from QA); it measures the quality of acceptance criteria and craftsmanship
• Estimate accuracy (estimate vs actual at close); it calibrates the next proposal

Do not track: individual velocity comparisons, hours-typed, lines of code. They corrupt behavior and measure nothing a client pays for.

← Handover · Home · Next: Roles & RACI →

Roles & RACI

← Monitoring · Home · Next: Templates →

On a 2-8 person team, people wear multiple hats. That's fine. What is not fine is a hat nobody wears. At Phase 0, the Delivery Lead writes the name next to every role below in the Notion project record; one person can hold several roles, but every role has exactly one name.

Roles

RACI by activity

R = does the work · A = accountable, one letter per row · C = consulted · I = informed

Reading the gaps: if during a project someone asks "who's supposed to do X?" and this table doesn't answer it, that's a defect in the SOP; add the row at the next retro.

Worked example: DuitReady Affiliate & Matching Platform (V2.2)

A real application of the table above, using the signed DuitReady proposal: fixed price (RM 15,000 setup fee), a 6-week timeline across 5 phases, and milestone gates M1 to M7 with client sign-offs at M2 (System Design Sign-Off, Day 5) and M6 (UAT Sign-Off, Day 28). Fixed price + tight timeline means the RACI discipline matters more here, not less: every unowned decision burns margin.

Step 1: Assign the hats (Phase 0, Day 1)

Names below are illustrative; the Delivery Lead writes the real ones into the Notion project record at kickoff.

One person holding Delivery Lead + PM + part of QA is normal at this team size. What the table guarantees is that when "who chases DuitReady for the M2 sign-off?" comes up, the answer is written down (PM), not assumed.

Step 2: Read real rows against the project

PRD sign-off ↔ Milestone M2 (Day 5). The proposal's Phase 1 ends with System Design Sign-Off including the RBAC palette and the commission tranche schedule. Client is R (approving is their work), PM is A (makes the approval happen). If DuitReady goes quiet, the PM applies Playbook 2 immediately, because on a 6-week plan every silent day slips go-live day for day.

Coding & PRs ↔ Phases 2 to 4 (weeks 2 to 5). Devs are R, Tech Lead is A. Concretely: if the volume-tranche calculator rounds RM 75/RM 70 step-downs wrong at the 3,000-case boundary, the dev who built it fixes it, but the Tech Lead answers for it having shipped. The Designer is not in this row at all, which is also information: nobody waits on design for backend ledger work.

Change requests ↔ the Add-On list. Mid-build, DuitReady asks for SMS notifications. That is literally Add-On 5 in their own proposal (RM 5,000, 2 weeks), so the RACI row applies cleanly: PM is R/A for the CR form and impact estimate, Client is R for the decision (approve at cost, defer, or drop). No dev writes a line of SMS code before the written decision exists.

UAT logistics & sign-off ↔ Milestone M6 (Day 28). Phase 5 gives UAT one week. PM is A: prepares the UAT script from the proposal's workflows (borrower redirect flow, 24-hour IC lock behavior, agent dashboard statuses, CSV export alert), sets the 5-day window, chases daily. Client is R: their people run the script and sign. QA is C: on call to reproduce and triage what DuitReady reports.

Go/no-go ↔ Milestone M7 (Day 30). Tech Lead is A, alone. If Day 30 arrives and the HMAC webhook gateway still has an S2 bug, the Tech Lead holds the release even if everyone (including the client) wants to launch on schedule. The PM is R for running the decision meeting and communicating the outcome; the Delivery Lead is C, not the decider.

← Monitoring · Home · Next: Templates →

Templates & Checklists

← Roles & RACI · Home

Copy these into the project's Notion space. Keep templates boring and stable; improve them via retro actions, not ad-hoc edits mid-project.

T1: Intake Review

# Intake Review: <Client / Project>
Date: · Attendees: · Signed proposal: <link>

## In scope (as bullets, one deliverable each)
-

## Explicitly OUT of scope
-

## Promised timeline & milestones (from proposal)
-

## Sales assumptions to validate
| Assumption | Risk if wrong | Validate by |
|---|---|---|

## Client-side expectations not in writing
-

## Needed FROM client (owner + date each)
-

## Open questions for kickoff
-

T2: Kickoff Agenda

# Kickoff: <Project> · <Date, 60 min>
1. Introductions; single points of contact; SIGN-OFF PERSON (name: ______)
2. Scope walkthrough as we understand it
3. Open questions (from intake review)
4. Communication contract: weekly update day, demo cadence, response SLA (both sides), escalation contacts
5. Client dependencies calendar: item / owner / date
6. How we work: phase gates, written sign-offs at Discovery, Design, UAT; revision rounds included: __
7. Next steps & dates

T3: Discovery question bank (pick what applies)

Business: What does success look like in 6 months? Who signs off internally?
What happens if this launches late?
Users: Who are they? What do they do today instead? Top 3 tasks?
Content: Who writes/provides it? What exists? Migration from where?
Technical: Current systems? Integrations + who owns credentials? Hosting preferences/constraints? Compliance (privacy, industry)?
Traffic/scale expectations? Devices/browsers that matter (check their analytics)?
Constraints: Hard deadline and why? Budget beyond this contract (maintenance)?
Brand guidelines exist? Accessibility requirements?

T4: PRD skeleton

# PRD: <Project>  · Status: Draft / In review / SIGNED OFF (date, by whom)
1. Goals & success metrics
2. Users & key flows
3. Feature list (MoSCoW table: Feature | M/S/C/W | Notes)
4. Functional requirements (per feature: description, edge cases,
   acceptance criteria, Given/When/Then)
5. Non-functional: performance targets, browser/device matrix,
   accessibility level, security & privacy
6. Content & asset plan (what client supplies + dates)
7. Integrations (system | purpose | credentials owner | sandbox? )
8. Constraints & assumptions
9. Change log (vs signed proposal)

T5: Design Handoff checklist

- ☐ All milestone screens marked ✅ final; Handoff page organized by flow
- ☐ Components from the design system; detached instances justified
- ☐ States: empty / error / loading / success / long-content
- ☐ Responsive behavior specified per breakpoint
- ☐ Assets exportable; fonts licensed
- ☐ Microcopy final or marked placeholder (owner + date)
- ☐ Handoff meeting held on <date>; open questions logged as Figma comments
- ☐ Tech Lead acceptance posted in channel

T6: Test Plan

# Test Plan: <Project> · QA owner:
Scope: features in / out of this cycle
Environments & devices: (from PRD support matrix)
Test data & accounts:
Schedule: start / bug-fix loop / regression / done-by
Suites: manual checklist <link> · E2E suite <link> ·
        non-functional checks (perf targets, a11y, security hygiene)
Exit criteria: 0 known S1/S2; S3/S4 dispositioned; E2E green

T7: Bug report (Notion task template)

**Steps to reproduce:** 1. … 2. … 3. …
**Expected:**
**Actual:**
**Environment:** staging/prod · browser/device · account used
**Evidence:** screenshot / recording link
**Severity (QA sets):** S1 / S2 / S3 / S4

T8: UAT script

# UAT: <Project> · Window: <start> to <end> (5 business days)
Testers: <names> · Report issues here: <single link>
How to decide: Bug = doesn't match the PRD. Change = new idea → change request.

## Scenario <n>: <flow name>
Precondition: logged in as <test account>
Steps: 1. … 2. … 3. …
Expected result: …
Pass / Fail / Comments: ___

…(one block per key flow; cover every PRD Must)

## Sign-off
We accept this build for release, subject to the known-issues list <link>.
Name: ______  Date: ______

T9: Change request

# CR-<n>: <title> · Date · Requested by:
Description & reason:
Impact: scope (what's added/changed) · effort: <days> · cost: <if fixed-price> ·
        timeline: <milestone effect> · risks:
Options: A) Approve (dates/cost adjust as above)  B) Defer to phase 2  C) Drop
Client decision (written): ______ Date: ______

T10: Release checklist

# Release: <Project> vX.Y.Z · Go-live: <date/time> · Runbook owner: <Tech Lead>
T-3 days: ☐ date agreed in writing ☐ DNS/SSL plan (TTL lowered)
          ☐ third-party live keys ☐ prod env vars diffed
          ☐ migration rehearsed (timing: __) ☐ rollback plan written
          ☐ monitoring + alerts wired
T-1 day:  ☐ code freeze ☐ E2E green ☐ manual smoke on staging
          ☐ backup taken AND restore tested ☐ client informed
          ☐ release notes drafted
Go-live:  ☐ announce start ☐ migrations (abort threshold: __)
          ☐ deploy tag ☐ prod smoke test (2 people, checklist: __)
          ☐ DNS cutover + redirects verified ☐ announce done + notes
Hypercare:☐ monitor rota: D1 __ D2 __ D3 __  ☐ T+3 review done
Rollback: trigger: __ · decider: Tech Lead · code path: __ ·
          data path: __ · DNS revert: __

T11: Handover doc

# Handover: <Project> · Go-live date: · Warranty ends:
1. Access & credentials: transferred via <password manager> on <date>
   (hosting / domain+DNS / repo / third parties / admin users)
2. Technical docs: architecture <link> · README/setup <link> ·
   env vars <link> · deploy process <link> · backup & restore <link>
3. User/admin guide: <link> · training recordings: <links>
4. Known issues (final): <link> · Release notes: <link>
5. Ownership map: Jxing maintains: … · Client owns: …
6. Warranty: covers defects vs signed PRD until <date>. Excludes new
   features, content changes, third-party breakage. Report via: <channel>
7. Support/maintenance options after warranty: <link/summary>
Client acknowledgment: ______ Date: ______

T12: Weekly client update

# <Project>: Week of <date> · Health: 🟢/🟡/🔴
✅ Done this week: (3-6 bullets, in client language, not ticket IDs)
🔜 Next week:
⚠️ We need from you: item · owner · needed by · (original date if overdue)
📅 Milestones: <name> · <target> · on track / at risk (why + mitigation)

← Roles & RACI · Home