Open any launch feed on a Tuesday morning and you will find a dozen products that look identical. Same dark gradient, same "AI-native" headline, same three-tier pricing table. Underneath a good number of them is a React frontend, an OpenAI key, and roughly two hundred lines of glue code.
That is not automatically a bad thing. Some wrappers are genuinely useful, and a well-designed interface on top of a model can save real time. The problem starts when one gets sold as infrastructure. When a founder tells an enterprise buyer that the retrieval layer is proprietary, and it turns out to be a system prompt plus a vector database they signed up for last month, somebody is going to have a bad quarter.
So it is worth knowing how to tell the difference quickly. Here is what we check when a submission lands in our review queue, roughly in the order we check it.
Start with the docs, not the homepage
Wrappers spend their engineering budget on the landing page. That is where the animation work went, and often it is genuinely nice work. The tell is what happens when you click through to the documentation.
With real infrastructure you land on something dense: authentication, an endpoint reference, error codes, rate limits, SDKs in two or three languages, a changelog that shows breaking changes being handled like adults. With a wrapper you get a Notion page with four screenshots and a "contact us for API access" button.
The short version of the question is this: could you integrate the thing without talking to a salesperson? If the answer is no, and the product is being marketed to developers, that mismatch is your answer.
There is a fair exception here. Plenty of early teams have real technology and thin docs because there are three of them and they are busy shipping. In that case the code tells you what the documentation does not. Look at the repository, the commit history, and how the maintainers answer issues.
Send ten requests at once
You will learn more from five minutes of load testing than from an hour on a demo call.
Real infrastructure is built around concurrency because it had to be. Somebody spent months on connection pooling, cache invalidation and queue behaviour, and that work shows up as response times that stay flat when you push on them. Send ten requests together and you get ten timely responses.
A wrapper inherits the latency of whatever it sits on, adds its own overhead, and frequently has no queue at all. Response times hovering right around the underlying model's own latency are a hint. Requests that start failing when three of them arrive together is not a hint, it is the answer.
This is also the test nobody games, because faking it would cost real money.
Do the token maths
Pull up the pricing page and work backwards. What does this plausibly cost to run?
Legitimate pricing tracks something real: compute, storage, proprietary data, support you actually want. Wrapper pricing tracks the gap between what the provider underneath charges and what the market will pay. There is nothing wrong with margin, but you should know when you are buying margin rather than technology.
The useful exercise is to estimate the token spend for your own usage and compare it with the seat price. If a subscription is moving a few cents of tokens per user per month and wrapping them in a form, you are paying for the form. Sometimes the form is worth it, especially when it keeps a non-technical team away from raw API calls. Often it is not, and a scheduled script does the same job for the cost of the tokens.
Be suspicious of products that do everything
Good infrastructure has a narrow surface. Stripe does payments. Twilio does messaging. The scope is boring, and that is the point, because a narrow surface is what lets a team make hard guarantees about it.
Foundation models are general, so anything built directly on one inherits that generality along with the temptation that comes with it. This is how a note-taking app ends up claiming it also replaces your CRM, your analytics and your junior developer. When the feature list reads like a list of things a language model happens to be able to do, you are usually looking at prompts with a user interface attached.
The counter-check is to ask what the product deliberately does not do. Teams building real systems can normally answer that on the spot, and they answer it with a reason.
None of this is a purity test
We are not arguing that wrappers are worthless. Some of the most used tools of the past two years are, structurally, a thin layer over somebody else's model, and they earn their keep through interface design, distribution, or a specific workflow nobody else bothered to build.
The point is to price the thing correctly, in money and in risk. A thin layer is exposed to every price change, deprecation and rate limit of the provider beneath it. If that layer sits in your critical path, you have taken on that exposure as well, and it is better to know that before the migration email arrives than after.
Why we run a review queue
Directories are easy to fill and hard to keep worth reading. We open every submission by hand, and we do reject things, most often for the reasons above: no documentation worth the name, pricing with nothing underneath it, a feature list that is really a capability list for a model somebody else trained.
We get it wrong sometimes, and we reverse decisions when a maker explains something we missed. But the default is that a listing has to earn its place, because a directory where the entry next to yours is junk quietly devalues yours too.
Where to go next
If you would rather skip the filtering work, browse the AI Tools category or the directory as a whole. A person has opened and read every entry in there.
Building on top of one of these platforms yourself? The Automation and SaaS categories are where the tools with real APIs tend to land.
And if you have built something with genuine technical depth, submit it. With a documentation link, ideally.