Five Times We Told a Client Not to Use AI

Real cases where a rules engine, a SQL query, or a better form beat an LLM on cost, reliability, and speed to ship — and the simple test we run before recommending AI for anything.

A good chunk of our work starts with a client who has already decided the answer is AI. They've seen the demos. They want a copilot, a chatbot, an agent. Our job in the first week is often a different one: figure out whether that's actually the right call. More often than you'd think, it isn't.

Not because the technology doesn't work. Because a rules engine, a SQL query, or a slightly better form does the same job cheaper, faster, and without a 5% chance of being confidently wrong. Here are five real cases where we talked a client out of an LLM, and the test we run before recommending AI for anything.

The loan rules were already written down

A regional fintech (hypothetical, but the shape is common) wanted an LLM to decide microloan eligibility. The problem: the eligibility policy already existed as a six-page document. Income thresholds, debt-to-income ratios, exclusion lists. That's a decision table, not a language problem. Wrapping a model around fully specified logic buys you nondeterminism and a bill, and takes away the one thing lending regulators actually require: an auditable reason for every yes and no.

• The logic was fully specified in the policy — there was no ambiguity left to interpret
• A regulator can audit an if/then table; nobody can audit why a model returned a given score
• A decision engine gives the same answer every time; an LLM does not
• Running rules costs effectively nothing per decision, versus per-token API calls at volume

'Chat with your data' when there were only twelve questions

An ecommerce team wanted natural-language querying over their Postgres analytics database. The reality, once we watched how they worked: leadership asked the same twelve or so questions every week. Text-to-SQL accuracy on real production schemas typically lands somewhere around 60-80%, and a wrong number looks exactly like a right one. Nobody double-checks a dashboard.

We built parameterized SQL views behind a plain dashboard. Sub-100ms, exact, roughly a fiftieth of the cost. LLM text-to-SQL does earn its place when the question space is genuinely open — exploratory analysis for analysts writing weird ad-hoc queries all day. That just wasn't this workload, and pretending it was would have shipped a slower, more expensive tool that occasionally lied.

Users didn't need to be understood, they needed a shorter form

A returns chatbot was on the roadmap. When we tagged a month of tickets, about 80% fell into four intents: where's my refund, wrong item, damaged item, change of mind. The bottleneck was never understanding language. It was that the existing returns form had fourteen fields and buried the order-status link.

• Four buttons plus an order-status lookup deflected more tickets than the chatbot prototype
• Zero risk of the bot inventing a refund policy that contradicts the real one
• Faster for the user: two taps instead of typing a paragraph and waiting for a reply
• Cheaper to run and far cheaper to keep correct over time

One ERP, one invoice template, no reason to guess

Invoice extraction sounds like a textbook LLM job. But in this case every invoice came out of a single ERP with a fixed layout — same fields, same positions, every time. Positional template parsing is 100% deterministic and free per document. An LLM would have added cost and the occasional field swap for no gain in accuracy.

To be fair, this flips completely when templates vary. If you're ingesting invoices from 500 different vendors, no two alike, that's exactly where LLM extraction — with schema validation and confidence thresholds — earns its cost. The deciding factor is the variety of the input, not the word 'invoice.' Match the tool to the messiness, not to the document type.

Don't send 90% of the easy cases to a model

A content-moderation pipeline needed to be both high-volume and latency-sensitive. Per-item LLM cost multiplied by millions of items a day is brutal, and the awkward truth is that most items are obvious. Paying frontier-model prices to classify clearly-fine content is waste dressed up as sophistication.

• Cheap first pass: keyword heuristics and a small classifier handle the clear-cut majority
• Route only the genuinely ambiguous minority to an LLM
• This cascade pattern cut projected cost sharply while keeping quality on the hard cases
• Measure cost per item at real volume, not per demo

The test we run before recommending AI

Before we suggest an LLM for anything, we walk through five questions. They take ten minutes and they're honest. If the answers point away from AI, we say so — even when the client came in wanting the opposite.

• Can you write the rule down? If the logic fits in a decision table or a SQL query, use that.
• Is the input bounded and structured? Deterministic code beats a model on structured input every time.
• Do you need the same answer every time, or an audit trail? Nondeterminism is a feature for brainstorming and a liability for compliance.
• What's the cost per item at your real volume, not in the demo?
• When it's wrong 5% of the time, is that a minor annoyance or a lawsuit?

AI is for ambiguity, not for logic you can specify

The pattern is consistent. LLMs shine when the input is messy language, the question space is open, and a good-enough answer beats no answer. They're the wrong tool when the rule is already written, the input is structured, or being wrong is expensive. The best systems we ship usually aren't 'an AI product' at all — they're mostly boring deterministic code, with a model handling the one part that's genuinely fuzzy. Decide where that line falls before you pick the tool, not after.