Architecture

Architecture is where we turn the discovery brief into a concrete design. We define workflows, data flows, and how your tools connect. You get a blueprint we’ll build against—no vague "we’ll figure it out later."

Why this step exists

Discovery tells us what we're solving. Architecture decides how we'll solve it. Without it, build becomes a series of ad hoc decisions. We've seen projects where intake was "just enquirers into a list," but nobody had agreed whether that list lived in the CRM, a custom layer, or a spreadsheet. Architecture fixes that. We make the structural choices—what talks to what, who does what, what we build versus configure—before we write code or configure systems.

It also gives you a chance to react. We’ll show you flows, ownership, and integration points. You can say "we’d never do it that way" or "what about when X happens?" before we’ve built anything. Changing a diagram is cheap; changing a built system is not.

Finally, architecture creates a shared reference for build and embed. The team knows what we’re implementing. You know what you’re getting. Handover and training map back to the same design.

What happens in this phase

Turning the brief into flows and ownership

We take the discovery brief and flesh it out into explicit workflows. How do enquiries move from intake to assignment to follow-up? Who owns each stage? What triggers the next step? We draw this out—literally—so we can discuss it. We avoid jargon; we use your language and your examples.

Defining data flows and integrations

We map where data lives and how it moves. Which systems hold enquiries, jobs, quotes? Do we push from form to CRM, or pull from job board to a central list? We identify integration points, what we’ll use (APIs, webhooks, exports), and what we’ll build versus what we’ll configure. We’re clear about what’s robust and what’s fragile.

Choosing build versus configure

We decide what we build from scratch and what we do with your existing tools. Sometimes the answer is "configure the CRM and add a few automations." Sometimes it’s "build a lightweight layer that connects everything." We’ll recommend the simplest option that meets the brief, and we’ll explain why.

Documenting the design and getting sign-off

We produce a short architecture document: flows, data model, integrations, and build vs configure. We walk you through it and adjust based on your feedback. We don’t move to build until you’ve signed off. The document becomes the reference for implementation.

Aligning with build and embed

We hand the architecture to the build phase. The team implements against it. We also flag what embed will need—training, docs, support—so nothing’s left to chance when we go live.

What we need from you

We need your feedback on the flows and design. We’ll propose; you validate or correct. We also need clarity on any hard constraints—tools you won’t change, compliance requirements, or teams that need particular interfaces.

• Availability for 1–2 review sessions to walk through flows and integration choices
• Decisions on "build vs configure" where we’ve laid out options
• Any constraints we didn’t capture in discovery: tools, compliance, or ways of working
• Sign-off on the architecture document before we move to build

What you get out of it

You get a clear blueprint for what we’ll build and how it fits together. No black box.

• Workflow maps: how work moves, who owns it, what triggers what
• Data and integration design: what connects to what, and how
• A short architecture document that build will implement and embed will use
• Explicit "build vs configure" choices and the reasoning behind them

Common concerns

Time commitment. Architecture usually runs over one to two weeks after discovery. We’ll send drafts and schedule reviews. You’re not in workshops all day; we need focused feedback and sign-off.

Disruption. We’re not changing how you operate yet. We’re designing. Most of the work is ours; we pull in your input when we need to validate or decide. We’ll agree a rhythm that works for you.

Cost anxiety. Architecture is a defined phase with a clear deliverable. We’ll scope and price it up front. Skipping it often leads to rework in build—which costs more than doing it properly once.

Tool access. We may need to check APIs, exports, or config options for your existing tools. We’ll ask for the minimum we need. If we can’t integrate something, we’ll say so and suggest alternatives.

Confidentiality. The architecture will include your flows, tool choices, and sometimes sample structures. We treat it as confidential. We’re happy to formalise that.

Internal buy-in. Some people prefer to "see something working" before committing to a design. We get that. We’ll make the case that a clear design reduces risk and rework, and we’ll show you enough—flows, examples—that it feels concrete. We’re not asking you to sign a blank cheque.

A typical example

Illustrative example. A professional services firm had discovery done: one intake pipeline, assignment by practice area, and clear handover to delivery. In architecture we mapped the flow in detail—form and email into a single list, routing rules, status stages, and handover checklist. We looked at their CRM and job tool; both had APIs. We proposed a small custom layer that connected form, email, and job board to the CRM, with routing and status in that layer. They signed off. Build implemented it; embed trained the team. The architecture document stayed the reference throughout.

Next step

With the architecture signed off, we move to build: we implement the design in phases, test with you, and iterate. Read about the build phase, or get in touch to discuss your project.