Small Architecture is not a process. It answers the two questions nobody bothered answering for small teams: when does architecture actually pay, and what is the smallest move that collects? Learn to recognize a handful of moments; each has one cheap move — a small diagram your agent drafts in minutes. Do only that, and you end up with the minimal viable architecture for your company.
- RULE 1A map you can't update in minutes is already dead.
- RULE 2Freshness beats validity.
- RULE 3Draw what means something.
The bug that wasn't in the code
Slotwise, a five-developer booking SaaS, shipped reminders: 24 hours before an appointment, the customer gets a text. It worked perfectly and support tickets went up anyway — the team used one word, "appointment", for three different things, and the reminders went out for open slots nobody had booked. The code was correct. The sentence the team had agreed on was not.
Every small team has a version of this story, and a second one behind it: the only person who really knows how the calendar sync works is one offer letter away from leaving. Both are architecture moments — missed not out of laziness, but because nobody ever said what an architecture moment looks like, or that the move it calls for costs an afternoon, not a quarter.
Architecture is a moment, not a phase
Architecture was sold to small teams as a phase (the design step before the real work), a role (a hire you can't afford), and a binder (the wiki diagram, wrong by June). None survives a five-person team shipping weekly — so small teams do none of it, and pay a tax that never appears on any invoice: bugs that were misunderstandings, onboarding measured in weeks, every hard question routed through one person.
The reframe the whole method rests on: architecture is a handful of moments per quarter where a small drawing changes the outcome of a decision. A recognition skill, then a cheap move — the drawing part is now agent work. What accumulates is your minimal viable architecture: a dictionary plus two to five one-screen diagrams. That's a ceiling, not a target — a company with one diagram it trusts is doing this better than a company with twelve it doesn't.
The moments
- The same word built two different things. → draw the Domain Model.
- A feature is about to touch your core objects, and everyone nods vaguely. → walk the Domain Model first.
- Every "what breaks if…?" routes through one person. → draw the System Map.
- An incident started with twenty minutes of archaeology. → draw the System Map; walk it in the postmortem.
- The third standup argument about how X actually works. → draw a Trace of one real case.
- A model feels abstract and the argument goes in circles. → trace one real case through it, with actual values.
- "Ask Sam how refunds work." → draw the Flow.
- You're about to automate a process. → draw the Flow first — the drawing is the spec.
- Someone new starts Monday. → read the maps together; that counts as a walk.
And the anti-moment: no question, no diagram. If you can't name the argument, the bug, or the decision a drawing would change, you're decorating. Skip it without guilt.
The four moves
Every hard conversation in a small team is one of four questions in disguise. Four questions, four diagrams — you'll likely never need all four. Adopt one when its moment arrives; let the next pain tell you if you need a second. Behind them sits the Dictionary: the 20 to 50 words your product runs on, one actionable sentence each, wired in so a rename propagates to every diagram.
1. The Domain Model — what do our words mean, and how do they relate?
Your business objects and their relationships, drawn as sentences: a Customer books a Slot; a Booking generates a Calendar event. Not your database schema. The benefit: arguments end by pointing — "can a Booking exist without a Customer?" found Slotwise a null-pointer path two weeks before a customer did.
Walk it when you merge a proposal, add a core concept, or onboard someone. Stale when the code grew a concept the model doesn't have — the agent will tell you. Refuses attributes for completeness' sake and anything a business person wouldn't recognize.
2. The System Map — what runs, and what talks to what?
The running system: services, databases, queues, external SaaS, labeled arrows for what flows where. Slotwise's map is twelve boxes. The benefit: the bus factor stops being a person — "what breaks if Redis dies?" becomes a thirty-second question.
Walk it after infrastructure changes, in postmortems, on someone's day one. Stale when a deploy moved a box and the map didn't. Refuses internal module structure; anything that isn't independently running.
3. The Trace — how does X actually happen?
One sequence, drawn small: parties as columns, numbered arrows, a note where a subtlety hides. No fragments, no loops — if the story branches, draw a second trace. Slotwise's first trace settled three standup arguments in six arrows: reminders query Bookings, not Slots.
Walk it when the code path changes — that's it; traces are cheap on purpose. Stale? Often better deleted than repaired; if the question returns, redraw in ten minutes. Refuses alt/loop fragments, activation bars, return arrows.
4. The Flow — how does work get from A to done?
One process picture: steps, decisions with labeled outcomes, a fork where things genuinely run in parallel. No swimlanes. Nine boxes ended Slotwise's era of "ask Sam how refunds work" — and made the decision points visible, which is where processes actually go wrong.
Walk it when the policy changes or its owner hands it over. Stale when the team does something the diagram doesn't say. Refuses swimlanes and exhaustive exception handling.
For all four: one question, one screen, one human owner. If you can't name the question, delete the diagram.
Keeping them true
No documentation sprint, no calendar ritual. The agent watches your codebase for drift and proposes changes on a branch, the way a colleague prepares a pull request; you review like you already review, in minutes, because every diagram is one screen. And the method's most contrarian call: freshness beats validity. Don't ask "is this diagram valid?" — ask "who last walked it, and when?" "Walked by Lena, January 12" tells you exactly how much to trust a map. A stale green badge tells you a comforting lie. For the rare moment that deserves more, an owner can freeze a diagram — deliberate and visible, like protecting a branch. Never required.
Day one: "draw my product"
One moment the list above can't teach you to see: all the moments you've already missed. So you don't start with a workshop — you tell your agent to draw my product. It explores the codebase, judges which diagrams mean something (one may be enough), drafts them, lints its own work, and returns a report: what I drew and why, where the code disagrees with itself, which words you use inconsistently, what only a human can answer. Slotwise's first session wasn't spent drawing boxes; it was spent arguing about what "Slot" means — a year of missed moments, collected in one afternoon. The exit criterion: you know when to draw, and it costs you nothing to be right.
A default, not a wall
Koncept gives the four moves a home — native diagram types, threads anchored to the exact node, walks recorded, branches for proposals, and an MCP server that hands your agent the same pen you hold. But you don't have to adopt the method, because your agent already practices it: it lives in the agent's authoring guide, not in walls. Use Koncept freely; the fresh diagrams and the walk trail accumulate as a side effect. Methods used to demand discipline from humans. This one ships with its own practitioner.