Every week another founder shows up in your inbox with an "AI platform." A clean landing page, a free trial, a chat window. You try it. It feels familiar. That's because under the hood, it is the same model you already pay for, with a different logo on top.
This is fine when the wrapper actually solves a problem. It is a waste of money when it doesn't. The trouble is that most buyers cannot tell the difference, and the marketing pages are designed to make sure they can't.
Here is the test you can run in five minutes.
1. Ask What It Does That a Plain Chat Window Can't
Open the product's homepage. Read the headline. Read the three feature bullets. Now ask yourself: could I get the same outcome by pasting the same question into ChatGPT or Claude directly?
If the answer is yes, you are looking at a wrapper. The product is renting you access to a model you could rent yourself, with a worse interface and a higher price.
A real tool does at least one of these things:
- Connects to your actual data (your CRM, your inbox, your accounting system) and acts on it
- Runs a specific workflow on a schedule without you typing the prompt each time
- Stores context across sessions so it gets better the more you use it
- Enforces a process: structured inputs, structured outputs, audit trails
If the product just lets you type a question and get an answer, it is a chat box with a paint job.
2. Look at the Pricing Page
Wrappers tend to price by message or by seat. They have to, because their cost is the model call, and they need a margin on top of it.
Tools that do real work price by outcome or by integration. A scheduler that books your meetings might charge per booking. An onboarding system might charge per client onboarded. A research tool might charge per report generated.
When you see "unlimited messages" or "1,000 credits per month" without any sense of what those messages produce, you are looking at a metered wrapper. The vendor is gambling that you will not use it enough to expose how thin the product is.
3. Check the Integration Surface
A wrapper has one job: take your text, send it to a model, return the answer. It does not need to connect to anything else.
A real tool needs to read from the systems you already use and write to them. Look for:
- Native integrations, not "we have an API" (an API means you have to build it yourself)
- Webhooks and triggers (it can react to events, not just respond to prompts)
- Authentication into common business systems (Google, Microsoft, your CRM, your accounting)
If the only integration is "copy and paste the result into your other tool," you are doing the work that the product should be doing.
4. Try to Break the Demo
Most wrappers demo well because the demo is a single, polished example. The model is good. The example was chosen to make the model look good. The wrapper adds nothing.
Pick something specific from your actual business. A real email you got this morning. A real client question you are dealing with right now. Drop it in and see what happens.
A wrapper will either give you a generic answer or refuse because it has no context about your business. A real tool will ask for more information, tell you what it can and can't do, and produce something you could actually send.
5. Read the Changelog
This is the cheap trick that works almost every time. Open the product's changelog or release notes page. If it doesn't have one, that tells you something already.
If it does, read the last six months. A wrapper's changelog looks like this: "Added a new model. Updated the UI. Fixed a bug." A real tool's changelog looks like this: "Added support for Stripe webhooks. Improved error handling for failed Calendly bookings. Reduced average response time on long documents by 40%."
The first list is cosmetic. The second list is a product that is solving real problems for real users.
Why This Matters
A wrapper costs you money you didn't need to spend. A bad wrapper costs you trust with your team, who watch you bring in tools that don't stick.
The good news: the test is fast. Five minutes on the homepage, two minutes on pricing, two minutes on integrations, two minutes trying to break the demo, two minutes on the changelog. Thirteen minutes total to know whether you are about to pay for software or pay for someone's API margin.
Run the test before the next free trial. Run it on the tools you already use. You will be surprised how many of them quietly fail.