What is actually in the plan
Not a transcript of your answers. A structured document with a position on every decision that costs money.
What the plan is made of
- 38 Sections in the report catalogue (Every section that carries analysis, listed in full below. A cover completes the document; a given plan uses the sections its project needs.)
- 22 Analysis areas scored (Scored areas behind the recommendations — scope, cost, risk, compliance and the rest.)
- 6 Rungs on the reviewer Ladder (Candidate to Fellow. The criteria for each rung are published on the reviewer levels page.)
A recommendation you can argue with
The difference between a plan and a generated document is that a plan shows its working. Every section states what it recommends, what it rejected, and what would have to be true for the answer to change.
That is what makes it reviewable — by you, by your developer, and by an accredited reviewer who has built this kind of thing before.
- A position on every decision that costs money.
- The reasoning shown, not just the conclusion.
- Costs as ranges, with what moves them.
Inside the document
Scope
What is in, what is out, and what is deliberately deferred to a later phase.
Phases
An order of work that front-loads the parts that could invalidate the rest.
Tooling
Build, buy or automate — matched to budget and to the team you will actually have.
Costs
Ranges honest enough to plan against, with what drives them upward.
Team shape
The roles you need and the sequence to hire or contract them in.
Risks
What is most likely to go wrong, and the cheapest way to find out early.
Compliance
The obligations that apply to a project of this shape, flagged before design rather than after.
Reasoning
Every recommendation shows why. A plan you cannot argue with is a plan you cannot trust.
Export
A document you can hand to a developer, an agency, or a board.
The whole catalogue
| What it answers | Sections |
|---|---|
| The case for doing it | Executive summary, Business context & goals, Project scope, Stakeholders & roles |
| What it has to do | Functional requirements, Business rules, Non-functional requirements, End-to-end journey |
| How it gets built | System architecture, Technology stack, Data model, Backend & API, Frontend design, UI / UX & branding, Third-party integrations, AI & automation |
| Running it once it exists | Infrastructure, DevOps & CI/CD, Monitoring & observability, Testing & QA, Maintenance & lifecycle, Documentation |
| Obligations you inherit | Authentication & access, Security & compliance, Supply-chain security, Accessibility, Sustainability, Change management |
| Time, money and people | Team & delivery model, Timeline & milestones, Budget & financial, Vendor & procurement |
| Getting it used | Go-to-market & growth, Sales & customer success, Customer onboarding, Content & SEO |
| What to do next | Risks & recommendations, Next steps |
All 39 sections that carry analysis, grouped by the question they answer. A cover completes the document. Which sections a given plan uses depends on what you are building.
Tools the recommendations draw on
What it deliberately is not
- A quote. Costs are ranges, and they say what moves them.
- A contract. It is the thing you write a contract from.
- A substitute for judgement — yours, or a reviewer’s.
- Legal, financial or professional engineering advice.