Phase 5 of 6

Run /visionaire:start

Works on what you already have. Reads your codebase before recommending anything.

Translates your UI/UX decisions into technical structure — components, data model, technology choices, and integration points — before a line of implementation begins.

Start my spec session — $297
$297 early access — first 100 builders  ·  Becomes $447 after
See how it works  →
One payment. Keep it forever. Runs locally. No telemetry.
05
Architecture
ARCHITECTURE.md
The system designed before the code is written.
ARCHITECTURE.md
F-001...F-N
BRIEF.md
1# ARCHITECTURE.md — ScopeGuard
2
3## User Journey Infrastructure Requirements
4↳ Sign-in journey requires: session store, auth middleware
5↳ Scope approval requires: audit log, approval state machine
6↳ Client review requires: token-based access, no login
7↳ Notifications require: real-time channel (Action Cable)
8
9## System Components
10Web App (Rails 8 monolith)
11 Owns: auth, business logic, API endpoints
12 Does NOT own: file storage, email delivery
13Action Cable — real-time scope change alerts
14Sidekiq + Redis — background processing queue
15PostgreSQL 16 — primary data store
10
11## Data Model
12Project → has_many Scopes
13Scope → has_many ChangeRequests
14ChangeRequest → belongs_to User
15 status: enum (pending, approved, rejected)
16
17## Technology Decisions
18Ruby 3.4 + Rails 8
19 Rationale: team expertise (8 yrs). Gained: velocity.
20 Trade-off: async I/O vs Node.js concurrency model.
21Heroku (initial deploy)
22 Rationale: managed infra, less DevOps overhead v1.
23
24## Integration Points
25 Stripe — payments, webhooks, retry logic
26 GitHub OAuth — authentication provider
27 Postmark — transactional email
28 AWS S3 — file storage (attachments)
29✓ User Journey Infrastructure Requirements present
30✓ All decisions trace back to journey requirements
31✓ Technology choices rationale present
32✓ Scope exclusions — no accidental enablement
33✓ All 8 criteria pass
34→ ARCHITECTURE.md APPROVED · Features phase ready
If you skip this phase
  • You will add the new feature where it fits the deadline, not where it fits the system.
  • You will leave technical debt you don't notice until the next feature hits the same spot.
  • You will refactor under pressure instead of designing under intention.

None of this is theoretical. These are the patterns that show up every time.

New features conflict with existing code. You either patch or refactor — neither option is free.

The Architecture phase reads your existing codebase before recommending anything. For greenfield projects, it designs the system from the experience outward. For existing systems, it understands what's already there — and places new capabilities correctly inside it, not bolted on from outside.

Technology chosen before requirements are read
The backend engineer chooses REST before seeing the UI/UX spec. Six weeks later, the real-time collaboration feature ships — and it requires WebSocket infrastructure that wasn't designed in. You're not picking between approaches. You're retrofitting a communication model onto a system that assumed a different one.
Decisions nobody can question six months later
A new engineer asks why you're using MongoDB. Nobody remembers. "We've always used it." The data is relational — users, projects, tasks with foreign keys and joins. MongoDB fights every query. You can't reverse it without a rewrite, and you can't question it without rationale nobody wrote down.
Trust boundaries that were never drawn
"User authentication" appears in requirements. Three engineers implement it three different ways — tokens in localStorage, httpOnly cookies, session storage. They all work until the security audit. 47 findings. 12 critical. A $250K contract lost because nobody drew a line and said "this is where the system ends and the external world begins."
Business logic scattered across unclear owners
Billing logic lives in: the API controller, a model callback, a background job, a helper module, and a service class. Nobody planned it. It grew there through accidental consistency. Changing the billing model now requires touching six files, understanding implicit dependencies, and hoping the model callback and background job don't conflict in the edge case.

One undocumented architectural decision costs 6–10 weeks of implementation rework. Architecture Phase catches them all before the first file is created.

From UX decisions floating in a document to a technical system ready for feature specification.

The Architecture Phase takes every screen, interaction, and constraint from UIUX.md and maps it to components, data, technology choices, and integration points — without writing a line of code.

After UI/UX Phase
Screen flows Interaction patterns Real-time needs Offline capability? Performance targets User journeys Data requirements? Which stack?
ARCHITECTURE.md
System components — named and bounded
Data model — entities and relationships
Technology stack — chosen with rationale
Integration points — explicit and scoped
Security model — designed in, not retrofitted
Stage gate — APPROVED before Features

What the phase reads before it asks a single technical question — and what that changes.

Your UX spec. Your existing codebase, if there is one. Architecture decisions that aren't grounded in what you've already built become technical debt before the first feature ships.

01
UX is read before any technical question is asked
The agent reads your UIUX.md in full, presents a comprehension summary of technical implications — real-time needs, data requirements, performance constraints — and waits for your confirmation before starting the interview.
02
One question at a time
Not a form. Not a checklist. The technical interview moves through seven areas — stack, boundaries, data, integrations, security, scale, deployment — one question at a time, adapting to what you say. Technology decisions stay with you.
03
A gap check before the outline is written
After the interview, the agent reviews UIUX.md again before writing a single section. Any UX requirement without architectural support triggers a follow-up question. Structural commitment waits until the gaps are closed.
04
You approve structure before detail is written
An outline is generated and presented for your approval before the agent writes six pages. Structural misalignment gets caught in one page, not discovered at the end of a document you now have to revise entirely.
05
Every technology choice documents what was traded
"Industry standard" is not rationale. Every decision in ARCHITECTURE.md names what was gained and what was sacrificed. Future engineers can question choices with full context. You can revisit decisions without starting the reasoning over.
06
Explicit over implied, always
"Payment processing" is not an integration point. Stripe with retry logic, webhook validation, and failure handling is. Component responsibilities are named. What they explicitly don't own is also named. Nothing is assumed.
07
Security is designed in from the start
Authentication strategy, authorization model, encryption decisions, audit logging requirements, and compliance constraints are all captured during the interview and reflected in ARCHITECTURE.md — not discovered during a security audit six months later.
08
A formal gate before Features begins
An autonomous reviewer evaluates ARCHITECTURE.md against eight criteria: presence and completeness of the User Journey Infrastructure Requirements section, architectural traceability (every decision traces there), architectural completeness, decision clarity and rationale, constraint alignment with the Product Brief and Design Intent, implementation readiness, journey coverage including destructive actions and onboarding, and scope exclusion compliance. APPROVED or REJECTED — no softened verdicts. Features phase does not begin until this passes.
Every architecture decision skipped becomes a constraint discovered mid-implementation.

One architectural pivot costs 6–10 weeks. This phase costs $297.

Start my spec session — $297
$297 early access — first 100 builders  ·  Becomes $447 after
One payment. Yours forever. Runs locally in Claude Code. 30-day guarantee.

Interview to architecture document in four steps.

Two mandatory checkpoints where the agent stops and waits before proceeding. You don't commit to structure until you've confirmed what was understood.

01

UX comprehension review

The agent reads UIUX.md and BRIEF.md, then presents a structured summary of technical implications: real-time needs, data requirements, performance constraints, and any UX elements that carry architectural weight. You confirm or correct. Nothing proceeds until you confirm the agent understood correctly.

02

Adaptive technical interview

One question at a time across seven areas: technology stack, system boundaries, data architecture, external integrations, security model, scale expectations, and deployment approach. Questions adapt based on your answers. You stay in control of every technology decision.

03

Outline presented for approval

After the interview, the agent runs a UX gap check against UIUX.md, then generates an architecture outline. You approve the structure — components, data model, technology stack, integration points — before a single page of detail is written. Structural misalignment is caught here.

04

ARCHITECTURE.md created and reviewed

The full document is written from the approved outline. An autonomous stage gate reviewer then evaluates it against eight criteria — anchored on the User Journey Infrastructure Requirements section, which every other decision must trace back to. APPROVED or REJECTED. Features phase begins only on APPROVED.

Stage Gate

Architecture has a formal quality-gate reviewer. Unlike the Idea Phase, Architecture cannot self-certify readiness. An autonomous critic evaluates ARCHITECTURE.md before advancing. A document missing rationale, unclear on component ownership, or silent on security will be REJECTED — and the specific gaps will be named. Every other phase (Product Brief, UI/UX, Features) also has a gate.

Greenfield, existing system, or UX requirements that surprised you technically.

Not an idealized clean-slate project. Architecture Phase works differently depending on what you're starting from — here's what that looks like.

Scenario 01

Your team has strong opinions about the stack but no agreed architecture

Everyone agrees on Rails. Nobody agrees on where business logic lives, how authorization works, or whether the real-time features need Action Cable or a separate WebSocket server. You're about to start building with six different mental models of how the system is structured.

The technical interview forces each question into the open, one at a time. By the end, technology preferences are captured as documented decisions with rationale — not tribal knowledge held in different engineers' heads. The outline shows you what you agreed on before anyone starts building.

What you walk away with

An ARCHITECTURE.md that documents component ownership, technology choices with rationale, and explicit boundaries between parts of the system — before the first line is written and before disagreements become undocumented code.

Scenario 02

You're adding a major feature to an existing system

ScopeGuard is live. Sarah Chen wants to add real-time scope change notifications — a fundamentally different interaction model than the current request/response pattern. The existing architecture wasn't designed for it, but a full rewrite isn't on the table.

Architecture Phase can be run against an existing codebase. The agent reads your current system structure before asking technical questions — understanding what constraints already exist, what can be extended, and where the new capability fits without creating a seam that users will feel.

What you walk away with

An architecture document that shows exactly how the new capability integrates with the existing system — what changes, what stays, and why — ready for feature specification without guessing at constraints.

Scenario 03

The UI/UX spec revealed requirements you hadn't anticipated technically

UIUX.md came back with offline capability, sub-300ms search, and a collaborative editing mode. None of these were in the original technical thinking. Features that seemed simple suddenly require IndexedDB, full-text search infrastructure, and WebSocket conflict resolution — decisions with real tradeoffs nobody has surfaced yet.

The UX comprehension review at the start of Architecture Phase is specifically designed for this. The agent reads UIUX.md and maps every requirement to its technical implication, then brings those implications into the interview as explicit questions — before they become implicit assumptions in a Features spec.

What you walk away with

Technology decisions made for the system you're actually building — not the simpler one you originally imagined — with every UX requirement accounted for before Features begins.

Phase 5 of six. The blueprint before the build.

After UI/UX validates the experience. Before Features specify what gets implemented. The point where thinking becomes structure.

Phase 1Idea
Phase 2Product Brief
Phase 3Market Validation
Phase 4UI/UX
Phase 5ArchitectureYou are here
Phase 6Features

You can skip this and move straight to Features.

Teams do it constantly. "We'll figure out the architecture as we build" is a decision — it just happens in code under pressure instead of in a document under deliberation.

Without Architecture Phase

Faster start, higher implementation cost

  • Technology chosen without reading UX requirements — mismatches discovered mid-feature
  • Component ownership undefined — business logic scatters across files
  • Security retrofitted after launch — authentication and authorization bolted on
  • Technology decisions undocumented — impossible to question or revisit with context
  • Feature specifications written on architectural assumptions that may be wrong
  • Integration points discovered when they block implementation, not before it begins
With Architecture Phase

Slower start, implementation that runs clean

  • Every technology decision made with UX requirements already read and mapped
  • Component boundaries explicit — responsibilities don't overlap, owners don't conflict
  • Security model designed in — auth strategy, authorization, compliance from day one
  • Every decision documented with rationale and tradeoffs — revisitable by anyone
  • Features written from architecture — zero ambiguity about what system they're built on
  • Integration points named and scoped before a single API call is designed

Architecture doesn't slow you down. It changes what Features is working with.

Features written from a documented architecture move faster and produce cleaner implementations than features written against an architecture that exists only in someone's head. The hours spent here aren't overhead — they're the decisions that determine whether implementation is clear or chaotic.

Two principles that shaped every decision in this phase.

"Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change."

— Ralph Johnson · Design Patterns: Elements of Reusable Object-Oriented Software

This is the operating principle behind every question in the Architecture interview. When the agent asks you to choose between REST and WebSocket, it isn't collecting preferences — it's forcing a decision with a known cost of reversal. Every question in this phase targets choices that are expensive to undo. That's what makes the hour you spend here worth more than the weeks you'd spend retrofitting later.

"Software architecture is those decisions which are both important and hard to change."

— Martin Fowler · Who Needs an Architect? (ThoughtWorks)

The inverse is equally true: if a decision isn't both important and hard to change, it doesn't need to be resolved at architecture time. The phase focuses exactly here — on the decisions that lock in early and echo through every feature that comes after. Naming the database. Drawing the trust boundaries. Choosing whether real-time runs through the web server or alongside it. These are the decisions you can't take back cheaply.

Every project that skips this phase has architecture. It just wasn't designed — it was discovered.

Discovered architecture inherits every assumption that came first. The engineer who touched it first. The deadline that was looming. The framework default that nobody questioned. Architecture Phase exists to make those decisions explicit before any of those pressures show up.

The architecture interview doesn't ask you to fill out a form. It asks you questions you haven't been forced to answer yet — in the order that your UX decisions demand them. That sequencing is the work.

Every technology choice you leave implicit becomes a constraint the next engineer works around without knowing why. Every undefined component boundary becomes business logic that lives where it shouldn't. This phase closes those gaps before implementation inherits them.

— Robert Evans

Works on what you already have.

Reads your codebase before recommending anything. No mid-build technology debates. No architectural surprises three weeks into implementation. Every decision made before the first file is created — and documented so anyone can question it later.

$297 < 1 architectural pivot · prevents 6–10 weeks of implementation rework
Start my spec session — $297
$297 early access — first 100 builders  ·  Becomes $447 after
One payment. Yours forever. Runs locally in Claude Code. 30-day guarantee.
View Sample ARCHITECTURE.md  ↑ Read Features Phase  →