Guide

Is the target just a GPT wrapper? A diligence read

Running diligence on an AI target? How to tell a defensible system from a GPT wrapper, and what the finding does to price and structure.

You are paying for an AI company, and the model it runs on is not its AI. Before the term sheet hardens, you need to know whether the target built anything the foundation model provider can't ship in its next release. "Is it just a GPT wrapper" is the wrong shape of that question, because it collapses an architecture into a yes/no, and the yes/no is almost always wrong.

The model is a bought component for nearly every AI company you will diligence. An API call, off the shelf, commodity for the target and for everyone it competes with. So a verdict that says "they didn't train their own model" tells you nothing you didn't already know. The real question is asked layer by layer: where in this product does proprietary value actually live, and is that layer something a vendor already sells or something only this company has?

A verdict that says they didn't train their own model tells you nothing you didn't already know.

The line between commodity and moat runs inside the architecture, not around its perimeter. Sometimes the value sits downstream of the model, in how the system learns from use. Sometimes upstream, in retrieval: how the company decides what to feed the model, how it tags and structures its data, how it defines what "relevant" means for one narrow domain. The model is bought in both cases. What separates a durable business from a wrapper is where, if anywhere, the un-buyable knowledge is encoded.

What a GPT wrapper actually is, in deal terms

Strip the developer-forum definitions. A GPT wrapper is a product whose entire proprietary content is the instruction it sends to someone else's model. The prompt is the IP. Everything else, the interface, the auth, the billing, is plumbing a competent team rebuilds in a weekend. A thin wrapper is not disqualifying on its own; plenty of useful products are thin. It becomes disqualifying when the price assumes a moat the architecture doesn't contain.

The fastest test you can run in a management session

You don't need the code review back to start. In an expert session, ask the target's domain specialist or lead engineer why they built the data and retrieval layer the way they did, then watch how the answer arrives.

An instant, crisp answer means it is a codifiable fact. If it reduces cleanly to a rule, a vendor has probably already encoded it, and it is commodity. The pause means something else. They reach, they draw on years of doing the thing, the answer turns out to be a judgement call rather than a fact. That hesitation is the moat. The thing that is hard to articulate is hard precisely because it is tacit and accumulated, which is exactly what no vendor has and no model can guess.

If the expert can answer why without thinking, you do not have a moat there. If they go quiet and start reaching, you have found it.

If the expert can answer why without thinking, you do not have a moat there. If they go quiet and start reaching, you have found it. The pause is a physical, in-the-room signal, and it is available to you long before any technical audit lands.

What the demo is hiding

The demo is built to dazzle on the model layer, the easy and already-solved part. An API call works in an afternoon and feels like doing AI, so attention and polish flow toward the visible, exciting layer and starve the unglamorous one where defensibility actually sits. The value layer (data, retrieval, the boring foundation) is the part a demo can't show.

Signals in a demo or data room that the core IP is the prompt, not the system:

  • The impressive moment is the model's general fluency, not anything specific to the target's domain.
  • The data room has a thin or missing answer to "what proprietary data trains or grounds this."
  • Founders steer every conversation back to the interface and the model's latest capabilities.
  • Engineering effort, by commit history and headcount, concentrates on the UI rather than on data and retrieval.

When leadership can describe the value only in terms of the model's capabilities, the moat is the model's, and it is not theirs to sell to you.

Wrapper economics: the margin question finance can't see

Your finance team has the revenue and the burn. What they cannot price without a technical read is how this margin behaves as the model market moves, and it moves in two directions at once.

First, cost of goods. A wrapper's main variable cost is inference, what it pays the model provider per call. Traditional SaaS carries near-zero marginal cost; a wrapper carries a supplier's bill on every transaction, set by a vendor it does not control. Second, capability. The frontier moves underneath the product. A feature that is the whole company today can become a checkbox in the next model release, at which point the target competes against the free version of its own core feature. Building on a capability the model providers will absorb within a couple of release cycles is setting fire to the moat.

A feature that is the whole product today can become a checkbox in the next model release.

So the unit-economics question is really two. Does the gross margin survive current inference costs? And does the product's reason to exist survive the next model release? A shaky answer to the first moves price. A shaky answer to the second moves the decision.

The defensibility line: what a provider can absorb in 12 months

The test for durability is whether the value resists being written down. If a competitor or the model provider could replicate it by reading a clear specification, it is not a moat, it is a feature waiting to be absorbed. The strongest sign that a target has something real is uncomfortable in a data room: the people who built it struggle to fully explain why it works, because the value lives in the interaction of many tacit judgements that don't decompose into instructions. The whole is doing something the parts can't be made to explain.

That same irreducibility is your warning about a different fragility. Value that can't be written down can't be transferred by buying the company either. It lives in people. Which leads to the conversation diligence usually skips.

The conversation the diligence dodges

Here is the contrarian read, and it is the one most data rooms are built to avoid. The build-versus-buy framing inside the target was always a proxy. The decision its leadership was actually avoiding is the workforce one, and that avoidance shows up twice in your deal, both times in the valuation.

First, inside the customer base. If the target's customers are enterprises that bought the tool and sprayed it across the org without confronting what it means for jobs, expansion revenue is sitting on shelfware. Adoption is gated by trust, and the people who have to change how they work are the same people whose roles are most exposed. They are not stupid. They protect themselves by using the tool shallowly and withholding the workflow knowledge that would make it powerful. Evasion does not avoid the cost, it converts a one-time hard conversation into a permanent adoption tax. Net revenue retention that looks healthy today can be masking a base quietly reclassifying the product from "transformation" to "cost of doing business," and that reclassification is almost impossible to reverse. It caps the expansion you are underwriting.

Second, inside the asset itself. If the moat is real, it lives in tacit expertise held by specific people, and you cannot extract it from people you don't keep.

You cannot extract a moat from people, and you cannot retain it by buying the company.

You cannot extract a moat from people, and you cannot retain it by buying the company. The frank version of the finding most data rooms route around: model the handful of people who actually hold the value, name what each one does that doesn't reduce to a rule, and price the deal on whether they stay. A wrapper has no key-person risk because it has no key person. A real moat has nothing else. Avoidance at every level produces the same quiet death: the target that evaded the workforce question sold shelfware, and the acquirer that evades the key-person question buys it.

Translating the finding into a decision

The point of the read is a price action, not a grade.

Invest when the value layer is real, the pause showed up where it should, and the people who hold it are inside the deal and incentivised to stay. Reprice when the architecture is sound but margin is exposed to inference costs, or the moat is genuine but concentrated in a few unretained people; that finding moves structure, earn-outs and retention packages, not the decision to proceed. Pass when the proprietary layer is the prompt and the price assumes a system. Walk when the core feature is plainly on the frontier providers' roadmap, or when leadership has been sold its own vision and is seeking confirmation rather than evaluation. The tell for the latter is founders pulling toward the simple story every time you add necessary complexity. When you are treated as an obstacle to a decision already made, the read is finished.

When finance and legal have cleared the deal and the entire thesis rests on an AI moat no one on your side can independently see, that is the moment an independent technical read pays for itself.

Related insights: Thin wrapper or true AI? — the wrapper-vs-real argument for a general technical audience, not a live deal; and The investor’s technical due diligence playbook — the wider read.

Proof point: we've built production AI from the ground up -- see an AI product taken from zero to beta. Knowing what real takes from the inside is what lets us tell a genuine system from a marketing layer.

Common questions

What exactly is a GPT wrapper, in a deal context?

A product whose entire proprietary content is the instruction it sends to someone else's model. The prompt is the IP; the interface, auth and billing are plumbing anyone can rebuild. It is only disqualifying when the price assumes a moat the architecture doesn't contain.

What is an AI wrapper versus a system with a real moat?

The model is a bought component for almost every AI company. A wrapper adds nothing the model provider can't ship next release. A system encodes value in a layer no vendor sells: proprietary data, domain-specific retrieval, or tacit judgement that doesn't reduce to a rule.

How do wrapper economics differ from traditional SaaS?

SaaS has near-zero marginal cost. A wrapper pays the model provider on every transaction, so inference cost sits inside gross margin and is set by a supplier it doesn't control. The frontier also moves: a feature that is the whole product today can become a checkbox in the next model release.

What diligence questions expose wrapper risk?

Ask the domain expert why the data and retrieval layer is built the way it is and watch for the pause. Ask what proprietary data grounds the product. Ask whether the gross margin survives current inference costs, and whether the product's reason to exist survives the next model release.

Weighing this decision for a system that actually matters? That’s the conversation worth having before you commit budget.

Talk it through
Get AI insights in your inbox
Practical analysis on AI strategy, products, and technical leadership
No more than one newsletter a month