The Whole Picture (SDLC)

Every other page in this wiki answers one question well. This page answers the question you have when you have lost the thread: where am I, what has to be true to move forward, and who says yes.

This page owns the shape of the lifecycle — the sequence, the gates, and who decides. It does not restate the rules. Every stage links to the page that owns it, and if a number or threshold appears both here and elsewhere, the other page wins.

The engagement, end to end

flowchart LR
  L["Lead / Sales"] --> D["Discovery & BA"]
  D --> E["Estimate & SOW"]
  E --> K["Kickoff"]
  K --> P["Provisioning"]
  P --> B{"Build<br/>2-week cadence"}
  B --> G["Handover / go-live"]
  G --> W["Warranty"]
  W --> S["Paid support"]
  S --> C["Closure"]
  C -.new scope.-> L

Build is the only stage that loops — it runs continuously on a fixed 2-week cadence until the scope is delivered. Everything before it happens once per engagement, except Estimate & SOW, which is re-entered for every change request. Warranty and paid support are not events but open states that run from go-live onward.

#	Stage	Runs	Accountable	The page that owns it
0	Lead / Sales	Once	CEO	Decision Rights · Role Cards
1	Discovery & BA	Once	PM (BA does the work)	Discovery & BA Deliverables
2	Estimate & SOW	Once, re-entered per change request	CEO (PM drives)	Estimation · SOW Template
3	Kickoff	Once	PM	Kickoff Agenda
4	Provisioning	Once per repo/engagement	Backend Lead	New Project Provisioning
5	Build	Continuously, on a 2-week cadence	PM	Delivery Lifecycle · Boards
6	Handover / go-live	Once	PM	Warranty Boundary
7	Warranty	Fixed window from go-live	CEO (PM runs it)	Warranty Boundary
8	Paid support	Open-ended	CEO (L1 is first response)	Support Model
9	Closure	Once	PM	This page

One accountable role per stage — for the full R/A/C/I, see the RACI. Two things run in parallel with everything above: change requests and, after go-live, support and incidents.

Sell and set up

flowchart TD
  L["Lead"] --> Q{"Take the project?"}
  Q -- No --> X["Declined — logged"]
  Q -- Yes --> D["Discovery & BA"]
  D --> DE{"Backlog estimable?"}
  DE -- No --> D
  DE -- Yes --> E["Estimate — a PERT range,<br/>never a single number"]
  E --> S["SOW drafted"]
  S --> SG{"Client signs?"}
  SG -- No --> E
  SG -- Yes --> K["Kickoff"]
  K --> KE{"Scope · roles ·<br/>timeline · comms<br/>all agreed?"}
  KE -- No --> K
  KE -- Yes --> PV["Provisioning checklist"]
  PV --> R["Ready — the first story can start"]

• We estimate before we sign, and we scope before we estimate. Discovery ends at a defined exit — a backlog granular enough to price — not when the client stops talking. See Discovery exit criteria.
• Sales owns the lead and nothing else. No commitment a client hears is valid until the CEO confirms it. See Role Cards.
• Kickoff is not a meeting, it’s an alignment test. It is done when its exit criteria are written down, not when the invite ends. See Kickoff exit criteria.
• Provisioning is a checklist, not a judgement call. Same repo template, same pipelines, same branch policies, same four environments, every client. A repo missing a day-one file is not provisioned. See New Project Provisioning.

Build — the loop

This is where the wiki’s separate pages join up. One story runs this path; the board runs many in parallel under WIP limits.

flowchart TD
  RD["Ready<br/>Definition of Ready met"] --> IN["In Dev<br/>branch named for the work item"]
  IN --> PRO["PR opened<br/>small, self-reviewed, work item linked"]
  PRO --> BV{"Build validation<br/>+ code review"}
  BV -- red or changes requested --> IN
  BV -- green and approved --> MG["Squash-merge to main<br/>delete the branch"]
  MG --> DV["dev — auto-deploy"]
  DV --> QE["qa — auto-deploy"]
  QE --> QC{"QA against<br/>acceptance criteria"}
  QC -- failed --> IN
  QC -- passed --> UT["uat — promoted on approval"]
  UT --> UC{"Client sign-off"}
  UC -- change requested --> IN
  UC -- signed --> DN["Done<br/>Definition of Done met"]

Native mobile ships differently. Same board, same PR gates, same reviews — but a signed build promotes through the store’s own tracks instead of dev/qa/uat/prod. → Native mobile

The load-bearing rules behind that picture, and where each lives:

What holds it together	Owning page
Definition of Ready gates entry; Definition of Done gates Done. Don’t start a story that fails DoR.	Delivery Lifecycle
WIP limits per column, the work-item hierarchy, the expedite lane, branch naming	Boards & Work Items
The order you run this in, every day	The Daily Loop
GitHub Flow, PR size, reviewers, review conventions	Branching & Pull Requests
The blocking gate list, the environment ladder, build-once-promote-the-artifact, migrations, secrets	Pipelines & Environments
CI lanes, the diff-coverage gate, determinism, who writes which tests	Testing Strategy
The committed config that is the coding standard	Engineering Standards
Standup, weekly written status, client demo, retro	Communication Cadence

Note

Four things people get backwards. Testing is not a phase — it runs on every PR and blocks the merge. Developers write every automated test, in the same PR as the change; QA owns exploratory and manual regression. Architecture is decided as you build — an ADR merges in the PR that implements it, not in a design phase before it. And the artifact is built once and promoted; rebuilding per environment means nobody tested what shipped.

Ship

Going live is two separate approvals plus a commercial condition. All three are real.

What	Who
Go / no-go on quality and readiness	A two-key decision — one person alone cannot release
Promotion of the artifact into uat, then prod	A pipeline environment approval
Handover of code, credentials, and environment access	On final payment, not before — see Warranty Boundary

Before you get there, the system needs a complete runbook in the repo and L1 walked through it — otherwise support after go-live is a person, not a process.

Caution

Do not grant a client access to production credentials or the deployment environment before payment terms are met. Handover and final payment are the same event.

After go-live

Post-go-live work is not a separate process. It enters the same board — bugs and support tickets through the expedite lane, change requests through the normal backlog — and goes through the same branch policies and PR gates. One exception to the environment ladder, and only one: a hotfix/<id> branch can go straight to prod, under the same two-key approval as any release. Nobody takes that path alone. See Who Owns What and Boards.

flowchart TD
  R["Something arrives<br/>client report, demo feedback, telemetry"] --> T{"L1 triage<br/>PM decides warranty vs. billable"}
  T -- known issue --> KB["Closed from the repo runbook"]
  T -- production impact --> IC["Declare an incident<br/>set severity"]
  T -- our defect, inside warranty --> BG["Bug — expedite lane, free"]
  T -- new or changed behaviour --> CR["Change request — priced"]
  IC --> MT["Mitigate, then resolve"]
  MT --> PMO["Blameless postmortem<br/>if severity requires it"]
  MT --> BG
  BG --> BD["Back into the build loop —<br/>failing test first, then the fix"]

• The triage question is asked once, at intake: is this our defect, or is it new scope? L1 flags it; the PM decides it. Getting it wrong costs either trust or margin. See Who Owns What and Warranty Boundary.
• Support is tiered and business-hours. L1 → L2 → the original developer. There is no pager rotation, and we do not let one become an informal promise. See Support Model.
• Incidents have one channel and one client voice. See Incident Response and the Postmortem Template.
• A production bug gets a failing test before it gets a fix. See Testing Strategy.

Change requests

This page owns this process. Everything a client asks for beyond the signed scope comes through here — during build, during UAT, during warranty, and under a retainer.

flowchart TD
  IN["Request recorded at intake —<br/>PM during build, L1 after go-live.<br/>Never absorbed silently"] --> W{"Our defect against agreed<br/>acceptance criteria?"}
  W -- Yes --> FR["Not a change request — free rework:<br/>back to In Dev before go-live,<br/>warranty bug on the expedite lane after"]
  W -- No --> BA["BA writes it to the<br/>Definition of Ready standard"]
  BA --> SZ["Team Lead sizes it —<br/>a PERT range"]
  SZ --> IM["PM assembles the impact:<br/>cost · schedule · risk to<br/>committed milestones"]
  IM --> CE{"CEO approves —<br/>required when it changes cost"}
  CE -- No --> DF["Declined or deferred —<br/>logged, never deleted"]
  CE -- Yes --> CL{"Client approves<br/>in writing"}
  CL -- No --> DF
  CL -- Yes --> BK["Into the backlog,<br/>dates re-baselined"]

The rules:

1. Every request is recorded, including the ones we say no to. A request answered in a chat message and never written down is how scope creep starts.
2. There is no “small enough to absorb” branch. A change is either our defect — free — or it is priced. “It would be better if…” is a change request even inside the warranty window.
3. Re-estimate, never adjust. A change request gets a fresh PERT range, not a discount off the original.
4. No work starts without written client approval. This is a signed SOW clause, not an internal preference.
5. An approved change re-baselines the dates. If the timeline moves, the PM tells the client — that conversation never happens first at a demo. See Who Owns What.
6. Client requests come through the agreed channel — the PM during build, L1 after go-live — never a developer’s DM. An answer given in a DM becomes a commitment nobody priced. See Support Model.

Who decides what: the BA flags that something is out of scope, the PM decides that it is and proposes the change, the CEO approves anything that changes cost, and the client approves in writing before work begins.

Closing an engagement

This page owns this process. An engagement that is never formally closed leaves live credentials, live environments, and an open-ended support expectation nobody is charging for.

flowchart TD
  F["Final payment received,<br/>handover complete"] --> RB["Runbook complete in the repo,<br/>L1 briefed"]
  RB --> WE["Warranty window ends —<br/>client told the date in advance"]
  WE --> RT{"Paid retainer?"}
  RT -- Signed --> OP["Retainer in force — we keep prod<br/>plus the dev · qa · uat ladder<br/>we ship changes through"]
  RT -- Declined --> RV["Revoke our prod access —<br/>the client owns it outright"]
  RV --> DC["Decommission dev · qa · uat"]
  DC --> AC["Revoke remaining access,<br/>both directions"]
  OP --> EA["Estimate vs. actual review —<br/>feeds the next quote"]
  AC --> EA
  EA --> CL["Closed"]

• Tell the client the warranty end date before it arrives, along with what support looks like after it — a retainer, or nothing. A warranty that expires silently becomes an argument.
• Decommission dev, qa, and uat — only when there is no retainer. Under a retainer the whole ladder stays: a change still promotes build-once through dev → qa → uat → prod. See Pipelines & Environments.
• Access is revoked in both directions. The Team Lead revokes the client’s access to our repos and environments; the PM closes our access to client-owned systems — it is the PM’s row in Tools & Access; production credentials and Key Vault are the CTO’s.
• The runbook must be complete, not seeded, and L1 must have been walked through it. See Runbook Template.
• Compare the estimate to the actual, once, in writing. It is the only thing that makes the next quote better. Retros already handle the process lessons on the regular cadence.
• We do not archive documents into a second place. The board and the repo are the record. Copying them somewhere “for the archive” creates a copy that drifts — the same reason this wiki deletes rather than archives.
• We do not “release project resources.” Specialists are shared across concurrent projects by design; there is no allocated pool to hand back.

A follow-on scope is not a continuation — it re-enters at the top as a new lead, with its own discovery, estimate, and SOW.

Every gate, in order

Enforced means a tool refuses to proceed. Approval means a named person must say yes. Standard means it is written and expected, but nothing blocks you — which is exactly why skipping one is visible.

Gate	Type	Owning page
Take the project	Approval — CEO	Decision Rights
Discovery exit — the backlog can be estimated	Standard	Discovery
SOW signed, quoted as a range	Approval — client	SOW Template
Kickoff exit — scope, roles, timeline, comms	Standard	Kickoff
Repo provisioned — day-one files, policies, four environments	Standard, verifiable in a minute	Provisioning
Definition of Ready — entry to the board	Enforced — board column rule	Delivery Lifecycle
WIP limit per column	Enforced — board	Boards
PR links a work item, of the right type	Enforced — branch policy + build	Boards
Build validation — the blocking gate list	Enforced — branch policy on main	Pipelines & Environments
Test lanes and the diff-coverage gate	Enforced — same branch policy	Testing Strategy
Reviewer approval, self-approval off	Enforced — branch policy	Branching & PRs
QA against acceptance criteria	Approval — QA	Delivery Lifecycle
UAT client sign-off	Approval — client / PM	Delivery Lifecycle
Definition of Done — gates Done	Enforced — board column rule	Delivery Lifecycle
Promotion to uat, then prod	Approval — pipeline environment check	Pipelines & Environments
Go / no-go to production	Approval — two-key	Decision Rights
Hotfix straight to prod	Approval — same two keys	Who Owns What
Migration applied to uat / prod	Enforced mechanism + deliberate human step	Pipelines & Environments
Change request — client approval in writing before work starts, CEO first when it changes cost	Approval	Change requests
Handover on final payment	Approval — PM confirms	Warranty Boundary

When you are not sure who decides

Ownership is settled at one of three altitudes, and most arguments happen because someone reached for the wrong one.

Ask this first	If yes, read
Is it my role’s standing accountability?	Role Cards — then decide it yourself
Is it one of the six recurring cross-boundary calls?	Decision Rights (DACI)
Anything else	Who Owns What — and if it isn’t listed, PM for delivery or client, CTO for technical, then add the row

What this page does not own

Nothing on this page is a threshold, a limit, or a number you should quote from here. Definitions of Ready and Done, WIP limits, PR size, reviewer counts, coverage gates, environment approvers, the warranty duration, severity levels, and payment terms all live on the pages linked above — and those pages win. If this page and an owning page disagree, this page is the bug: fix it with a PR.