Does Your Problem Even Need an LLM?

Not every problem should be handed to a language model, and the ones that should not are surprisingly easy to spot before you build, and surprisingly expensive to discover after. This is the cheapest gate in the whole lifecycle: a few minutes of honest thinking that can save you a quarter of building the wrong thing. This post is that gate, and what to do when your problem fails it.

This is part four of the From Demo to Product series. It runs before defensibility and before evals, because if the fit is wrong none of the rest matters.

What LLMs are actually good at#

LLMs fit language and knowledge work that tolerates some imperfection, or is cheap to verify, and is expensive to do by hand. That is the whole sentence, and every word in it is load-bearing.

Reading, writing, summarising, extracting, classifying, transforming, routing. Fuzzy or varied input, where the output is checkable. A task where a costly human already does the work, so there is an ROI baseline to beat. When those hold, an LLM can compress hours into minutes, and "good enough, fast, cheap" beats "perfect, slow, expensive."

The mismatches are just as clear. Exact computation and deterministic control logic are not LLM jobs. Neither is anything that needs hard real-time determinism, exact recall of facts the model does not have and cannot reliably retrieve, or a decision whose wrong answer is catastrophic and uncontainable.

Signal	Good fit	Poor fit
Task shape	reading, writing, summarising, extracting, classifying, routing	exact computation, deterministic control logic
Error tolerance	occasional error tolerable, or cheap to catch	zero tolerance with no verification layer
Latency and consistency	good-enough-fast-cheap beats perfect-slow-expensive	hard real-time determinism required
Knowledge need	fuzzy input, checkable output	exact recall the model lacks and cannot retrieve
Blast radius of a wrong answer	contained, reversible, cheap to catch	catastrophic and uncontainable
Economics	a costly human already does this	no human workflow displaced, no ROI baseline

The poor-fit column is not "never"#

The right column does not mean "an LLM can never touch this." It means "add a verification or human layer, or do not let the model own the decision."

An LLM drafting a contract clause for a lawyer to review is a good use of a model that has bad recall, because the lawyer is the catch. The same model directly executing an irreversible wire transfer with no check is not, because there is no catch. Same underlying weakness, models are fluent, not infallible, and a completely different consequence, because one has a catch mechanism and the other does not.

So the design question is never "can the model do this." It is "what catches it when it is wrong, and how expensive is that catch." If the catch is cheap and reliable, most fuzzy tasks are fair game. If the catch is expensive, slow, or absent, either build one or keep the model out of the decision.

Where good ideas actually come from#

The fit test tells you whether an idea qualifies. It does not generate ideas. The best wedges tend to come from a few places:

Expensive human workflows in a domain you already know, where a specific, painful, language-heavy task costs someone real money to do by hand. Boring back-office and vertical work over another general chatbot, because vertical plus a system-of-record ambition is where enduring businesses form. Your own friction, the tools you wish existed while building. And anything adjacent to a data asset a general model cannot access, which is a moat-shaped starting point rather than an afterthought.

Then filter every candidate through one set of questions: is it a real, painful, frequent job? Can I be 10x on time or cost? Where is the defensibility? What breaks if the model is wrong, and can I contain it? And the uncomfortable one: would "just build it internally" be the customer's obvious move, and if so, why would they pick me?

The output: the opportunity thesis#

The artifact this stage produces is a single paragraph. If you cannot write it crisply, you are not ready to plan the build.

For [user], [painful, frequent job] currently costs [time, money, errors]. We can be [10x claim] because [why now]. The wedge is [narrow first workflow], and the moat is [data, workflow, system of record, or compounding UX], so a 2x-better model makes us better, not obsolete.

That paragraph does double duty: it forces the fit question (is there a painful, frequent, language-heavy job with a checkable output) and the defensibility question (the subject of the previous post) into the same sentence. If either half is vague, the idea is not ready, and it is far cheaper to learn that now than after a quarter of building.

The traps#

A few ways this gate gets fumbled, all of which I have seen:

Getting seduced by capability instead of the workflow. "10x on what the model can technically do" is not the same as "10x on the actual expensive job someone was paying for." Verify that someone was really paying, in time or money, for the narrow thing you are displacing.

Assuming the verification layer exists because it could. A task can pass the fit test on paper and fail in production when the "cheap check" turns out to be nobody's job.

Treating a failed spike as a prompt problem. When you time-box a quick feasibility check and the model is not close, the temptation is to blame the prompt and iterate for another week. Sometimes the honest answer is that this was not an LLM problem, and a failed check in week one is cheap information.

Where this goes next#

Say your problem passes the fit gate, you have a moat, and your evals are honest. There is still one operating reality that will bite you regardless: the model underneath is a third party that changes its pricing, its behaviour, and even its tokenizer while your product is live. The next and final post in the series is treating the model as a flaky, expensive dependency. If you want the strategy question this post keeps pointing at, it is why AI is not a moat.