Blueprint-First Development

FlowForge builds the plan before it builds the code. A feature-sized change flows through a documentation discipline — requirements, architecture, design, a product brief — and only after the founder ratifies that plan does it become tickets. This chapter explains the flow and the two ideas that make it trustworthy: blueprints are sacred and two gates only.

The flow

A plain-language idea becomes shippable work through a repeatable path:

idea → requirements → architecture → design brief → PRD/po-brief → RATIFY → decompose → attached tickets

• Requirements capture the customer’s intent verbatim and pin down scope, acceptance criteria, and constraints — before any architect guesses at an API.
• Architecture and the design brief decide how it’s built and which guidelines govern each surface.
• The PRD / po-brief is the product-owner’s ratifiable statement of the work.
• Ratification by the founder turns the plan into authorization.
• Decomposition derives micro-tickets from the ratified plan — each one carrying a trail back to the clause it came from.

Blueprints are the source of truth

A ratified blueprint — a PRD, an ADR, a captured spec — is the source of truth. Implementation follows the blueprint, never the reverse.

When the code and the blueprint disagree, you do not quietly edit the document to match the code. You surface the gap, and the founder decides which side is correct. Ratified documents are amendable only by the founder or through an explicit ratification cycle. This is what “blueprints are sacred” means, and it’s why the manual you’re reading treats its own IA as subordinate to the ratified plan behind it.

The docs trail

Every ticket links back to the blueprint clause that produced it — the docs trail. That trail is what lets anyone, months later, ask “why does this exist?” and get a real answer that runs from a line of code back to a ratified decision. Feature-sized work is expected to carry its blueprint artifacts (requirements, po-brief, ADR — plus a design mockup where a screen exists) in that trail before code is dispatched. Trivial and bugfix work passes free — the gate is size-tiered so it never cries wolf on small work.

ADRs: decisions that stay decided

Architecture Decision Records capture the consequential forks — what was chosen, what was rejected, and why — in a git-mergeable, registry-tracked format. An ADR is how a decision stays decided: the next person doesn’t reopen it from zero, they read the record.

Two gates only

The plan designs exactly where the founder is asked to weigh in, and FlowForge adds no approvals beyond those. Founder touchpoints equal the gates the plan designed — no more.

Concretely: once the final design gate ratifies the plan, the ratified-plan record is itself the authority to emit that plan’s tickets. You never stack a separate “may I create the tickets?” ask on top of a gate that already passed. Tickets are derived from the ratified plan, never hand-created and never re-approved. A correct “plan a feature” run shows two founder touchpoints — ratify the plan, review before tickets are written — and no ticket-creation re-ask.

Do it right, and do it once

Blueprint-first is slower for the first hour and faster for every hour after. Deciding the architecture up front means you build the thing once instead of three times. The plan is the cheap place to be wrong; the code is the expensive place.

Why it matters

Blueprint-first development is how FlowForge keeps AI speed from turning into AI debt. The plan is ratified before the work exists, every ticket traces back to that plan, and the decisions behind it are written down where they’ll be found. The result is a codebase whose reasons are as legible as its code.