The counter-case

A language model is a probabilistic component. Some processes should not contain one.

We build AI systems for a living, which makes this the page worth reading first. There are whole classes of problem where introducing a model makes an operation slower, dearer and harder to defend than the spreadsheet it replaced. These are the shapes we look for, what we recommend instead, and the questions that settle it before any money is committed.

Tell us what you are trying to do The whole stack

The framing

Probability is a feature. It is not always an upgrade.

What a language model is, stated plainly enough to see where it does not belong.

A language model does not compute an answer. It produces a likely continuation — the next token, then the next, weighted by everything it has absorbed and by the words already on the page. Ask it the same question twice and you may get two different answers. Ask it something slightly outside what it has seen and it will still answer, in exactly the same confident register, with nothing in the output to mark the difference. That behaviour is precisely what makes it valuable on input that has no fixed shape: an email that could be phrased fifty ways, a delivery note scanned at an angle, a request that arrives as a sentence rather than as fields in a form. It is also what makes it the wrong component for a great deal of ordinary business work.

Most of what a company runs on is already deterministic — meaning that for a given set of inputs it produces one output, the same one, every time it is run, including the run somebody repeats in two years to answer an auditor. A VAT calculation is deterministic. So is a payroll deduction, a discount band, a stock reservation, a postcode lookup and a barcode scan. Each of those is a function, and a function is the cheapest, fastest and most trustworthy thing in computing: it costs a fraction of a penny, returns in a millisecond, and can be tested exhaustively. Putting a probabilistic component in the middle of a process that was previously deterministic is not modernisation. It converts something you could prove into something you have to monitor, evaluate and defend.

The costs of that conversion are real and they recur. You take on a per-call charge that scales with usage, a latency floor measured in seconds rather than milliseconds, a dependency on a supplier's model version that can shift under you, and a permanent evaluation burden — the held-aside set of judged cases you must maintain to know whether the system is still working, because unlike a broken function a degraded model does not throw an error. It produces a wrong answer that reads exactly like a right one. Those costs are worth paying when the input is genuinely unstructured and the alternative is a person reading every item by hand. They are not worth paying to re-implement a rule that already exists in a spreadsheet.

So the disclosure is worth making plainly. A share of the enquiries that reach us describe problems better answered by two hundred lines of ordinary code, a required field on a form, an integration between two systems that never spoke, or a fortnight spent fixing how the data is captured before anyone mentions models at all. We would rather say that on the first call than at the pilot review. It costs us a project and it costs you nothing, which is the correct way round.

Adding probability to a deterministic process converts something you could prove into something you have to defend.

Five shapes

Where something else wins, and what wins instead.

These are shapes rather than industries — the same shape turns up in a warehouse, a payroll run and a lettings office. One note on how to read them. Everywhere else on this site the third line under each item says what breaks if you do not have the thing being described. Here it is inverted: it says what breaks if you use a model on this shape anyway.

The rule is already written

Deterministic logic, decision tables, rules engines, validation at the point of entry

If a policy can be stated as a table — orders above this value from customers in that band get this rate, unless the account is on stop — then it is already a program. Somebody has done the difficult part, which was deciding the rule. What remains is typing it into a decision table or a page of code, where a non-programmer can read it, where it can be unit tested, where every change is in version control with a name and a date against it, and where an auditor asking why one order was priced that way gets the rule itself as the answer. A model asked to apply the same rule will get it right most of the time. Most of the time is a weaker guarantee than the one you already had, at a higher cost per invocation and with a slower answer.

You have replaced a rule anyone can read with a system nobody can read, and taken on an evaluation programme to establish something the decision table gave you for nothing — that the rule is applied correctly on every single case rather than on the ones you sampled. When the policy changes, you now retest a model instead of editing one line and shipping it before lunch.

The answer must be identical every time

Determinism, exact decimal arithmetic, reproducibility, calculations subject to audit

Payroll deductions, VAT, interest accrual, commission splits, duty and unit conversions in a regulated environment. Two properties matter in this work and a language model has neither of them. The first is reproducibility: the same input must give the same output on every run, including the run someone repeats eighteen months later because an employee has queried a payslip. The second is exactness: money is decimal arithmetic with defined rounding, and a system predicting the next token is not performing decimal arithmetic even when it prints a number that looks plausible. A model can be genuinely useful next to this work — reading the timesheet, pulling figures off a supplier invoice, explaining to an employee in plain English why their deduction changed this month — but the calculation itself belongs in code, with the rates held as data so they can be changed without a release.

You turn a number that has to be defensible into a number that has to be checked. An error of a penny in a rounding rule does not announce itself; it accumulates quietly across a few thousand payslips until somebody notices, and by then you are reconstructing months of runs that cannot be reproduced. The model generated it is not an answer that satisfies an auditor, a regulator or the person holding the payslip.

The data isn't there yet

Data capture, provenance, ground truth, the judged examples nothing can be evaluated without

This is the most common one we see, and the least welcome. The proposal is a model that predicts something valuable — which machine is about to fail, which invoice will be paid late, which shift will be short-staffed — and the records that would ground or train it either do not exist, exist in three systems that disagree about the same event, or exist as free text in a comments box that four people fill in four different ways. Ground truth is the term for what you would compare the model's answers against: real cases, judged by somebody qualified, held aside and used for nothing else. Without it there is no way to tell a good system from a confident one. A fortnight spent making the warehouse scan the barcode at the moment the pallet actually moves, or adding one required reason code to a form, buys more than any model built on the records you have now — and it is the precondition for the model you build next year.

You get a system that is confidently wrong in precisely the pattern of your existing data problems, and no means of proving it, because the ground truth you would measure against is the thing you did not have. It will look fine in the demonstration, where the records were chosen by hand, and it will disappoint on the first week of real traffic in a way nobody can diagnose.

The volume doesn't justify it

Cost per call, build cost amortised across usage, the person-minutes actually displaced

Do the arithmetic before the architecture. Count how many times the task happens in a month, multiply by the minutes a person spends on each one, and set that against the build cost, the per-call cost of the model, and the standing cost of somebody owning the thing — because an AI system in production has an owner, a monitoring dashboard and a bill, permanently. A task that happens forty times a month and takes four minutes is under three hours of work a month. There is almost nothing worth building there, and a checklist or a better form will beat anything we could ship. The same task at four thousand times a month is an entirely different proposition. Volume is not the only multiplier that counts: a rare task can be worth automating when being slow at it is expensive, as with a safety recall or a bid deadline. But that is a case you should be able to state out loud in one sentence before anyone starts.

You spend more building and running the system than the work it replaced ever cost, and the loss is a quiet one. It does not surface as a failure anybody reports. It surfaces as a line in a cloud bill and as an engineer's attention held permanently by a system that saves three hours a month.

The process itself is the problem

Process design before automation; the failure mode where speed multiplies a defect

Some processes are slow because they are broken. An approval step exists because two departments do not trust one another. A form has twenty fields of which four are ever used, and a person downstream spends their morning working out which four mattered this time. A reconciliation runs every Friday only because two systems were never integrated and both hold a version of the same order. Automating any of these preserves them exactly as they are. It also removes the friction that was, quietly, the only reason anyone still noticed how bad they were — a step that hurts gets fixed eventually, a step that has been made effortless never does. The right move is a fortnight of process work: delete the step, integrate the systems, cut the form to four fields. What remains afterwards is often small enough that the automation question answers itself.

You make a bad process fast, which means it produces its bad outputs faster than anybody can review them, and errors that used to be caught by the slowness now travel all the way to a customer. The automation also encodes the broken process in software, so fixing the process properly later stops being a conversation and becomes a rebuild.

The two lists

What we would build with you. And what we would talk you out of.

Both lists are drawn from the same kind of conversation. The difference is almost never the industry — it is whether the input has a fixed shape and whether the answer has to be the same one every time.

Worth building with AI

Input arrives as language or as an image: emails to a shared mailbox, scanned delivery notes, handwritten job sheets, supplier invoices in two hundred different layouts
A real rule governs the work but nobody has ever written it down, and the only record of it is several thousand past decisions people made correctly
Triage, routing or extraction at a volume no rota can absorb, with a confidence floor that sends the uncertain cases to a person rather than guessing
The answer exists somewhere in ten thousand documents, and the current method of finding it is asking the colleague who has been there nine years
A near-miss is cheap: a suggested category, a drafted reply, a prioritised queue, where a person approves the output before anything is committed
The volume is high enough that a single percentage point of accuracy is measured in days of recovered work rather than minutes

We would tell you not to

A payroll deduction, a VAT figure or anything else where the arithmetic must be exact and reproducible on demand two years later
A discount, eligibility or routing rule that already exists as a table in somebody's spreadsheet and has never been in dispute
A barcode, a serial number, a postcode, a stock level — anything with a definitive answer available from a database or an API
A free-text field being interpreted by a model when a dropdown or a required reason code at the point of entry would remove the ambiguity at source
A prediction whose ground truth does not exist yet, because nothing in the current records says reliably what actually happened
A task that runs thirty times a month and takes two minutes, where the annual saving would not cover the first month of running the system

The diagnosis

Four questions, and what a good answer looks like on paper.

Run these before committing a budget. Each one produces an artefact you can hold, and each artefact is useful whichever way the decision goes — nothing here is wasted if the answer turns out to be no.

Can you write the rule down?

Either a decision table complete enough to implement, or a written record of exactly where the experts disagreed and why. Both are worth the afternoon they cost.

Sit two people who do the work in a room and ask them to state the rule they apply, including the exceptions. If it comes out as a table, you have found a decision table and you should build that instead, for a fraction of the cost and with none of the evaluation burden. If three attempts produce three different tables that all describe real practice, you have found the genuine case for a model — the rule exists but lives in judgement rather than in policy. You have also found your labelling problem, because those disagreements are the thing a model would have to learn.

What does a correct answer look like, and who decides?

A named individual, and between fifty and two hundred real cases they have judged, stored separately and never used to build or tune anything.

Correctness has to have a named owner — a person with the standing to say that this classification was right and that one was wrong, and whose judgement the business will accept when a disagreement reaches them. Then that person needs to judge a real sample: not invented cases, not the tidy ones, a fair draw from actual traffic including the awkward tail. That sample is held aside and used for nothing except measurement. Without it you can observe that a system changed but never that it improved, and every subsequent argument about quality becomes a matter of impressions.

Where does the data actually come from, and is it captured yet?

A one-page table of fields, each with its source system, its point of capture and its rate of being missing or wrong. Anything above roughly a fifth missing is a data problem to fix first.

List the fields the system would need. For each one, name the system of record it comes from, the person or the device that puts it there, and how often it is missing, late or contradicted by another system. This exercise is dull and it is the one that most often changes the plan, because it exposes the fields everyone assumed existed. Any field whose real answer is a free-text comments box is a data capture task before it is an AI task, and it is usually a cheaper one.

What does it cost to run, and what does it displace?

Two figures on one line, with the assumptions written beside them so anybody can argue with the arithmetic rather than with the conclusion.

Two numbers, honestly assembled. The first is the work displaced: occurrences per month multiplied by minutes per occurrence, valued at what that time is genuinely worth. The second is total cost of ownership for a year — build, per-call charges at expected volume, the infrastructure, and the share of an engineer's time that maintaining and re-evaluating it will take, which is never zero. If the two numbers are within a factor of two of each other, the honest answer is not yet, and the useful next step is usually to raise the volume or narrow the scope rather than to build.

Asked often

The questions this page tends to provoke.

Isn't publishing this against your own interest?: In the short run, yes — it loses us work we could have sold. In the longer run it is the only version that holds up. The engagements that go badly are almost always the ones that should not have started, and they cost far more than the fee: months of an internal team's time, credibility inside the business, and an appetite for the next project that never comes back. There is also a plainer point. A supplier who has never once told you not to build something has given you no information at all when they tell you to build something.
What do you do when a client insists?: We say what is on this page, once, in writing, with the cheaper alternative costed next to it so the comparison is concrete rather than rhetorical. If the decision still stands, we will usually build it — it is your business and your call — on two conditions. There is a judged evaluation set agreed before any code is written, and there is a threshold written down in advance at which all parties accept it did not work. Occasionally we are the ones who turn out to be wrong, and the evaluation set is how anybody finds that out in either direction.
Can we start smaller instead of not at all?: Usually, and it is the right instinct. Smaller rarely means a smaller model; it means a narrower slice of the same problem. One document type rather than nine. One site, one queue, one product line. A person approving every output before it commits, so the worst case is wasted keystrokes rather than a wrong invoice. What smaller must not mean is skipping the judged sample or the cost arithmetic, because those are what tell you whether the slice worked — and a pilot with no measurement attached will be argued about for a year and settle nothing.
What if a competitor ships it anyway?: Then watch what happens to it, because a system of this kind is a standing commitment rather than a launch. The interesting question is not whether they shipped but whether it is still running in eighteen months, what it costs them per month, who owns it after the person who built it moves on, and whether anybody has measured its accuracy since the day it went live. Some of what is being shipped in this field at the moment is a deterministic process with a model dropped into the middle of it, and that is a decision that bills monthly. Where a competitor has genuinely automated unstructured work at volume, that is a real advantage and we will say so.
Does any of this apply to automation that isn't AI?: The volume test and the broken-process test apply to every kind of automation, including plain workflow automation and robotic process automation, where a script drives existing software the way a person would. The determinism and ground-truth tests do not: conventional automation is deterministic by construction, which is exactly why it remains the correct answer for a large share of the work people now describe as AI projects. If your problem passes the volume test and the input already has a fixed shape, the cheaper technology is the better one.

In practice

The no is not modesty. It is what makes the yes mean anything.

Every recommendation we make is worth exactly as much as our willingness to make the opposite one. We are an engineering firm rather than a licence reseller, so a project that should not have been built is not a smaller sale to us — it is a bad outcome we then have to stand next to. That is why this page exists in the same detail as the pages arguing for the work, and why the diagnosis above is written so you can run it without us.

Where a problem does pass those four questions, it usually passes them clearly, and the case is then easy to make in a sentence: this input has no fixed shape, this volume is real, this is what a correct answer looks like and here is who says so. Where it does not, the alternative is normally cheaper, faster and available sooner — a rule written down, a field added to a form, two systems finally introduced to each other.

If you would like a straight answer about which of those you are holding, describe the workflow and we will tell you. If the answer is that you do not need us, that is the answer you will get.

Describe the workflow How we run an engagement

Fine-tuning, RAG or prompting

Three ways to make a model know your business. Which one you need, and what each costs.

Read

Where the money actually goes

What an AI system actually costs to run, and which parts of the bill get larger after it launches.

Read

How you know it works

How anyone can tell whether an AI system is actually working, rather than merely looking like it did in the demonstration.

Read

Loading…

FAQs

Frequently Asked Questions

Industrial AI, robotics conversion and adoption, Industry 4.0 automation and test automation, and the software those systems run inside: enterprise systems (ERP, HRMS, CRM, inventory and production management), web applications, AI agents and automation, and native mobile apps for iOS and Android.

A focused first release typically ships in 8–12 weeks. Multi-module enterprise platforms run 4–9 months, delivered module by module so you are using working software long before the final release rather than waiting on a single big-bang launch.

Both. A well-defined scope gets a fixed price against a signed specification. Longer or evolving builds run as a dedicated team on a monthly retainer. Either way you get a written estimate with every assumption listed before a contract exists, so you can see exactly what moves the number.

Discovery and scoping, then UI/UX design, then two-week build sprints that each end in a working demo. You get a staging environment from the first week, and QA, security review and deployment run inside the sprint instead of being bolted on at the end.

You do, in full, on final payment. Source code, design files, infrastructure and documentation are handed over in your own repositories and cloud accounts. We keep no licence over your product and there is no lock-in to our hosting.

Yes. We connect to MES and the equipment already on the line, accounting, HR and CRM platforms, payment gateways, WhatsApp Business, and legacy in-house databases. Where no API exists we build a sync layer and migrate historical records with reconciliation reports your finance team can check line by line.

Every project closes with a handover: documentation, team training, and a warranty period covering defects at no cost. After that you can run support in-house or keep us on a monthly plan covering monitoring, security patches, and an agreed block of enhancement hours.

We sign your NDA before the first technical conversation. Builds ship with role-based access, encryption in transit and at rest, and audit logging as standard. Production data stays inside your infrastructure and access is limited to the engineers assigned to your project.

Start a project

Didn’t find what you were looking for?

Tell us what you are building. You get scope, a timeline and a realistic cost — not a brochure.

Tools

The stack we build on

We design, build, and evaluate with a modern AI stack—LLMs, vector search, orchestration, and observability—so your features are fast, reliable, and secure.

OpenAI

Anthropic

Gemini

xAI

Hugging Face

Kimi

LangChain

NVIDIA

Pinecone

Databricks