The Project Playbook We Use on Every Project, Free to Copy

Most projects that go wrong don’t go wrong in the code. They go wrong in the first two weeks: a goal nobody wrote down, a stack picked out of habit, content that arrives a month late, an estimate that was one number on a napkin.

So every project we take on goes through the same eight stages, in order, before anyone writes code. We’ve put the whole thing on one page, and you’re welcome to copy it.

Open the project playbook →

The eight stages

Each stage produces something the next one needs. Skip one and the gap shows up later as rework.

1. Goal and purpose. Why build it, who uses it, which number should move, what’s in scope, what limits it, and who decides. The answers go into a one-page project brief, and the goal becomes one sentence the client signs off on.
2. New build or conversion. A new build starts from a blank page and the brief. A conversion starts from a system people use every day, and that system is the source of truth: match its behavior first, redesign later.
3. The stack. Database, backend, frontend, each answering a different question. We choose by team skills, typed code, the shape of the data, where the client already hosts things, and longevity, and we start with one app split into clear modules.
4. Text content. Late content is one of the most common reasons a launch slips. Collection starts in week one, in one inventory, with an owner and a due date on every row.
5. Media. The same tracking as text, plus the right format and size for the web and proof of the right to use every file.
6. The block diagram. Two drawings: the sitemap (what pages exist) and the system diagram (what runs where). Walk the client through both; anything they point at that isn’t drawn is new scope.
7. Work stories. Epics come from the big blocks, stories from the pages and features inside them, each with acceptance criteria a tester can check and a definition of done.
8. Estimates. Every story gets two numbers: AI time and Dev time.

Why two clocks

With AI agents doing much of the building, one hour figure per story hides where the time goes.

• AI time is the hours an agent spends building under a developer’s direction: writing the code, running the tests, fixing what fails.
• Dev time is the hours a person spends planning, reviewing, deciding, testing in the browser and talking with the client.
• Wait time, for content, approvals or access, goes on the calendar but never into the hour estimate.

Dev time shrinks more slowly than AI time, because review and testing take about as long whoever wrote the code. Small stories often carry as much Dev time as AI time. Splitting the two makes that visible to everyone, the client included, and after the first sprint the actual hours on closed stories show how good the estimates were.

What’s on the page

• Nine diagrams: the eight stages, the new-build-or-conversion fork, the three-layer stack, the content and media pipelines, a sitemap, a system diagram, the backlog hierarchy and where a story’s time goes
• An example project brief and an example story card with acceptance criteria
• A sizing guide from XS to XL in AI hours and Dev hours
• An example estimate: 15 stories in five epics, added up
• A kickoff checklist of twelve items you can tick off as the project moves (the ticks stay in your browser)

Copy it

Use it for your own projects and your own clients. Change the stages, rename them, put your own numbers in the sizing guide after a sprint or two. It’s a starting point, not a rulebook.

Open the project playbook →

Want us to run a project this way for you? Tell me what you’d like to build. Every engagement starts with a free 30-minute call, and stage 01 starts right there.