Build

Build is where we implement the architecture. We build or configure in phases, so you see working increments rather than a big reveal at the end. We test with you, fix issues, and iterate. By go-live, the system has already been used in anger.

Why this step exists

A lot of operational projects fail at the "big bang" moment. Everything’s built behind the scenes; then it goes live and reality doesn’t match the design. Build avoids that. We deliver in small slices—intake first, then routing, then handover, or whatever order the architecture dictates. You use each slice, we adjust, and we move on. When we flip the switch for real, we’re not hoping it works; we’ve already seen it work.

Phased delivery also reduces risk. If something’s off—a integration breaks, a workflow doesn’t fit—we catch it early. We’re not undoing months of work. We’re tweaking the last increment.

Finally, build is where we make the architecture real. The document tells us what to build; we implement it, document what we’ve done, and hand it over for embed. No gap between "what we agreed" and "what you get."

What happens in this phase

Implementing in phases

We break the architecture into phases. A typical first phase might be intake and routing; a later one handovers or reporting. We implement, test, and sign off each phase before we move on. You see progress; we don’t hide behind "almost ready."

Integrating with your tools

We connect to your inbox, CRM, job boards, or whatever the architecture specifies. We use APIs, webhooks, or lightweight automation as agreed. We test with real-like data and we’re clear about what’s robust and what might need care when vendors change things.

Testing with you

We don’t treat testing as an internal-only step. We run through scenarios with you—"here’s an enquiry, here’s how it’s assigned, here’s the handover." You try it. We fix what’s wrong. We repeat until you’re comfortable. That might mean a staging environment or a closed pilot; we’ll agree what fits.

Iterating based on feedback

We expect feedback. The architecture narrows the scope of changes, but we’ll still adjust details as we go. We scope and prioritise; we’re not rigid. We’re also clear when a change is "quick tweak" versus "scope increase."

Documenting and handing over to embed

We document what we’ve built: how it works, how to run it, what to do when something breaks. We hand that over to the embed phase for training and go-live. We’re available to fix teething issues and to support embed.

What we need from you

We need timely feedback on each phase. We also need access to systems we’re integrating with—often API keys, webhook endpoints, or test accounts—and someone technical enough to help if we hit auth or config issues. Finally, we need decisions when we present options; we don’t want build held up by slow sign-off.

• Feedback on each phase within an agreed window (we’ll propose timelines)
• Access to integrate with your tools: API keys, webhooks, or test environments as needed
• A technical contact for integration or config questions, if you have one
• Decisions on scope or prioritisation when we raise them—we’ll keep things moving

What you get out of it

You get a working system that matches the architecture, plus the documentation to run and maintain it.

• A built (or configured) system: intake, workflows, integrations, and any reporting we agreed
• Phased delivery so you’ve seen and used it before go-live
• Documentation: how it works, how to maintain it, what to do when things break
• A clean handover to embed for training and launch

Common concerns

Time commitment. Build is the longest phase. We’ll give you a timeline up front and we’ll flag dependencies—e.g. we need API access by X. Your main job is feedback and decisions; we’re not asking you to project-manage us.

Disruption. We build in staging or pilot where we can. Live operations don’t switch over until we’ve tested and you’re ready. We’ll agree a go-live plan so you control when the cutover happens.

Cost anxiety. We scope and price build per the architecture. If you want changes that add scope, we’ll say so and we’ll agree before we do the work. No surprise invoices.

Tool access. We need to connect to your systems. That usually means API keys, webhooks, or similar. We’ll ask for the minimum we need and we’ll use test or staging where it exists. We don’t tinker with live data without your say-so.

Confidentiality. We’re building something that handles your enquiries, jobs, or other operational data. We follow your security expectations and we don’t store more than we need. We’re happy to formalise that.

Internal buy-in. Some stakeholders want "everything at once." We can plan a single go-live, but we’ll still build in phases internally. Phased delivery de-risks the project; we can align launches with your calendar. We’ll also involve the people who’ll use the system so they’re not surprised at go-live.

A typical example

Illustrative example. A trades company had completed discovery and architecture. Build was in three phases: (1) intake from website and two job boards into one list, (2) assignment and status in that list, (3) handover to their existing job tool. We built phase 1, connected their form and boards, and ran a fortnight of test enquiries with the office manager. We fixed routing and notifications, then moved to phase 2. Same pattern—implement, test, iterate. Phase 3 added the handover and a simple checklist. Go-live was a flip from pilot to live; they’d already been using it for weeks.

Next step

Once build is done and signed off, we move to embed: we train your team, support go-live, and make sure the system sticks. Read about the embed phase, or get in touch to talk about your build.