01 · Operational discovery
Before we build anything, we make the operation readable.
Most software projects fail long before the first line of code. They fail because nobody wrote down how the business actually works — only how one person believes it works. We start by fixing that.
How it works
We talk to the people doing the work, not only the person who owns the show. The estimator carrying the pricing logic in his head. The office manager who knows which supplier to call. The person who spends every Friday reconciling two systems that disagree.
Out of those conversations comes a model of the real operation: the customers, jobs, resources, decisions and transactions at its heart, the dependencies between them, and the exceptions that never made it into any process manual.
Sometimes that model says build. Sometimes it says connect what you already have. Occasionally it says the problem is not software at all. We will tell you which, early, rather than late.
What you get
Concrete things, not a retainer.
Stakeholder interviews
With the people doing the work, not a summary of them.
The real operation, mapped
How value moves from request to delivery, including the exceptions.
System adjacency
Which of your tools genuinely exchange data, and which gaps a person is closing by hand.
A shared operational language
One agreed definition of a customer, a job, an invoice.
A prioritised plan
What to build, what to connect, what to leave alone — in what order.
An honest recommendation
Including whether we are the right partner for it.
How we run it
- 01ReadInterviews with the people doing the work, across every function the operation touches.
- 02ModelA shared language for the entities and decisions at the heart of the business.
- 03ReportThe operation as it stands, the gaps closed by people, and what to do in what order.
This is for you if
- Important knowledge lives in a handful of people
- Too many decisions come back to the founder
- Nobody can give the same answer about how a process works
- A previous software project stalled or was abandoned
- You are being sold AI and cannot tell whether it would help
What this is not
- A workshop that ends in a slide deck nobody opens
- A six-month audit before anything gets built
- A recommendation that always concludes you should hire us
Where we have done this
4 shipped systems that used it.
Questions we get
- How long does it take?
- Usually two to four weeks, depending on how many functions the operation touches and how available the people are. It is deliberately short — discovery that runs for months is a way of avoiding the build.
- Do we have to build with you afterwards?
- No. The model and the roadmap are yours. Some clients take them to an internal team. We would rather you have an accurate plan than an engagement.
- What if we already know what we want built?
- Then this is short. But it is worth checking that everyone means the same thing by it — the most expensive projects we have seen are the ones where the founder and the team were describing different systems in the same words.
We once built exactly what a founder asked for. When we showed it to his team, they spoke a different language than he did — the business was not legible even to itself. The project paused. Now we insist the key stakeholders are in the room from day one.
Tell us what is slowing the business down. We will tell you whether this is the right place to start.
Start a Conversation