Architecture-first consulting: what it actually means

“Architecture-first” is a phrase that sounds good in a website hero and means nothing to the people buying consulting. Every agency will tell you their architects are senior. Every boutique claims it puts design before code. In practice most of them send junior developers to write code week one, then retroactively describe the result as an architecture.

So let's make it testable. Here is what architecture-first actually means in our engagements, and four specific things we refuse to do because of it.

Working definition

Architecture-first means: before the first line of production code, we have written down — and agreed with you — what the solution looks like, what parts of it are risky, and why we chose it over the three alternatives we considered.

Concretely, this is an Architecture Decision Document. It has three sections:

1. The diagram. A system-level drawing showing the pieces, their trust boundaries, and the main flows. Not a UML masterpiece — a whiteboard-quality picture that anyone technical can read in 90 seconds.
2. The decisions. 5–15 numbered ADRs (Architecture Decision Records). Each one says: “We chose X over Y because Z.” That's it. Future maintainers can skim them in ten minutes and understand why the system looks the way it does.
3. The risks. What can go wrong, what we think the probability is, and what we'll do if it does. Not performative hand-wringing — 3 to 7 real items that deserve attention.

That's the artifact. Its job is to make disagreements cheap and visible before they turn into reworked code.

Four things we refuse to do

1. We don't start with “let's just prototype”

“Prototype first, architect later” is a legitimate approach when the problem is clearly unknown. 95% of the time, the problem is known — it's the commercial team under pressure to show something quickly. Prototype-first in those cases produces code that ships to production without the architecture ever being written down. Six months later it's “the prototype” that everyone's afraid to change.

When a prototype genuinely is the right move (e.g. validating a novel technical assumption), we set a throwaway budget up front: two weeks, one developer, and explicit permission to delete everything.

2. We don't bill you to write general-purpose frameworks

Consulting projects have a bad habit of growing internal frameworks that only make sense inside the project. Custom form libraries, bespoke i18n wrappers, in-house state machines. They feel productive to the developer writing them and become a liability the second someone new joins.

The rule: if a reasonable third-party library exists, we use it. Chakra UI, React Hook Form, TanStack Query, Zod, Prisma — these aren't glamorous, but they're maintained by more people than any consulting project can match. We only build custom when the domain genuinely has no equivalent off-the-shelf option.

3. We don't separate “the architect” from “the engineers”

A classic failure pattern: the senior architect designs the system, junior engineers write it, and the architect disappears to the next project. Inevitable result — the junior team hits a design edge case that the architect never anticipated, improvises around it, and the architecture diverges from the diagram within weeks.

On our projects, whoever wrote the architecture writes production code in that project. Not as a control mechanism — as a feedback loop. If a design decision makes the code awkward, we notice that in week two, not in month six when the integration tests reveal it.

4. We don't do pure advice

We don't do the stereotype of “we'll write you a report and move on.” Written recommendations that nobody implements are worth nothing. Written recommendations that we help implement are worth what they were paid for.

When we write an architecture document, we either carry it through to delivery, or we hand it over with a named engineer who will — not a vague “maybe your team can follow the ADRs.” That usually means staying attached through at least the first production release of whatever the document describes.

Why this matters for your project

Most consulting horror stories trace back to one of those four things. The prototype that became production. The bespoke framework that nobody can maintain. The architect who vanished. The report that stayed in a shared drive.

Architecture-first consulting doesn't mean spending months before you see code. In practice, our architecture documents are typically written in 48 hours from the first conversation. They are short, opinionated, and wrong in small ways that get corrected in code. The point is not to freeze the design — it's to make the disagreements visible while they're still cheap.

If you're evaluating consulting options, the single easiest test: ask for the last architecture document they produced, redacted for confidentiality. If they have to invent one for the meeting, you know what you're buying.