The Application Layer: Thin Wrapper or Real Product?

“It’s just a wrapper” is used as a verdict and is almost never stated as a claim that could be wrong. Stated properly it is a claim about replacement cost, and replacement cost is something you can estimate.

What the accusation actually says

Nearly all software wraps something. A payments product wraps a card network; an analytics product wraps a database; an operating system wraps a scheduler somebody else designed. Wrapping is not the charge. The charge, made precisely, is: this product could be replaced, by a competent team, at a cost so low that no price above the underlying API can be sustained.

That is falsifiable. It also explains why the accusation lands differently in different markets: replacement cost is not only engineering time. It includes acquiring the customers, passing their security review, integrating with their systems, and accumulating whatever state makes the product useful on day two. In some markets those dominate the software by an order of magnitude.

Three tests

The swap test

If the underlying model were replaced tomorrow with an equivalent one from another supplier, what breaks? If the answer is “some prompts need retuning and the evaluation suite needs re-running”, the product has no model-specific value — which is not fatal, but it does mean none of the defensibility is in the model. If the answer is “nothing, it is done quarterly already”, that is a sign of maturity, not of thinness.

The rebuild test

How long would a competent team with the same funding need to reach feature parity, and separately, to reach customer parity? The gap between those two numbers is the real answer. A weekend to rebuild the software and two years to rebuild the customer relationships describes a great many durable businesses.

The accumulation test

Does anything get better as customers use it, without anyone shipping code? Corrections that become training or retrieval data, workflow configuration, an evaluation set derived from real traffic, records that only exist inside your product. If nothing accumulates, the product is the same on its thousandth day as its first, and the moat condition in the accumulation-versus-decay model gives g = 0.

Where value accumulates instead

The work that makes an AI product non-trivial is unglamorous and mostly invisible in a demo, which is precisely why demos invite the accusation:

• Evaluation. A suite that tells you whether a change helped, built from real traffic. Nobody can copy yours because it is derived from your customers’ work, and without one you cannot safely change anything.
• The long tail of correctness. The demo path works for everyone. Getting the awkward twenty percent right — the malformed input, the ambiguous request, the case the model confidently fumbles — is most of the engineering, and it is what a buyer actually experiences.
• Permissions, audit and retention. Who may see what, what is logged, how long it is kept, who signs off. Slow to build, required to sell, and worth nothing in a screenshot.
• Integration. Being inside the system where the work already happens. This is where switching cost is manufactured, and it is the layer with the highest switching cost in the value-capture analysis.
• Liability and assurance. Standing behind the output — contractually, with support, with a human escalation path. The buyer is frequently paying for someone to be responsible, which a raw API cannot sell them.

The unifying observation: none of that is model work, and all of it survives the model being swapped. A product whose value is concentrated there is robust to exactly the event that destroys a thin wrapper.

Absorption risk

The specific danger for a product built on someone else’s model is not a startup competitor. It is the supplier shipping your feature, because your feature is a natural extension of their product and they have distribution you do not.

The test is uncomfortable and worth doing anyway: if you were writing your supplier’s roadmap, would your product be on it? If yes, you need a reason they will not or cannot — a market too small to matter to them, a regulated domain they will not enter, an integration they cannot make, a channel that is not theirs. “Moving faster” is not a reason; it is a hope with a schedule attached.

There is a second-order version worth naming: even if the supplier never ships it, a credible possibility that they will suppresses your pricing and your funding, because buyers and investors are running the same test.

Supplier exposure, quantified

How much a supplier can extract from you is a function of two things: how much of your cost they represent, and how hard it is to leave.

Exposure = (share of COGS from one supplier)
           * (months to migrate away)

Assume the model API is 80% of COGS and migration
takes 4 months of elapsed time:

  Exposure = 0.8 * 4 = 3.2  "supplier-months"

Now the sensitivity that matters: what a price rise
does to gross margin.

  m = 1 - c/p
  Assume p = $0.20 per unit sold, c = $0.05 per unit
    m = 75%
  Supplier raises its price 40%: c = $0.07
    m = 65%

Ten points of margin, transferred by an email, and
the only defence is the ability to leave.

Both terms are reducible and neither is free. Lowering the first means moving cost out of inference — caching, smaller models for the easy majority, doing less work per task. Lowering the second means an evaluation suite and a provider-agnostic call layer so that migration is measured in days; the mechanics of that are in writing code that is not tied to one provider.

Which brings the argument to its practical end. The question is not whether your product wraps a model — it does, and so does every competitor. The question is what a buyer would lose by leaving, what a supplier could extract before you could go elsewhere, and what your product will be worth on the day the capability inside it is available to everyone. That day is scheduled, per the drift argument; the only variable is when.