Think before you code, validate before you suffer!

A readiness playbook for software projects.

It defines the mandatory artefacts and the approval workflow every project goes through before any line of code, from business conception to the formal authorisation to start development (the Go/No-Go gate).

Rigour scales with project criticality: Low-criticality projects follow a Light Track (BRD + HLD combined into a one-pager); Critical projects follow the full flow. The BRD and the Go/No-Go are never waived.

The workflow

   Step 0 · Discovery / Spike ................. optional
        |
        | feeds
        v
   Step 1 · BRD ............................... approves: PM + Requester
        |
        v
   Step 2 · HLD (C4 L1/L2) .................... approves: Approving Tech Lead
        |\
        | \__ may start once the HLD is approved __
        |                                          \
        v                                           v
   Step 3 · LLD/TDD (C4 L3)              Step 5 · Technical Bootstrap
        |                                           |
        v                                           |
   Step 4 · SAD (consolidation)                     |
        |                                           |
        +---------------------+---------------------+
                              v
                     Step 6 · Go / No-Go
                              |
                +-------------+-------------+
                v                           v
         [ NO ] Blocked            [ YES ] Development starts

At any gate, a rejection returns to the producer with objective reasons. After three rejection cycles on the same step, the case escalates to the Architecture Team. The full specification is in the normative document.

Three mechanisms

Objective gates	Every step has verifiable entry (DoR) and acceptance (DoD) criteria; approval is not subjective.
Separation of duties	Whoever produces an artefact is never the one who approves it.
Self-sufficient handoff	Each step’s artefact must be enough for another team to run the next step without depending on the previous one. That is what allows internal, contracted and partner teams to alternate along the flow.

How to use it

If you are leading a new project

Read the main document, in particular Chapter 3 (who produces and who approves each step) and Chapter 8 (which track your project follows, by criticality).
For each step, copy the matching template, fill in the <...> fields and remove the italic instructions. Use the filled example as a model.
Only advance once the DoD is met and the formal approval is recorded in the Documentation Repository (the tool agreed between the parties at project start, e.g. Confluence, SharePoint, a Git wiki) or by e-mail with the requester.
The Go/No-Go (Step 6) authorises or blocks the start of development. Every mandatory item, and every applicable conditional one, must be complete with evidence.

If you are an approver

Your role, the review SLA (3 business days) and the rejection flow are in Chapter 4. You never approve an artefact you produced.

If you just want the gist

Read the Go/No-Go example and follow its links: it ties together every artefact of the reference case.

Scope and roadmap

Scope	Status
Day Zero Playbook — pre-development readiness	Published (v1.0)
Security: mandatory configurations	In progress
Development & Code Review · Deploy & Operations · Closure & Handover	Roadmap (post–Day Zero)

Out of scope

Everything after the Go/No-Go — branches, issues, code review, QA and closure — is out of scope for the Day Zero Playbook and is defined by each team’s own conventions; the playbook only asks that they be recorded in the Technical Bootstrap. Security is handled separately: until the Security companion is published, the minimum security baseline in Chapter 7 applies.

On agile and bureaucracy

The Day Zero Playbook is not a reaction against agile, and it does not exist to add control.

I work with agile. What this playbook covers is what happens before the first sprint: the alignment between business and technology that, when missing, comes back as rework mid-development. After the Go/No-Go gate, the team works the way it already works — the playbook ends exactly where development begins.

It does not invent a new process either. BRD, HLD, LLD/TDD, SAD, ADR and Go/No-Go already exist and are already practised, usually scattered and with no clear owner. What the playbook does is bring together resources that are already there into a single path, state who produces and who approves each step, and match the rigour to the project’s criticality — at Low criticality, BRD and HLD fit in a one-pager.

The goal is a healthy path: less rework, decisions with owners, and a development start that does not rely on guesswork. If on some project the playbook is producing paperwork instead of clarity, either the chosen track was too heavy for its criticality — or the playbook needs to change. Open an issue when that happens.