Is it a real AI product or a wrapper? Ask what is left without the model.

"It's just a wrapper" is the fastest way to dismiss an AI product and one of the least useful, because it is usually true and usually beside the point. Almost every AI product you can buy calls somebody else's model over an API. Mine mostly do.

I have also been on the other side of it: I trained a small language model from scratch for a narrow task, and fine-tuned an open-weight one for another. Having done both, I think the wrapper question is the wrong question, and there is a better one that anybody can ask without reading a line of code.

#The question that actually separates them

If you removed the model, what would be left?

That is the whole test. Not "do they use somebody else's model" — of course they do — but what did they build around it. If the answer is a text box, a system prompt and a subscription, you are paying a markup on an API you could call yourself. If the answer is a body of work that would still be valuable with a different model plugged into it, that is a product.

Most of the value in serious AI products is not in the model at all. It is in the boring surrounding work: getting your data in, deciding who is allowed to see what, handling the cases where the answer is wrong, keeping a record of what was done, and fitting into the way your organisation actually operates.

#Five tells you can check without being technical

1. Ask what happens when it is wrong

This is the single most revealing question, and the answers separate cleanly. A serious team has thought about it: the output goes to a human first, or a confidence threshold routes it, or there is a check that catches the common failure. A thin product shows you the wrong answer with the same confidence as a right one and leaves you to notice.

2. Ask for the number, not the model name

"We use the latest frontier model" is a fact about their supplier, not a claim about their quality. The question is how often the product is right, measured against what. Anybody who has genuinely done the work has a number and a description of how they got it — and will usually be quite keen to tell you, because it was expensive to produce.

3. Look for state

Does it remember anything? Does it connect to your systems, hold a record, learn your conventions, or does every session start from zero? A product that retains nothing between uses is a conversation with extra steps. This is easy to check in a trial and very hard to fake.

4. Look at the shape of the pricing

Pricing tends to reveal the cost structure underneath it. When a price tracks message volume closely, the dominant cost is usually somebody else's tokens. When it is priced per seat or per outcome, there is more often real infrastructure being paid for. Not conclusive on its own, but it points.

5. Ask what happens when the model changes

Model versions get deprecated, repriced and retired constantly. Ask what that means for you. A team with an answer — an evaluation suite they re-run, an abstraction that lets them swap, a fallback — has built something. A team that has not considered it is telling you their product is the current behaviour of one vendor's endpoint.

#When the wrapper is the right thing to buy

I want to be fair about this, because the dismissal is used lazily and it costs people good tools.

Sometimes the wrapping is the product. If a tool takes something you do fifteen times a week and turns it into one click, in the place you already work, with the right defaults for your industry — that is real value, and the fact that a general model does the reasoning underneath does not diminish it. Distribution, interface and workflow are genuine products. Plenty of software people happily pay for is a thin layer over something free.

The failure mode is not being a wrapper. It is being a wrapper priced as though it were infrastructure, sold with claims that belong to the model rather than to the product.

#What it looks like when someone has gone further

Occasionally you will meet a product that trained or tuned its own model for its specific task, and it is worth knowing what that signals, because it is rarer than the marketing suggests.

I built a 47-million-parameter model from scratch to turn plain English into terminal commands — trained on 299,000 pairs, and it lands around 87% exact match on that one narrow job. It is thousands of times smaller than a frontier model and it beats one at that specific task, because the task is narrow and the model was built for it. That is what purpose-built looks like, and it is a genuinely different proposition from a prompt.

It is also expensive in effort, which is why almost nobody does it and why claiming it is a strong signal when true. If a vendor says they trained their own model, ask what on, how big, and how they measured it. The answers arrive quickly from anyone who did, and vaguely from anyone who did not.

#Four questions to take into the meeting

1. What does your product do when the model gets it wrong?
2. How often is it right, and how did you measure that?
3. If your model provider deprecated the version you use tomorrow, what changes for me?
4. Which part of this is yours?

You do not need to evaluate the technical accuracy of the answers. Ask all four and watch which ones produce a specific, slightly weary reply — the tone of someone describing work they actually did — and which produce a pivot back to the model name. That difference is legible to anyone, and it is most of what you need.