Before we build,
we understand.
Every engagement opens with a dedicated phase to understand the problem worth solving, the people it affects, and the constraints that will shape the right solution. We call it Discovery.
What is Discovery?
Discovery is a structured period at the start of an engagement, typically two weeks, always shaped to the size and complexity of the work. It runs in person or remotely, depending on how the client team operates.
It exists to close the context gap. No consultancy walks into a new organisation with full understanding of its industry, its regulatory position, its legacy systems, or how its teams genuinely work. Discovery is how we get that understanding before any of it shapes a build.
Pressure to show value fast leads to building the wrong thing.
Budgets get approved. Procurement gets navigated. Leadership wants visible progress. The temptation is to start writing code on day one.
That temptation is what produces features users don't need, systems teams can't maintain, and engagements that ship outputs nobody integrates. We don't open engagements that way. We open with Discovery, because the cost of building in the wrong direction is far higher than the cost of taking two weeks to understand the right one.
That temptation is what produces features users don't need, systems teams can't maintain, and engagements that ship outputs nobody integrates. We don't open engagements that way. We open with Discovery, because the cost of building in the wrong direction is far higher than the cost of taking two weeks to understand the right one.
What we cover
Context and Constraints
The regulatory requirements that shape what's possible. The market dynamics the business responds to. The research already conducted inside the organisation, and the questions that research was trying to answer.
How Work Flows
The gap between the org chart and how teams actually coordinate. Who owns what. Where handoffs slow things down. How the current release cadence compares to where the organisation wants it to be.
Technical Reality
Architecture, technology choices, engineering practices, deployment processes, and how teams use their tools day to day.
Product Development
How the organisation validates that it's building the right product. What user research looks like, and how insights translate into prioritisation.
Team Capability
The maturity and shape of the teams we'll be working alongside. Observations made carefully and shared thoughtfully, used to tailor how we engage.
Getting to know your organisation
Most of what we learn comes from one-to-one conversations with designers, engineers, product owners, and leadership. These work best when they feel less like formal interviews and more like a genuine attempt to understand. We listen without judgement, document carefully, and look for the friction points that don't surface in group settings. The output is an honest picture of where the organisation stands.
We share what we find in two stages
Challenges are named alongside genuine strengths. Nothing gets dressed up or buried.
1
Senior stakeholders
The first playback is with senior stakeholders. They see the complete picture, including the observations that might be uncomfortable. This is where issues the organisation suspected get validated, and where blind spots surface that hadn't yet been named.
2
The wider team
The second playback is for the wider team. Not a censored version of the first; a focused one, shaped by the decision-makers, who own the content and decide what their teams need to know to collaborate well.
Discovery is how we de-risk the rest of the engagement
Why Discovery can’t be skipped
The pressure to skip Discovery and get straight to delivery is real. Budgets are tight, timelines are tighter, and the learning phase can feel like something to compress. Skipping it doesn't remove uncertainty. It defers it, and the cost of addressing uncertainty downstream is always higher than the cost of facing it at the start.
What Discovery makes possible
When we move into delivery after Discovery, the success metrics that matter are already understood. The technical debates worth having have been identified. We have a clear feel for where the team needs hands-on execution and where it needs strategic guidance. That contextual understanding is what often separates engagements that produce lasting change from those that produce outputs the organisation struggles to integrate once we leave.
Keep Reading
Artificial Intelligence
AI-Shaped Services
Strategy, governance, readiness and the delivery to back it up.
Learn More
Design
Product Design and Development
Senior designers creating user-centred products that balance usability and business goals.
Learn More
Engineering
Software Engineering
Experienced engineers building robust, scalable systems with a focus on what matters.
Learn More
Have a problem worth understanding properly?
That's where we want to start.