Architecture Session: Lock the Blueprint Before Code

The pattern repeats often enough to be predictable. A team starts a build with a working brief, a rough technology preference, and the assumption that the architecture will reveal itself as the product matures. Sprint one ships a thin slice. Sprint two adds a second feature that quietly couples to the first. By sprint six, every new ticket touches three modules nobody intended to connect, the database schema has grown six accidental columns, and the team is debating whether the next feature is a refactor or a rebuild. The engineering effort was real. The architecture was improvised.

An architecture design session is the working session that prevents this. It is a structured meeting — not a slide review, not a kickoff call — that locks the technology stack, the data model, the API boundaries, and the integration approach before sprint one begins. The decisions are written down as Architecture Decision Records (ADRs) so anyone who joins the team in month four can read the answer to "why is it built this way?" instead of reverse-engineering it from the code. In the Built to Last™ 2.0 framework, this session sits at the foundation of P03 — The Right Architecture — and what gets decided here determines the cost of every feature that follows.

What follows is a walkthrough of what actually happens inside the session: who is in the room, the order the decisions are made, what gets documented, and how to tell whether your project needs one before the next sprint planning meeting.

The Cost of Improvising Architecture

Improvised architecture is rarely catastrophic in any single sprint. It compounds. The first sprint picks a framework because the lead developer is fluent in it. The second sprint chooses a database because the framework's ORM defaulted to it. The third sprint adds a queue because a feature needed asynchronous work, and the queue is stitched into the application instead of treated as a boundary. None of these are bad decisions on their own. They were just made one at a time, with no view of where the system needs to be in three years.

By month nine, the team is paying the bill in three places. New features take longer because they touch tightly coupled modules. Hiring slows because the system is hard to explain to candidates. The roadmap conversation circles back to "we'd need to re-architect to do that properly" — a phrase that means the architecture decisions of sprint one are now blocking the business decisions of sprint forty.

The cost is real and well documented in industry surveys. Engineering teams consistently report that thelargest drag on productivity is not unfamiliar technology but tangled systems whose original design assumptions no longer hold. A locked architecture does not eliminate that risk. It pushes the design decisions to the moment when they cost the least to make and the most to get right.

This is why EB Pearls — across 600+ products shipped since 2004, with a 98% on-time delivery rate over the past 12 years — runs the architecture session before sprint one rather than absorbing architectural drift across the first three sprints. The pattern is consistent: projects that lock architecture early ship faster past the 18-month mark.

Who Needs to Be in the Room

The session only works if the people who can lock decisions are present. Architecture by committee produces architecture by compromise — broad, defensive, and overbuilt. Architecture by absent decision-makers produces architecture by retrofit.

On the client side, that typically means the CTO or engineering lead, the product owner who understands the roadmap, and — for mobile, custom software, or TaaS engagements — whoever is accountable for the budget. If the product touches existing systems, the engineer who knows the most about those systems attends, even if their role is normally junior. They hold the constraints the session will not learn any other way.

On the EB Pearls side, the session is led by a senior solution architect with delivery experience across the relevant service line. Depending on the project, a data designer, a security specialist, or a DevOps engineer joins for the segments that touch their domain. The room stays small. Five to seven people, decision-makers only.

If a key decision-maker cannot attend, the session does not run. Decisions made without them either get unmade later or quietly drift into the codebase as the team builds against best-guess interpretations. Rescheduling costs hours. Rebuilding against a wrong decision costs months.

How the Architecture Session Works, Step by Step

The session is sequenced. Each step produces a decision that feeds the next. The order matters: locking the data model before the technology stack, for instance, surfaces requirements that change the stack choice. Here is what happens, in order.

Step 1: Restate the Commercial Problem and Non-Functional Requirements

The session opens by restating the commercial problem locked in the Discovery Workshop™ and translating it into non-functional requirements — the constraints that architecture decisions must satisfy. Expected concurrent users at launch. Expected concurrent users at year three. Acceptable latency. Data sovereignty. Compliance regimes (Australian Privacy Principles, GDPR, PCI-DSS, HIPAA where relevant). Uptime target. Disaster recovery posture.

These are not aspirational numbers. They are the numbers the business will be measured against. A product that needs to support 50,000 concurrent users at year three has different architectural requirements from one that needs 500, even if the feature lists look identical at launch. Most architecture failures trace to non-functional requirements that were never written down. The team optimised for the functional features and discovered the load profile in production.

Step 2: Map the Domain and the Data Model

Before any technology is selected, the session maps the domain. What are the core entities? How do they relate? Which entities will exist at 10x scale that do not exist now? Where will the data come from, and who owns it?

The data model is the most expensive part of a product to change after launch. A schema decision made on sprint one assumption almost always survives until a migration becomes the only option, and migrations across 18 months of production data are weeks of careful work that ship no new features. The session locks the core entities, the relationships, the audit and soft-delete strategy, the indexing approach for the queries the product will run most often, and the boundaries between transactional and analytical data.

What this surfaces, almost every time, is one or two entity definitions the team disagrees on. A "user" might mean three different things to three different stakeholders. A "transaction" might be a single row in one mental model and a state machine in another. The session resolves the disagreement on paper, before the code makes the disagreement permanent.

Step 3: Define API Boundaries and Module Seams

Once the domain is mapped, the session defines the module boundaries — what is an independent module, what is a service, what speaks to what across which interface. This is where the difference between a maintainable system and a tangled one is decided.

The discipline here is API-first thinking. Every module exposes a deliberate contract, not just whatever functions the next module happens to need. Boundaries are drawn around business capabilities (payments, identity, notifications) rather than around technical layers, because business capabilities evolve at different rates and benefit from independent change. A modular monolith with strong internal contracts is almost always the right starting point — microservices come later, when the operational maturity to run them has been earned.

The output of this step is a diagram and a written description of each boundary. What the boundary owns. What it exposes. What it depends on. Which boundaries can be deployed independently in future. This is what makes adding a fourth payment provider in year two a sprint instead of a refactor.

Step 4: Select the Technology Stack Against the Requirements

Only now does the session pick the technology stack. Framework, language, primary database, cache, queue, search, observability stack, hosting platform. The order is deliberate: by the time the team selects a stack, the requirements that the stack must satisfy are already written down.

The selection is not about developer comfort. It is about fit against the requirements, the team's ability to operate the stack at year three, the hiring market, and the exit cost if the stack is later wrong. A stack that lets the team ship in week one but cannot support the year-three load profile is a stack that buys six months and costs eighteen. A stack that requires a six-month hiring effort to find engineers who can operate it is a stack that buys nothing.

This is where conflict between the right architecture and the project budget tends to surface — and the session is built to surface it. If the requirements need a stack the budget cannot support, the session names the trade-off explicitly. Reduce the requirements, increase the budget, or accept a deliberate technical debt entry with a paydown schedule. What the session does not allow is the silent compromise that becomes a rebuild conversation in month twelve.

Step 5: Map the Integration Architecture

Most products do not stand alone. They integrate with payment providers, identity providers, CRM systems, analytics platforms, government APIs, third-party data sources, and other internal systems. The integration architecture is the part of the system that absorbs change least gracefully when it is not designed.

The session maps every integration the product needs at launch, every integration it will need by year two, and the authentication and data-flow shape of each one. Synchronous or asynchronous. Idempotent or not. Retry policy. Failure mode. Where the integration sits relative to the module boundaries defined in step three.

The discipline is to design integrations behind interfaces, not against the third-party's SDK directly. A payment provider integration that sits behind a payment-port interface can be swapped or supplemented in a week. The same integration with the provider's SDK woven through the checkout flow takes two months to replace. Imagine a checkout product whose costs depend on the provider it routes through — designing the port up front means that routing decision is configuration, not a refactor.

Step 6: Lock the Cross-Cutting Concerns

Authentication, authorisation, secrets management, logging, structured error handling, observability, feature flags, multi-tenancy if relevant. These cross-cutting concerns affect every module the team builds, which means they are either decided once at the architecture session or re-decided incompletely in every sprint.

The session locks the approach for each. Which identity provider. Which secrets manager. What goes in structured logs. Which metrics are emitted by default. How feature flags propagate across modules. How multi-tenant isolation is enforced — at the row level, at the schema level, at the database level — and what the operational cost of that choice is at 50, 500, and 5,000 tenants.

The cost of getting these wrong is rarely visible until the system is in production. The cost of getting them right is one structured conversation up front.

Step 7: Apply the Three-Horizon Test

Every decision made in the session is tested against three horizons before it is locked: today's build, 10x scale, and the business in three years. If a decision passes today but fails at 10x, it is either re-decided or accepted with a documented re-architecture trigger. If a decision passes 10x but builds the wrong shape for the three-year roadmap, the same.

The three-horizon test does not require the team to predict the future. It requires the team to articulate the conditions under which today's decision needs to change, and to write those conditions into the ADR. When the conditions arrive, the conversation is "this trigger fired, here is the planned response" instead of "how did we end up here?"

Step 8: Document Every Decision as an Architecture Decision Record

The session output is a set of Architecture Decision Records. Each ADR captures one decision in a consistent structure: the context that made the decision necessary, the alternatives considered, the decision itself, and the consequences — what the decision enables, what it forecloses, what it costs.

ADRs are written into the codebase, not stored in a wiki the team forgets about. They live alongside the code so anyone reading the code can find the answer to "why is this here?" without asking the engineer who wrote it. A typical architecture session produces ten to twenty ADRs covering the major decisions; ongoing decisions during the build add more, each one signed off by the named decision-maker.

The Locked Scope Document™ and the Architecture Decision Records together form the documented backbone of the engagement. Everything downstream — sprint planning, code review, the Production Readiness Review™ before launch — references these documents as the source of truth.

What Good Architecture Sessions Produce — and Where They Still Fail

A well-run session produces a system that is cheaper to extend at month eighteen than it was at month one, because every extension fits the seams already drawn. The development team starts with module boundaries to build inside, not boundaries to discover. The client starts with a documented architecture they can show to investors, auditors, and future engineering hires.

The failure modes, even when a session is run, are worth naming. The most common: the session ends with decisions agreed verbally and never written down as ADRs. Six months later, the verbal agreement has fragmented into three different recollections and the architecture has drifted to match the loudest recollection. The fix is the ADR discipline — no decision is locked until it is written.

The second failure mode is decisions made without the three-horizon test, locking the team into a shape that fits sprint one but not the year-three roadmap. The fix is to apply the test to every significant decision, not just the headline ones. A logging library choice or a queue selection can constrain the architecture as much as the database choice if it is made without the horizon view.

The third failure mode is subtler: the session optimises for elegance instead of operability. An architecture is only as good as the team's ability to run it in production. A beautifully designed event-driven system that requires a dedicated platform team to operate is the wrong architecture for a startup with three engineers, regardless of how well it scales. Operability is a non-functional requirement, and the session must treat it as one.

Two Builds, Two Approaches

A Sydney-based startup we are familiar with chose a monolithic Rails application because the founder was fluent in Rails and the team was small. The first six months delivered features fast. The product hit early traction. Then the product roadmap added real-time messaging, event-driven workflows triggered by external webhooks, and a third-party integration that required asynchronous retry logic. None of these were in the original brief. None of them fit the original architecture. The next twelve months were a slow rebuild — features still shipped, but the team spent roughly as much time refactoring the application's seams as adding new capability. The engineering quality was fine throughout. The architecture decision in week one had simply made the wrong assumption about year two.

Contrast that with a similar-stage startup that ran a full architecture session before sprint one. The session surfaced — through the three-horizon test — that the roadmap included asynchronous, event-driven work even though the launch product did not. The team chose a modular monolith with clearly defined event-publishing boundaries and a queue that sat behind a port interface. Launch came in on the same timeline as a comparable Rails build. When the real-time and webhook features arrived in year two, they fit the existing seams and shipped without architectural rework. The product scaled to roughly 10x its launch load without a rebuild.

Neither outcome is guaranteed by an architecture session. The session does not predict every requirement. What it does is force the trade-offs into the open at the moment when changing them is cheap, instead of leaving them buried in code where changing them is expensive.

When the Architecture Session Is Critical — and When You Might Defer It

The architecture session is critical when you are starting a new build with a roadmap that extends past six months. If the product needs to exist in three years, the architecture decisions made before sprint one are the decisions that determine whether year three is profitable extension or expensive rebuild. It is also critical when the product will integrate with three or more external systems, when it operates under a compliance regime that constrains data handling, or when the engineering team is not yet large enough to absorb mid-build re-architecture without slipping the roadmap.

It is essential for mobile builds where platform decisions (native iOS, native Android, cross-platform, offline-first) propagate through every feature. It is essential for custom software where the data model and the integration surface determine the cost of every feature for the next five years. And it is essential for TaaS engagements where the squad's first three months produce the architecture every subsequent quarter will live inside.

Where you might defer it: if you are adding a well-bounded feature to an existing product whose architecture is already locked and documented, and the feature fits inside an existing module without changing its contract. In that case, a smaller architecture review is enough — the full session's outputs already exist for the rest of the system. The deferral applies to the feature, not to the product. Even experienced teams occasionally discover that a "well-bounded feature" hides a cross-cutting concern that a one-hour architecture review would have caught before three sprints of partial work.

What to Do Next

If you are about to start a build that has a roadmap longer than six months and no documented architecture, the architecture session is the next step. It is one structured working day, not a multi-week engagement. The outputs — the ADRs, the data model, the module boundary diagram, the integration map — become the documented backbone of the build.

For a deeper view of how the architecture session fits into the full build sequence, the project delivery framework walks through the cadence end to end. If you are weighing whether to commit to a build at all, the from concept to launch overview maps the earlier decisions that feed into the session.

Frequently Asked Questions