Skip to content

Services / Discovery

Launchpad engagement

The cheapest week you'll spend on the project.

Before you commit six figures and six months, spend a week. We embed, talk to the people with the problem, map the landscape, and prototype the answer so you can see it. You leave with a decision you can defend: what to build, what it will cost, and where the risk sits.

≈ One weekFixed scopeYou own everything
Discovery readout
Day 5

Recommendation

Build, in two phases

Start with the ingestion path. Defer the dashboard.

The risk we mapped

Real-time sync at scale, the assumption most likely to sink the project.

Verdict

Feasible. We prototyped it so you can see it. validated

Cost envelope

8 to 10 weeks · fixed scope · 2 engineers

Confidence

High

Yours to keep. Take it to your board, or to another team.

The stakes

The expensive mistake isn't bad code. It's the wrong thing, built well.

By the time you've hired the team or signed the agency, the riskiest decision is already behind you: what to build. Get it wrong and it won't matter how clean the code is. You'll have shipped exactly what was specced, and exactly the wrong thing. Discovery is how you find that out in week one instead of month six.

Most discovery

  • A month of workshops and stakeholder interviews.
  • A deck, a Gantt chart, a backlog nobody fully trusts.
  • The hardest technical question deferred until it's expensive.
  • Findings handed to a delivery team that wasn't in the room.

How we do it

  • A week embedded with the people who actually have the problem.
  • A prototype of the idea, so the recommendation is something you can see.
  • The riskiest assumption mapped and pressure-tested, first.
  • Senior engineers doing the thinking, so the plan is grounded in reality.

How it runs

One week. Four moves.

Timeboxed on purpose. The week is the de-risk. It caps what the wrong answer can cost you.

  1. Day 1

    01Embed

    We sit in your standups, your Slack, your day-to-day. We talk to the people who actually have the problem, not just the person who signed the brief.

  2. Days 1-2

    02Map the landscape

    We separate the constraints that are real from the ones that are just habit, then pull the moving parts into one clear picture of what you're really deciding.

  3. Days 2-4

    03Prototype the answer

    We turn the emerging recommendation into something you can see and click, so people react to a real thing instead of a slide. A visualisation to align on, not a change to your production systems.

  4. Day 5

    04Recommend

    You get a build, buy or phase call, an honest cost-and-risk picture, and a plan for execs or investors. Sometimes the call is don't build it. That's a win.

What you leave with

A decision, not a document.

Everything we produce is yours, and it's concrete enough to act on Monday. No 60-page report to decode.

  1. 01

    A problem map

    What success actually looks like, which constraints are real, and exactly where the risk sits.

  2. 02

    A prototype you can see and click

    Something tangible that makes the recommendation real, so the room aligns on the actual idea instead of a slide. A visualisation, not a change to production.

  3. 03

    A build, buy or phase recommendation

    An honest call with the tradeoffs shown, including when the answer is buy it off the shelf, or don't build it at all.

  4. 04

    A delivery plan and cost envelope

    Scope, sequence, timeline and a cost range you can take to your board or your investors without flinching.

Why it lands

A prototype beats a deck.

Most discovery ends in a slide deck the room argues over. Ours ends in something you can see and click. We turn the recommendation into a prototype, so stakeholders react to a tangible version of the idea instead of a bullet point. It exists to align the room and pressure-test the direction. It is a visualisation, not a change to your production systems. The decision gets made looking at something real.

Prototype

Something to react to. A visualisation, not production code.

Is it for you?

We'd rather you do this for the right reason.

Discovery is for you if

  • You're staring at a big initiative and about to commit serious budget to it.
  • You've been burned by an agency that built exactly what was specced, and exactly the wrong thing.
  • You need a decision you can defend to a board or an investor, not a gut call.
  • There's a genuinely risky assumption (a hard integration, an unproven model, a scaling question) that could sink the whole thing.

Skip it if

  • You already know what to build and the risk is low. Just start, we'll tell you that for free.
  • The work is small enough that a week of discovery costs more than the mistake would.
  • You want validation for a decision you've already made. That's not what this is.

Questions

The skeptical ones.

Is this just a paid sales pitch?
No. You own everything we produce, and the honest recommendation is sometimes "don't build this" or "buy it off the shelf." We'd rather tell you that in week one than bill you for six months.
Why not just start building?
Sometimes that's the right call, and we'll say so. But a week spent killing the wrong idea, or de-risking the right one, is the cheapest week you'll spend on the whole project.
What happens after the week?
It stands alone: the decision, the prototype and the plan are yours to take anywhere. Or it rolls straight into Build, with the same engineers who already understand your problem. No re-onboarding, no second discovery.
Who actually does the work?
Senior forward-deployed engineers, the same people who'd go on to build it. Not a research team that hands findings to a delivery team. The person weighing the risk is the one who's been hands-on with your problem, not a layer removed.

Let's talk

Tell us what you're building.

One conversation. An honest take. No commitment until it makes sense.

Start the conversation

Based in Belfast, working with teams globally