Data & Applied AI

A demo is not evidence that a feature works

Getting operational data somewhere it can be queried, then building reporting or model-driven features on top of it — with accuracy measured rather than assumed.

Why this comes up

Two requests arrive constantly, and they are the same request. The first is reporting: the numbers the business runs on are assembled by hand each month, from three systems, into a spreadsheet only one person fully understands. The second is AI: a competitor has shipped something with a language model in it, and the board would like to know the plan.

Both fail for the same reason. Neither reporting nor a model-backed feature can be better than the data underneath, and in most organisations that data lives in operational databases shaped for transactions, in a SaaS tool with an export button, and in the spreadsheet. Until that is consolidated somewhere queryable, a dashboard is a nicer-looking version of the same manual work.

The second failure is specific to AI, and it is measurement. A language model feature demos beautifully and degrades quietly, and without an evaluation set you cannot tell the difference between a prompt change that helped and one that only felt better. So we build the evaluation set first — real examples, expected outputs, a score — and treat a number that does not move as a reason to stop.

What you get

Deliverables, not adjectives

Pipelines and a queryable model

Ingestion from operational databases, third-party APIs and the files people actually maintain, landed in a warehouse with a schema modelled for questions rather than for transactions. Incremental, monitored, and re-runnable after the inevitable bad day upstream.

Reporting that retires manual steps

The measure is not that a dashboard exists but that a recurring manual process stops. We start from the spreadsheet someone maintains, reproduce its numbers exactly, prove agreement, and then remove the step — in that order, because a dashboard nobody trusts is ignored.

LLM features with an evaluation harness

Retrieval-augmented answering, extraction, classification or summarisation over your own content, shipped with a scored evaluation set built from real examples. Plus the boundaries: what the feature declines to answer, how it cites sources, what a human reviews before anything is acted on.

Integration and workflow automation

System-to-system connections that handle the unhappy path — retries, idempotency, partial failure, replay — because the failure mode of a naive integration is silent divergence between two systems that both look fine.

Scope at a glance

Ingestion pipelines, warehousing and schema modelling
Reporting layers that retire manual spreadsheet steps
Retrieval-augmented LLM features with evaluation sets
System-to-system integration and workflow automation

What we reach for

Defaults rather than rules. Each one gets argued against on a project where it does not fit — the reasoning matters more than the tool.

Pipelines: Python with an orchestrator, kept simple enough that one engineer can hold it in mind.
Storage: PostgreSQL where the volume allows, a columnar warehouse when it genuinely does not.
Models: Claude and other hosted models behind an internal interface, so the provider stays a commercial decision.
Evaluation: Versioned test sets with scored runs, so prompt and model changes are compared, not felt.

How it runs

Durations are ranges because a single confident number this early is a guess in a suit.

Engagement shape

Fixed-scope pilot on one dataset or one feature, extended once it is measurably working.

Typical duration

Six to fourteen weeks, depending on how many source systems are involved.

Starts with

A data inventory and one clearly stated question the business wants answered reliably.

When this is the wrong thing to buy

We would rather lose the enquiry here than three months in. If you recognise your situation below, say so on the first call and we will tell you what we would do instead.

Adding AI to a product without a task it performs. We will ask what job it does, and if there is no answer we would rather not build it.
Fully autonomous decisions in a domain where a wrong answer has legal or financial consequences. We will build the assisted version and argue for the human review step.
Training a foundation model from scratch. For nearly every business problem, retrieval against a hosted model is better and vastly cheaper.

Questions we get asked

Is our data good enough for AI?

Usually it is good enough for a narrow, well-chosen task and not good enough for the broad one that was originally imagined. The data inventory at the start is what tells you which — and it is cheaper to learn that in week one than after a quarter of building.

How do you stop a model inventing answers?

Constrain it to retrieved content, cite the source alongside every answer, and make declining to answer an acceptable outcome. Then measure it: the evaluation set includes questions the system should refuse. A feature that is confidently wrong is worse than one that says it does not know.

Does our data go to a model provider?

Only if you decide it should, and we will make that a deliberate choice with the retention terms in front of you rather than a default buried in a library. Where the data cannot leave your environment, we will say up front what that rules out and what remains possible.

Can you work with our existing warehouse?

Yes. If there is already something queryable, that is a head start and we would rather build on it than replace it. Replacement gets proposed only when the existing model actively prevents the questions you need answered.

Talk to us about data & applied ai

Send the problem rather than a feature list. You will get an approach, a range and an honest view of what it takes — including whether you need this at all.

Book a 15-min strategy call