Decisions your clients can read: a blueprint for Software Architecture

You carry the shape of a dozen systems in your head. Monday is an architecture review for a seed-stage startup. Thursday is a technical due diligence report an investor wants by Friday. In between you draw context and container diagrams, write decision records, and update a technical debt register nobody else opens. The method lives in a checklist in Notion, a slide deck from your last firm, and a custom GPT you trained on your own ADRs. Each new client gets a copy, and each copy drifts.

This page is a blueprint for a Flow Playbook that carries that method. It is not built. AI Consulting is a Playbook that exists today, and its launch story is the walkthrough for every step below. This blueprint is yours to take. Build it from your own know-how, put your name on it, and launch it as your Playbook. If you do, I would like to hear about it.

The opportunity

The money is moving fast and someone has to decide what it buys. Worldwide IT spending is expected to reach $6.37 trillion in 2026, up 14.2 percent, with software alone at $1,468 billion. The Bureau of Labor Statistics counts 1.9 million software developers, QA analysts and testers in the US, with about 106,100 openings a year. The people who lead them are fewer and cost more. Computer and information systems managers earn a median of $175,140, and the role is growing 16 percent over ten years. A startup that cannot pay that salary hires you by the day. That is the fractional market.

AI changed what a day of engineering produces. Stack Overflow found 84 percent of developers use or plan to use AI tools, yet 46 percent distrust the accuracy of what those tools write. DORA put use at 90 percent and found only 24 percent trust the output a lot. DORA calls AI a mirror and a multiplier. More code arrives sooner, so the decisions about shape and cost matter more. Flexera estimates 29 percent of cloud spend is wasted, and 85 percent of respondents call cost their top challenge. CNCF found 82 percent of container users run Kubernetes in production, and the top challenge is culture, not tooling. Your review names both in writing.

Rules are arriving with dates on them. The EU Cyber Resilience Act applies in full from 11 December 2027, and its reporting duties for exploited vulnerabilities start on 11 September 2026. Every product with digital elements sold into the EU will need a written handle on its parts and its fixes. A client will ask where that is written down. And the custom GPT you trained on your ADRs and your diligence checklist retires on December 11, 2026. A Playbook is plain files in your own GitHub. Nobody can retire it.

The signals

Each figure measures something narrower than it sounds. Surveys count who answered. Vendor research counts a vendor’s view. A market estimate is a model. Read them as a direction, not a forecast.

What your Playbook holds

The figure at the top of this page is the folder as it could sit on GitHub. Six Markdown files. Here is what each one does.

The README is the front page. It says who the Playbook is for, what a reader will have at the end, and the order to read the documents in. A stepped figure shows a system becoming a review, then a plan. An isometric figure maps the path.

Architecture Review Method is the backbone. The steps of your review, the diagrams you draw before you judge anything, and the checklist that must pass before findings go out. A Workflow Path draws the review from intake to report. A Diagram holds the C4 context view as text. The checklist is an Approval Card, so the record of who signed stays with the report.

Decision Record Standard is the craft. How an architecture decision record is written, what it cites, how it is numbered, and when a decision is superseded instead of edited. A Decision Brief draws a record from a page of notes. Every fact links to its source. What you have not confirmed is marked, and Flow counts the marks.

Debt and Cost Register keeps the technical debt and the cloud spend side by side, because one usually explains the other. A Register draws it, each row with an owner, a size and a date last checked. A Scenario Model shows three ways the bill could go. A chart shows spend by service.

Team and Diligence Guide is how you write the two notes clients ask for most. The team topology note says which teams exist, which should, and who to hire next. The due diligence report is what an investor reads before a deal. A Delegation Map draws the teams. A Scorecard rates the system against your headings. An intake form asks the first questions before the clock starts.

Worked Example is a review report, two decision records and a debt register for a made-up client, filled in end to end, with the choices explained. A reader learns more from one finished review than from ten rules.

What Flow does for this work

Chat answers from the folder, with the README’s questions. The README carries up to six questions, such as “What does a review cover?” An empty Chat offers four of them as buttons. A client’s lead engineer presses one and gets an answer linked to the page it came from. When the folder does not say, Chat says so.

A Skill named for the review itself. Run Workflow Path on the Review Method and the figure shows intake, diagrams, checklist, findings and plan in five steps. Run Register on the Debt and Cost Register and the rows come with owners and dates. Every drawing waits in Review Changes until you keep it.

The review checklist is signed in the document. The Approval Card holds your checklist. The lead engineer ticks each item, types a name and presses Sign off. Flow writes one signed record beside the report. Tighten the checklist next quarter and the card asks for a new signature. The old record stays, and Publish prints the card with its ticks.

A Job keeps the cost model current. The Register’s spend chart can be a Job. Each run asks only for its rows, from the bill the client brings in as a table or a price page brought in with New from Web Page and Follow the source. On a night when nothing changed, it skips without calling a model.

Sources and Change Summary on the due diligence report. An investor wants to know what a finding rests on and what changed since the last draft. Sources lists what the report was made from and marks a source that changed since. Change Summary says what moved, who moved it and on which day. A published page carries both as plain rows.

A door for your own agents. With Flow Pro, Settings ▸ General ▸ Your agents opens the folder to the Claude Code or Codex you already run against a client’s repository. It can read the Standard, search the Method and propose an ADR. The proposal lands in Review Changes under the agent’s name. Flow itself sends nothing anywhere.

How you build it in Flow

The AI Consulting story walks every one of these steps on a real screen. Follow it with your own material.

1. Add an empty folder and choose it. Chat answers from the folder before any document exists. The walkthrough shows it at an empty folder, and Chat already in it.
2. Ask Chat for the README. Describe who the Playbook is for and what you want a reader to have at the end. Chat writes it in your voice and marks every claim it cannot stand behind. See a front page, in the author’s voice.
3. Bring in what you already have. The review checklist from Notion, three past ADRs with the client’s name changed, the C4 review page you point people to. New from Web Page turns a page or a shared AI chat into a document with its links kept. See an old AI chat became a reference.
4. Let Ideas pick a Skill. Press Suggest on your Review Method. Ideas reads the sections and names a Skill for each, a Workflow Path for the review, a Register for the debt. A figure or a form waits in Review Changes until you keep it.

5. Ask Chat for the next document with your own pages as sources. The Decision Record Standard can be written from your Method and the three ADRs. Repeat until the path is done. See the next document, from his own pages.
6. Review every change. When you merge two checklist items or rename the Register, every page that pointed at it follows. See Review changed the plan, and the source followed.

Apply it to a client job

A Playbook is for using, not only reading. Say a made-up e-bike rental startup, Lantern Bicycle Co., asks for a review before its next round. Open the Playbook, start a folder for Lantern, and drop in their container diagram and last month’s cloud bill as a table. Ask Chat to draft the review report from the Review Method and to mark every line it is unsure about. The checklist tells you what to confirm before the findings go out, and the lead engineer signs it. Moving the job queue off the main database becomes ADR 007, written to the Decision Record Standard. The debt you found goes into the Register with an owner and a date.

When the investor’s questions arrive, the Team and Diligence Guide gives the report its shape. A question you had to research goes back into the Guide as a new section, and the next client starts from what you learned. A new engineer at Lantern can read the Method and the Standard on day one and write their first ADR the way you would. That is the bus factor answered one person at a time.

Lantern Bicycle, Review Notes.mdLantern Bicycle, Architecture Review Report.mdArchitecture Review Method.mdADR 007, Queue off the main database.mdLantern Bicycle, Architecture Review Report.mdREADME.md Imported · 3 to check4 claims to check1 change to reviewKeptAwaiting signature6 files sent

Lantern Bicycle Co.

Lantern Bicycle, Review Notes

Proposed

Image

Imported · 3 to check

Lantern Bicycle Co.

Lantern Bicycle, Architecture Review Report

Proposed

Diagram · C4 context

4 claims to check

Lantern Bicycle Co.

Architecture Review Method

Proposed

Workflow Path

1 change to review

Lantern Bicycle Co.

ADR 007, Queue off the main database

Proposed

Decision Brief

Kept

Lantern Bicycle Co.

Lantern Bicycle, Architecture Review Report

Proposed

Approval Card · Sign off

Sign off

Awaiting signature

Lantern Bicycle Co.

README

Publish · GitHub Repository

github.com/…/review-method

README.mdArchitecture Review Method.mdDecision Record Standard.mdDebt and Cost Register.md

Publish to GitHubCancel

6 files sent

01Start the client folder02Ask for the review report03Draw the review path04Record the decision05Sign off the checklist06Publish the update

Publish it, and keep it current

When the folder is ready, choose Publish and then GitHub Repository. Flow sends the files and nothing else. A reader brings the Playbook in with File, then New from GitHub, and the folder’s address. Check the repository’s visibility first. Your method can be public while every client’s diagrams, bills and code stay in their own folder on your Mac.

When a rule changes and you publish again, every reader’s copy shows the update as a change they review. They keep their own edits. Nothing is replaced behind their back.

The same source can also become a GitHub Pages site, a PDF, an EPUB, or Word and Excel files for a client’s team. Chat on the Playbook, and the figures a reader steps through, stay in Flow.

What it costs

Bringing any Playbook into Flow is free on Base. Writing with Chat, and Chat on a Playbook, need Flow Pro at $10 a month. Publishing to GitHub needs the Publish add-on too, another $10 a month. There is no fee per Playbook, so publish one or twenty for the same price. Any AI you connect follows the terms of that service. Publishing does not bring clients on its own. It gives the clients you earn a living copy of your method.

Start here

Read the walkthrough once, end to end. Then add an empty folder in Flow, name it, and describe your review method to Chat in three sentences. The README it writes is the first document of your Playbook. If you want to talk it through first, the Playbooks page has one email address and four questions.