Discovery

Discovery is the phase where we figure out what we're building and why. We map your goals, your current setup, and what good looks like. You get a written brief, a timeline, and a handover plan. No one starts design or build until we're aligned.

Why this step exists

Too many operational projects drift because the brief lives in someone's head. "We need better enquiry handling" can mean one intake point, or a full CRM overhaul, or something in between. Discovery makes that explicit. We agree what's in scope, what's out, and what success looks like. When we move to architecture and build, we're working from the same page.

It also surfaces what we don't know yet. Sometimes the real constraint is a particular tool, a team that won't adopt new systems, or a handover that always breaks. We'd rather learn that in discovery than halfway through a build. A few focused sessions upfront reduce rework and missed scope.

Discovery isn't about producing paperwork for its own sake. The output is practical: a brief we'll use as the source of truth, a phased timeline you can plan around, and a handover plan so you know what "done" means and what you'll run afterwards.

What happens in this phase

Mapping goals and current state

We talk through what you're trying to fix or improve. Enquiries slipping, jobs duplicated, visibility missing—whatever it is. We then map how things work today: where enquiries land, how they're assigned, what gets recorded where, and who owns what. We're not auditing individuals; we're capturing flows. We often do this in workshops or interviews with the people who do the work.

Agreeing scope and success criteria

We turn that into a shared brief. What's in scope, what's out, and what "done" looks like. We agree success criteria—enough to know whether we've delivered. We avoid vague goals like "better visibility"; we aim for "we can see pipeline value and job status in one place." You get to challenge and refine until it fits.

Producing a timeline and handover plan

We propose a phased timeline: when discovery ends, when architecture and build run, and when you expect to go live. We also define the handover plan—what we'll leave you with, who owns it, and what support looks like. You see the full arc before we commit to the next phase.

Validating with key stakeholders

We check the brief and timeline with whoever needs to sign off or be involved. We don't want to discover halfway through that finance or operations had different assumptions. Alignment early prevents surprises later.

Handing over the brief

You receive a written brief, the timeline, and the handover plan. We use these as the source of truth for architecture and build. If scope or priorities change, we update the brief and agree the impact. Nothing gets lost in verbal handoffs.

What we need from you

We need access to the people who understand how work actually flows—those who receive enquiries, assign jobs, and hand over to delivery. We also need a clear point of contact for decisions and sign-off. We'll use any existing documentation or process maps you have; we won't ask you to invent them from scratch.

• Key people available for workshops or interviews (typically 2–4 sessions)
• A single decision-maker or small group for scope and timeline sign-off
• Any existing process notes, tool lists, or pain-point summaries you’ve already captured
• Honesty about constraints: budget, timeline, tools you won't change, or teams that are hard to move

What you get out of it

You get a shared reference for the rest of the engagement. No more "I thought we were doing X" or "when did we agree to that?"

• Written brief: goals, scope, out-of-scope, and success criteria
• Phased timeline from discovery through to go-live and handover
• Handover plan: what you'll run, who owns it, what support we provide
• Clear alignment with whoever needs to approve or be involved before we move on

Common concerns

Time commitment. Discovery usually takes a few weeks, depending on how many people and systems we need to involve. We'll propose a schedule up front. Sessions are typically 1–2 hours; we don't run endless workshops. We can work around your calendar.

Disruption. We're not shutting down operations. We're having focused conversations and mapping flows. Most teams find it useful—it often crystallises things they’ve felt but not articulated. We minimise interruption and we don't demand full-day lockouts.

Cost anxiety. Discovery is a fraction of a full design-and-build engagement. Skipping it often costs more: rework, scope creep, or projects that deliver the wrong thing. We'll give you a clear cost for this phase so you can decide.

Tool access. We don't need admin keys to everything at this stage. We need to understand what you use and how data moves. That usually means screen shares, sample exports, or walk-throughs. We'll say clearly if we need deeper access later.

Confidentiality. We work with sensitive commercial and operational detail. We're used to it. We don't share your information outside the engagement, and we're happy to formalise that if you need it.

Internal buy-in. Some stakeholders want to "just start building." We've seen too many projects drift when discovery is skipped. We'll make the case calmly: aligned brief, fewer surprises, less rework. We can also use any discovery work you've already done; we're not redoing it for the sake of it.

A typical example

Illustrative example. A trades business had three enquiry sources—website, two job boards, and phone—and one person manually entering leads into a spreadsheet. Quotes were slow because job details lived in email threads. We ran discovery over two weeks: interviewed the director, the person handling enquiries, and two lead installers. We mapped the three intake points, the spreadsheet, and the quote process. The brief we produced scoped a single intake pipeline, clear assignment rules, and a simple handover to quoting. Timeline: six weeks to build, two weeks to embed. They signed off, and we moved to architecture. No surprises, no "we thought you meant something else."

Next step

Once the brief and timeline are agreed, we move to architecture: we turn the discovery output into a concrete design—workflows, data flows, and system choices—before we build. Read about the architecture phase, or get in touch to discuss starting with discovery.