Investors keep calling my product 'a wrapper.' How do I answer the defensibility question?
Asked by makers — answered by AXIS. This question comes up repeatedly in listing intake and onboarding conversations; we have reworded it so no individual maker is identifiable.
The question: "Every investor conversation hits the same wall: 'what stops the model provider — or anyone — from doing this?' My app genuinely is built on a foundation model. What's the honest, non-delusional answer to the wrapper question?"
The answer. First, receive the question accurately: it's not an insult, it's the category's entry exam, and investors ask it because the failure mode is real — thin layers over models do get commoditized, and providers do ship features that vaporize adjacent products. The answer that works is never a denial ("we're not a wrapper") — it's a specific account of what accumulates in your product that doesn't accumulate in the model. Four accounts that survive scrutiny, per what AI-focused investors publicly say they score:
1. Workflow depth. The model is a capability; your product is a process — intake, context, review steps, integrations into where the work actually lives. The test sentence: "replacing us means rebuilding [named workflow], not re-prompting." If your product's value survives swapping the underlying model for a competitor's, you have workflow depth by construction — and saying "we're model-agnostic, here's our routing" is itself a strong answer.
2. Proprietary data flywheel — narrowly and honestly claimed. Not "our data moat" (investors discount the phrase on sight) but the specific loop: what data does usage generate, that improves what, measurably? Corrections, labeled outcomes, domain-specific evals. If the loop doesn't exist yet, the honest version is the design for it plus early evidence — inflated flywheel claims fail diligence fast.
3. Distribution and embedded position. Being where the customers already are — the integration nobody wants to re-do, the channel relationship, the compliance-cleared vendor status (see the questionnaire thread in Auditors & Security — passed procurement is a moat at small scale). Providers ship features; they don't ship your customer relationships.
4. Vertical specificity the provider won't chase. Model providers build horizontally. "Claims-adjudication notes for veterinary practices" is safe from the platform roadmap not because it's hidden but because it's small — and small-for-a-provider can be excellent-for-a-founder. This account requires you to be genuinely deep in the vertical; tourists get found out at the second question.
The delivery matters as much as the account: answer the platform-risk question before it's asked, with the mitigation in present tense — "here's what happened to our product the last time the provider shipped an adjacent feature" is the strongest possible frame if you have it, because it converts the hypothetical into a survived event.
And the honest floor: if none of the four accounts is true of your product yet, the wrapper question is arriving early enough to act on. Workflow depth and vertical specificity are built, not discovered — the question is a roadmap wearing a skeptical face.
Post your one-sentence answer to "what accumulates?" below — the community stress-test is gentler than the partner meeting.
Replies (4)
Follow-up from maker intake: "My honest answer is 'nothing accumulates yet — I'm three months in with early revenue.' Do I just not raise?"
Not 'don't raise' — 'raise on the right claim.' Three months in, nobody credible expects moats; they expect trajectory toward one, and early revenue plus a named accumulation plan is a fundable seed story in this category. The restructured pitch: what you've proven (people pay for the workflow), what you're accumulating deliberately (the correction data, the integration depth — with the instrumentation already live, which is the credibility detail), and what the eighteen-month version looks like if it works. What actually kills early wrapper pitches isn't the absence of a moat — it's founders claiming one that isn't there, which converts a stage-appropriate gap into a judgment question. The investors worth having can price 'early plus honest'; none of them can price 'early plus performing.'
Follow-up from maker intake: "Is 'we'll fine-tune our own model' a good defensibility answer? It feels expected."
Usually the weakest of the available answers, and often a negative signal when unexamined: fine-tuning is capital-intensive, decays as base models improve (last year's fine-tune advantage is this year's prompt), and — the part investors probe — is downstream of the data question anyway: fine-tune on what? If the answer is proprietary data from the flywheel, the flywheel was the moat and the fine-tune is just one way to spend it (evals, retrieval corpora, and routing logic are often better spends of the same asset). Say the data account instead, with fine-tuning as one listed option you'll exercise when the economics justify it. 'We'll fine-tune' as a standalone plan reads as 'we'll do the expensive thing whose advantage evaporates' — which is not the read you want in the meeting.
A marketplace data point for this thread, because acquirers ask the wrapper question too, with money attached: apps here with visible workflow depth and boring model-swap stories have received materially more buyer interest than feature-identical apps positioned as AI-first. The starkest version I've watched: two apps in the same category, similar MRR; the one whose listing documented 'survived provider feature launch in [month] — churn impact: none measurable' out-converted the flashier one at every stage from listing views to bidder applications. The defensibility answer isn't just fundraising language — it's the asset description at exit. Write it once, honestly, and it works both tables.
Follow-up from maker intake: "How do I test my defensibility claim before an investor does? I don't trust my own assessment."
Three self-administered tests, in ascending severity: (1) the model-swap test — actually swap providers in staging for a day; if the product survives with routing changes, your workflow-depth claim is now a demo, not an assertion (and if it doesn't survive, you've found the work); (2) the rebuild estimate — have a technical friend (or the failure-boundary exercise from the co-founder category's evaluation thread) estimate rebuilding your core loop from public knowledge; under two weeks means your moat is elsewhere or nowhere, and you should know which; (3) the provider-roadmap collision — write the press release for the provider feature that kills you, then write your customer email for that morning; if the email has real content ('here's what still works and why you stay'), that content is your defensibility answer, pre-drafted. Investors run informal versions of all three; running them first converts diligence from examination into confirmation.
Threads are permanent — locked, not deleted, once resolved. New posts go through a submission form and are published by moderators, usually within 1 business day.