The Wrapper Problem

A large share of AI products are, technically, a form that sends your text to a major provider's API with some instructions prepended, and returns the result.

This is not automatically a criticism. It is the fact you need in order to judge the price.

Where the value can genuinely be

Workflow. The general assistant can do the task; getting it to do the task consistently takes structure. A product that encodes that structure saves real time.

Integration. Sitting inside the tool where the work already happens, with access to the relevant context, is worth more than a chat window in another tab.

Proprietary data. A legal product with access to case law, a medical one with a clinical database. The model is generic; the material is not. This is the strongest form of genuine value.

Domain evaluation. Someone has tested the outputs against expert judgement and tuned accordingly. Rare, valuable, and hard to verify from outside.

Compliance and administration. Audit logs, retention controls, access management, a contract. For organisations this is frequently the whole product.

Non-model engineering. Document parsing, chunking, retrieval, output validation. The model is a component in a system that does real work around it.

Where it is not

A prompt. If the product's contribution is instructions you could write yourself, that is a template, not a product.

A slightly different interface to a conversation you could have directly.

A list of prompts sold as a library.

Model access with a markup and no other function.

Telling them apart

Ask what happens between your input and the API call. A product doing real work can describe it. A wrapper changes the subject.

Try the task in a general assistant. Fifteen minutes. If you get comparable output with a paragraph of instruction, you know what the product is worth to you.

Look for handling of failure. Wrappers pass model failures through. Products validate output, retry, or flag uncertainty.

Look at what happens with awkward input. Systems with real engineering handle messy documents. Wrappers produce garbage.

Check whether it improves with your data. A product that learns your preferences over time is doing something a prompt does not.

The pricing sanity check

Work out roughly what the underlying API calls cost. Published rates make this straightforward for typical use.

If a product charges a monthly subscription for what amounts to a modest volume of API calls plus a form, you are paying for convenience. That may be worth it — convenience has value, and not everyone wants to manage an API key — but you should know that is the transaction.

Where the multiple is large and the interface is thin, it usually will not last. Wrapper products are competed away quickly, and when they fold your workflow goes with them.

The dependency risk

Wrappers inherit every risk of the model beneath them and add their own.

The provider changes the model and behaviour shifts without notice.

The provider raises prices and the wrapper's margin disappears.

The provider ships the feature natively and the wrapper's reason for existing does.

The wrapper folds and your history, templates and workflow go with it.

That last one is the practical argument for the export test. A product you cannot leave is a bet on a company in the least stable software market there has been in some time.

When a wrapper is the right purchase

When your time is worth more than the markup. Genuinely often true.

When it puts the capability where colleagues will use it. Adoption is worth more than sophistication.

When it handles the administrative layer you would otherwise build.

When the interface is genuinely better for a task you do constantly.

Buy it knowing what it is, on a monthly term, with an export you have tested. Under those conditions a wrapper is a reasonable purchase. Under an annual contract with no export, it is not.

Where the thin layer is worth paying for anyway

The analysis above can read as an argument against convenience products. It is not, and the cases where a thin layer is a sensible purchase are worth naming.

When someone else administers it. Managing API keys, monitoring spend and handling failures is real work. A product that does it for a monthly fee may be cheaper than your time.

When it puts the capability in front of people who would not otherwise use it. A team that will use a button in a familiar tool and will not open a chat interface is better served by the button.

When the interface is the value for a task you do constantly. A saved workflow you run twenty times a day is worth paying for even if you could reproduce it.

When compliance requires a contract. An organisation needing a data processing agreement, audit logs and support cannot use a personal account, whatever it costs.

Buy on those grounds, knowingly. The problem is not paying for convenience; it is paying for convenience while believing you bought technology, and then signing a two-year contract for it.