In one of the systems we built at Codino, the entry point looks trivial. We receive a photo of a receipt and want to answer a simple question: what did the customer actually buy?

The first instinct these days is obvious enough: feed the photo to an LLM and collect the structured data. But once you start looking at the whole process, it quickly becomes clear that "analyzing a receipt" isn't one problem.

You have to read the text, understand the document's structure, and pull out the date, the amounts, the store, and the individual line items. Then the abbreviated store name has to be matched to a specific retail chain, and the product as written on the receipt (often nothing like the name it's sold under) to the actual product. After that comes enriching the data with additional attributes, and only on top of all that can you build a picture of the customer's buying behavior.

From the business's perspective, it's one process. From the solution side, it's several distinct problems, and they don't have to share the same technological answer.

Which is why, before I ask "which LLM should we use?", I prefer to ask a different question:

What exactly does an LLM give us that a simpler approach doesn't, and what will the company be left with after the rollout?

That distinction matters even when the automation itself already has a solid business case. Even a profitable project can be ruined by pairing a simple problem with a solution that's expensive to maintain or needlessly hard to change.

One process can contain several completely different problems

Receipts share some common traits, but they can also differ wildly between stores and cases. Product names, discounts, taxes and seller details are written differently everywhere. And then there's photo quality, which isn't consistent either.

On this project we compared several approaches. One was as close to end-to-end as possible: the model gets the image and tries to return the required information in one shot. Another used an LLM only where the variability and ambiguity are greatest. We also tested solutions built on classic algorithms, heuristics and rules.

And this is where you hit the thing that matters more in practice than any specific model choice: no single solution wins every time.

If you're handling a well-known range of documents and care about very low latency and a low unit cost, a more deterministic approach can make sense. If, on the other hand, the system has to adapt quickly to new formats, unusual ways of writing things, and a large number of variants, the model's flexibility can be worth far more.

Then there's the required quality bar and the kind of errors you're willing to accept. Misreading a secondary field is a different problem from getting the store or the purchase amount wrong.

So I break the process into parts to find the places where the difficulty actually lives. Not to immediately assign each part its own technology.

The simplest component doesn't always produce the simplest system

This is where the second trap lies.

You can find a simple mechanism for every part: a parser, a handful of rules, a separate classifier, extra logic for the exceptions, and integrations between all of them. Each piece looks reasonable on its own. But after a while, changing one document variant can require fixes in several places, and bugs start appearing not inside any single algorithm, but at the seam between two components that each work correctly.

In other words, you can make a series of individually simple technical decisions and still end up with a system that's hard to maintain.

So I don't just look at whether a single component is cheap or easy to build. I also want to know how much of our own logic we'll have to maintain later, how many dependencies we're creating, how hard the system will be to change in six months, whether we'll be able to trace the cause of an error, and what the whole thing costs to run every day.

In practice, it comes down to one simple question:

What will the company be left with after the rollout?

If the "simple" option means dozens of rules, plenty of exceptions, and several places that need touching every time a new case shows up, its simplicity may be an illusion.

An LLM can remove the rules. In return, you have to control the model

The same logic works in the other direction.

An LLM is not a more complicated solution by definition. If the core problem is a large number of variants in language, documents, or ways of describing the same thing, a model can cut down the need to keep hand-writing new rules and exceptions.

Receipt analysis shows this well. Reading a specific, unambiguous value can be a simple task. Matching an abbreviated product name to the actual product is a different problem entirely, especially when every store uses its own shorthand and conventions.

That doesn't automatically mean "this needs an LLM". It does mean this is exactly the kind of spot where comparing approaches is worth it, because the cost of hand-describing variant after variant can eventually exceed the cost of using a model.

Except that work doesn't disappear. It just moves.

Instead of maintaining a growing list of rules, you start controlling the quality of the model's answers. You have to check how it behaves on new data, whether a change of model or instructions degrades the results, and what to do with the cases where the answer is uncertain.

So I don't ask which technology is "inherently simpler". What interests me more is what kind of work and risk we're signing up for later.

In one option, that's maintaining rules and exceptions. In another, it's testing and controlling a more flexible model. In yet another, the best answer is a hybrid, with the LLM working only where its flexibility genuinely adds something.

That's why on projects like this we don't start by picking a model. First we find where the difficulty lives, then we compare different ways of solving it on real data. The technology follows from the requirements of the process; it's not the starting point.

Three questions I'd ask before choosing the technology

A CEO doesn't need to know whether a given piece of the process is best solved by a parser, a classic model, or an LLM. They should, however, expect the team to clearly justify why the proposed solution makes sense.

The first question:

Where in this process does the difficulty actually live?

Is the problem executing a known rule, moving data between systems, or interpreting cases we can't sensibly describe up front?

The second:

What does an LLM give us beyond the simpler approach, or what does it let us remove?

The answer doesn't have to be higher accuracy alone. The value can also be fewer hand-maintained rules, faster support for new variants, fewer separate models, or a shorter build.

And the third:

What will the company be left with after the rollout: what will it have to maintain, change, control, and keep paying for?

That last question protects you from both extremes. On one side, using an LLM just because it's there. On the other, piling up rules and specialized mechanisms just because each one looks simpler on its own.

That's how I actually approach technology choices in automation. I'm not looking for the simplest technology. I'm looking for the simplest solution as a whole that meets the business requirements.

A good decision isn't about using as little AI as possible, or as much AI as possible. It's about a solution that doesn't just work in a demo, but one you can sensibly maintain, evolve and use every single day.

And once you know what kind of solution makes sense, the next question comes up: are the company's data and systems in good enough shape to actually build it.