How we work with companies

What we do

The shape of an engagement

A first conversation, thirty minutes, free. Bring one specific problem rather than a strategy. The useful version of this call is about a task that takes too long today, described in enough detail that we can tell whether it is a deployment problem, an organisational one, or one that should not be solved with software.

An assessment phase, short and deliberately cheap. Enough time to look at how the work is actually done, find out what the data really contains, and establish what the realistic ceiling is. It ends with a written recommendation including a cost and a timeline, or with a recommendation not to proceed. Both are legitimate outputs and both are priced the same.

The build, against a defined problem. With a named owner on your side, an agreed route to data access, and something in front of a real user early rather than at the end. The first version will be wrong in ways nobody predicted, which is the point of putting it in front of someone while there is still time to change it.

The handover, as a deliverable. Documentation, the evaluation set, and a period where one of your people runs the system while we answer questions rather than the other way round. An engagement that ends without this produces something that decays within two quarters.

What we will not promise

We will not promise a percentage. Anyone who quotes you an efficiency figure before looking at your data is quoting you an average of other companies, and the variance between organisations on the same process is larger than the effect being claimed.

We will not promise that the project will be used. We can promise to build something that works, to put it in front of people early, and to spend real time on adoption rather than treating it as training. Whether an organisation adopts a change depends on things no vendor controls, and saying otherwise would be selling you a guarantee we cannot honour.

We will not promise that AI is the answer. In a meaningful share of the problems we are asked about, the better fix is a reporting change, a process change, or a piece of ordinary software with no model in it at all. We will say so, and it is the least commercially convenient sentence on this page.

When not to call us

If you have a strong internal team and the problem is well understood, build it yourselves. You will do it cheaper and you will own the knowledge, which matters more over three years than any speed we could add.

If the real obstacle is that two departments disagree about who owns the process, no deployment engineer will fix that, and the project will consume budget while the actual problem stays where it is. This one is worth naming explicitly because it is the most common reason a technically successful project produces nothing.

And if nobody senior actually wants the change, stop. A system that works, delivered into an organisation where the change has no sponsor, is the most expensive way to learn something that a single conversation would have revealed.

How we are paid

By the engagement, at a fixed scope agreed after the assessment phase. Not by the hour, because hourly billing rewards the wrong thing on work like this, and not on a share of savings, because that requires agreeing a measurement of savings and the agreement becomes the project.

Nothing is held back to create a dependency. The code, the prompts, the evaluation set and the documentation are yours outright and we retain no licence over any of it. If you never call us again, the work still functions, which is the only definition of a successful deployment we find defensible.