Do we have to use you to build what you recommend?

No, and the engagement is structured so that is a real option. Discovery is paid precisely so the plan belongs to you — architecture, scope, and estimate in enough detail to hand to another vendor or to your own team. If we are the right ones to build it we would rather win that on the plan than on your not having one.

How is this different from your AI implementation service?

This page is the decision; that one is the build. Consulting answers whether and what — whether a model belongs in the problem at all, which approach fits, what evaluation and cost would look like. AI implementation is the engineering that follows once those are settled. Small engagements are often only the first.

Can you advise on a system you did not build?

That is most of this work. We start by reading what exists — the code, the infrastructure, the incidents — because a recommendation made without that is a guess with a letterhead on it.

How long does discovery take?

It depends on how much system there is to read and how settled the constraints are. We will give you a duration after the first call rather than quoting a standard package, because a fixed-length discovery tells you more about our billing than about your problem.

Do you sign an NDA first?

Yes, before any technical discovery begins. Send yours or ask for ours.

IT & AI Consulting

Most consulting engagements end at the document. Ours end at a system, because the same team that writes the recommendation is the one that has to make it work. That changes what gets recommended: nobody on our side proposes an architecture they would not want to be on call for. We advise across the whole range we build in — line-of-business software, integrations, platform and cloud, and AI systems from a single model call through to agents that act on your tools.

What we advise on

The work is scoped to a decision you are trying to make, not to a fixed number of weeks. Most engagements start because something is about to be committed to and the cost of being wrong has become obvious.

Architecture and system design — how the thing should be shaped, and which constraints actually drive that shape.
Technical due diligence — reading a codebase, a team, and an infrastructure bill before an acquisition or an investment.
Build versus buy — whether the process is a differentiator worth building around or a cost worth paying someone else to carry.
Roadmap sequencing — what has to be true before the expensive part starts, and what can be deferred without painting you into a corner.
AI readiness — whether a problem is an AI problem at all, and if so which kind: retrieval, fine-tuning, agents, or a conventional system with better data.
Integration and platform strategy — how systems that were never designed together are going to have to work together.

Advice from people who have to build it

A consultancy that never ships is never corrected. It can recommend a service mesh for a team of four, hand over the deck, and never learn what that cost. We deliver, so our recommendations arrive attached to an estimate we would have to honour and an on-call rota we would have to sit on. That is a constraint on us, and it is the most useful thing we bring.

AI, specifically

AI advice is where the gap between confident and correct is widest right now, because the demos are easy and the production systems are not. What we look for first is whether the problem needs a model at all.

Which of the four answers fits — retrieval fixes missing knowledge, fine-tuning fixes format and tone, agents fix multi-step work, a larger model fixes reasoning depth. They are routinely applied to the wrong one.
What evaluation would even look like, because without it no later change can be judged better or worse.
What the thing costs at real volume, which is where AI economics diverge from ordinary software.
Where a human has to stay in the loop, and what happens on the day the model is confidently wrong.

How an engagement starts

Discovery is short, paid, and produces something you own. We charge for it deliberately: a free discovery produces a sales document, and a paid one produces a plan — architecture, scope, risks, and an estimate — that is yours to take to any vendor, including instead of us.

A first call to establish what decision is actually being made.
Discovery: reading the code, the infrastructure, and the constraints that are not written down.
A written recommendation with the reasoning, the options rejected, and what would change our mind.
Then your choice — we build it, your team builds it, or nobody does.

When we tell you not to build

Often enough that it is worth saying up front. Plenty of problems brought to us as engineering problems are process problems, data-quality problems, or a product that should be bought rather than built — and a well-chosen off-the-shelf tool beats a custom system that nobody has time to maintain. If that is what we find, that is what the recommendation says, even when the larger contract was the other answer.

Frequently asked questions

Do we have to use you to build what you recommend?: No, and the engagement is structured so that is a real option. Discovery is paid precisely so the plan belongs to you — architecture, scope, and estimate in enough detail to hand to another vendor or to your own team. If we are the right ones to build it we would rather win that on the plan than on your not having one.
How is this different from your AI implementation service?: This page is the decision; that one is the build. Consulting answers whether and what — whether a model belongs in the problem at all, which approach fits, what evaluation and cost would look like. AI implementation is the engineering that follows once those are settled. Small engagements are often only the first.
Can you advise on a system you did not build?: That is most of this work. We start by reading what exists — the code, the infrastructure, the incidents — because a recommendation made without that is a guess with a letterhead on it.
How long does discovery take?: It depends on how much system there is to read and how settled the constraints are. We will give you a duration after the first call rather than quoting a standard package, because a fixed-length discovery tells you more about our billing than about your problem.
Do you sign an NDA first?: Yes, before any technical discovery begins. Send yours or ask for ours.

Bring us the decision you are stuck on

Describe the system and what is about to be committed to. We will tell you whether an outside read would help, and say so if it would not.

Book a consultation