There's a question every product team building AI features eventually has to answer, whether they like it or not. A prospect sees the demo, nods along, and then asks: "can't I just do this in ChatGPT?"
If you don't have a sharp answer, you don't have a product. You have a wrapper, and wrappers don't survive long once the model providers ship the same capability natively. This article breaks down what actually separates a real moat from a feature that's one model update away from being irrelevant, drawing on a conversation between Charles Miglietti, CEO of Toucan, and Valentin Huang, CEO of Harvestr, plus research on how the broader AI product market is thinking about defensibility in 2026.
TL;DR
- The "can I just do this in ChatGPT" question is the single most useful filter for testing whether your AI feature is a product or a wrapper.
- A simple gut check: if a technical user can paste your core prompt into ChatGPT and get 80% of your output, you're a wrapper, not a moat.
- Real moats come from three places: proprietary data structured the right way, deep workflow integration, and a product experience that compounds with usage. Not the model itself.
- Charles Miglietti's advice from Toucan: define your value proposition against pure LLM before you build, and resist the urge to ship every AI feature that's technically easy.
- Valentin Huang's advice from Harvestr: your data layer is the moat that matters most. Bad data still produces bad output, even with the best model available.
- Industry data backs this up: most AI wrapper startups report no meaningful revenue, and the ones that survive are the ones that built defensibility underneath the wrapper, not just on top of a model.
Why this question matters more in 2026 than it did in 2023
In 2023, building an AI feature was a genuine differentiator on its own. Prompt engineering was a real skill. Knowing how to wrap a model well could make a noticeably better product than a competitor who hadn't figured it out yet.
That window closed. Foundation models got dramatically better at understanding intent, which means a merely well-prompted wrapper does less work than it used to. The barrier to building an AI feature dropped, and that's exactly the problem: if it's easy for you to build, it's easy for everyone else too, including the model providers themselves.
The data on this is not encouraging for thin wrappers. One analysis of AI wrapper startups found that 60 to 70% generate zero revenue, with only a small fraction reaching meaningful monthly recurring revenue. The pattern repeats across the market: companies that built a clever interface on top of an API call discovered that the interface alone wasn't worth paying for once the underlying model improved or a competitor cloned the same flow in a weekend.
This isn't a reason to avoid building AI features. It's a reason to be precise about what you're actually building underneath them.
The test: would your product survive if the model got smarter tomorrow?
There's a useful way to stress test this that doesn't require a strategy offsite. One framework circulating among AI product builders proposes a direct substitution check: can a technical user get most of your product's output by pasting your core prompt directly into ChatGPT or Claude? If the answer is yes, the honest conclusion is that your UI, your onboarding, and your branding are real assets, but they're a head start, not a moat.
A second version of the same test looks at dependency rather than substitution: if your model provider revoked your API access tomorrow, does your product still deliver value to a customer who's mid-session? For most wrapper-style products, the answer is no, which tells you where the actual value is concentrated, and it isn't in your product.
Charles Miglietti frames the same problem from the founder's side, based on what Toucan kept hearing from prospects during the company's own AI pivot: "the main feedback you may have from leads or customers is, yeah, but can I do that directly in ChatGPT? So really defining where your moat is, where your edge is, and what can be done uniquely in your product is the most important thing." The test isn't theoretical for him. It's the question that showed up in nearly every sales conversation.
What actually creates defensibility (and what doesn't)
Strip away the hype and the frameworks converge on roughly the same three categories.
Proprietary data that compounds. Not data you simply store, data that makes the product measurably better as more of it accumulates and that a competitor genuinely cannot access by scraping the public web or calling the same API you do. One framework for thinking about this distinguishes data you merely hold from data that feeds back into better product behavior, on the basis that the first is storage and only the second is a moat.
Workflow depth. The harder your product is woven into a customer's daily operations, the higher the switching cost, regardless of how good the underlying model is. A chatbot that answers questions in isolation is trivial to replace. A system that's accumulated a customer's approvals, edits, and historical context over months is not, because replacing it means losing that history.
Experience that compounds with usage. This one gets dismissed too quickly as "just UX," but the version that matters isn't cosmetic. It's the product getting genuinely better for a specific customer the longer they use it, through feedback loops the model alone can't replicate.
What doesn't make the list, no matter how often it gets pitched as one: model selection. Which foundation model you're calling is, at this point, closer to a commodity choice than a competitive advantage. Multiple analyses of the AI product market in 2026 converge on this point independently: defensibility is something built around the model, never inside it.
Valentin Huang's case for the data layer as the real moat
Ask Harvestr's CEO where the moat actually lives, and the answer isn't the model. It's what feeds it. "One of the moats that you have is your data. And whatever AI features you're building, it's super critical in the first place to get your data layer right, because with bad data, you will get bad results even with the latest and most powerful models."
This sounds obvious stated plainly, and yet it's the step most teams skip. Valentin's point is more specific than "data quality matters." It's that the data sitting in your product right now is probably not formatted the way your AI feature actually needs it. "Usually, for a specific feature, the data you will have in your database might not be formatted exactly in the right way, or you don't have the whole spectrum you actually need for this specific use case." Getting that right takes real time, and it has to happen before you start seriously testing models, not after.
The sequencing matters. Teams that jump straight to model selection and prompt tuning, skipping the unglamorous work of restructuring their existing data, end up with an AI feature that looks impressive in a demo and falls apart against messy real customer data. The fix isn't a better model. It's going back to the data layer that should have been the starting point.
Charles Miglietti's case for protecting the core, not chasing every feature
Charles's advice runs in a slightly different direction, and it's a useful complement: even once you know your moat, the discipline is in not eroding it. "You don't want to add too many features that are easy to build with AI. Really, really, I would say: define what makes you unique and different, and don't dilute it."
The trap is specific to this moment in AI tooling. Because shipping an AI feature is faster now than it's ever been, teams feel pressure to ship constantly, and every easy feature feels like progress. But a pile of easy-to-build AI features that anyone else could build just as fast doesn't add up to a moat. It adds up to a product that's harder to explain and no harder to replace.
The two pieces of advice connect more than they first appear to. Valentin's data layer point and Charles's dilution warning are both versions of the same discipline: spend your effort on the thing that compounds and is genuinely yours, not on the thing that's merely possible this week because the tooling got easier.
The UX argument that's easy to underestimate
There's a third angle from the same conversation that doesn't get enough attention: the experience layer itself can be part of the moat, but only if it's treated as real product work rather than a wrapper around a chat box.
Valentin again, on what Harvestr got wrong before they got this right: "When you ship a new AI feature, it's not just about adding AI to your product. It's really about thinking through the overall experience and how you make sure your customers get value from it and adopt it in their day to day. That's also how you actually differentiate from ChatGPT or Claude. It's thinking through the whole product experience, not just one AI feature, and that takes a lot of work and a lot of iteration, versus just choosing a model and running it on your data."
This is consistent with what the wider market is converging on. The strongest products tend to combine more than one of these moats at once: workflow integration, a data feedback loop, and a deliberately designed experience, working together rather than any single one carrying the whole weight.
What this looks like specifically for embedded analytics
For ISVs and SaaS teams building analytics into their own product, the ChatGPT question shows up in a particular shape: "why would my customer ask your embedded AI instead of just pasting their data into ChatGPT themselves?"
The honest answer for most bolted-on AI chat features is that there isn't a strong one. A chat box sitting on top of a query engine, without a governed semantic layer underneath it, is exactly the kind of thin wrapper a model update can quietly outpace. One comparison of embedded analytics platforms in 2026 draws this distinction directly: tools that simply bolt a chat box onto an existing query engine are a fundamentally different category from platforms that are AI-native end to end and governed by a semantic layer underneath.
That distinction is the actual moat in analytics. A customer can ask ChatGPT a question about a spreadsheet they upload. They cannot ask ChatGPT a governed question against their live, multi-tenant, row-level-secured production data and get an answer that's guaranteed to be numerically correct, because ChatGPT has no access to that data layer and no contract to honor its access rules. The moat isn't the chat interface. It's everything underneath it that makes the chat interface trustworthy.
There's a retention angle here too, not just a defensibility one. Recent analysis of embedded analytics adoption found that customers who actively use embedded analytics churn at meaningfully lower rates than those who don't, which means the moat question and the revenue question are the same question, not two separate ones.
A practical filter for your own roadmap
If you're deciding whether to build the next AI feature on your list, run it through three questions before committing engineering time.
Does this feature get better the more a specific customer uses it? If the tenth use produces the same quality of output as the first, you're not building a moat, you're building a convenience. Convenience is fine, but don't budget for it like it's defensible.
Could a customer get most of this value by copying their data into ChatGPT themselves? Be honest here. If the answer is close to yes, the feature isn't wrong to build, but it shouldn't be the centerpiece of your AI story, and you shouldn't expect it to drive retention on its own.
Is the data underneath this feature actually ready, or are you assuming it is? This is the question Valentin's team learned to ask the hard way. If your data layer needs restructuring to support the feature properly, that work needs to happen first, not in parallel, and definitely not after launch.
Where Toucan fits into this
This is the exact problem Toucan rebuilt its product around. Toucan's AI layer doesn't sit on top of raw customer data the way a generic chat wrapper does. It sits on top of a governed semantic layer, multi-tenant by design, with row-level security built in rather than bolted on. When a user asks a question, it gets translated into a deterministic query against that governed layer, not interpreted freehand by a model guessing at the schema.
That architecture is what answers the "can't I just do this in ChatGPT" question for an ISV's own customers. ChatGPT can summarize a CSV someone uploads. It cannot enforce tenant isolation across thousands of customers, guarantee that a finance team only sees its own numbers, or guarantee the underlying metric is the one your business actually certified as correct. That gap is the moat, and it's the reason embedding AI inside a product you control is fundamentally different from letting customers route around you to a general-purpose model.
If you're an ISV trying to figure out whether your own AI roadmap is building real defensibility or just shipping features that look impressive in a demo, book a demo and we'll show you exactly where the semantic layer sits underneath the conversational interface, and why that's the part competitors can't copy in a weekend.
Go deeper
- Analytics Solution: Should You Build or Buy? The build vs. buy decision through the same defensibility lens: what's worth owning and what isn't.
- The Ultimate Guide to Embedded Analytics Context on what embedded analytics actually means and why the architecture underneath it matters more than the interface on top.
- Introducing Our New Multi-Tenant Service A closer look at the row-level security and tenant isolation that sits underneath Toucan's AI layer.
- How to Generate New Revenue Streams with Data in a SaaS Product How a defensible analytics layer turns into a retention and upsell lever, not just a feature checkbox.
FAQ
What does it mean to build an AI moat against ChatGPT?
An AI moat against ChatGPT means building defensibility that doesn't disappear the moment a foundation model gets a capability upgrade. Most AI wrapper products fail this test because their core value is a well-written prompt or interface sitting on top of a model API, something any competitor or even the model provider itself can replicate quickly. A real moat comes from proprietary data that compounds with usage, deep integration into a customer's existing workflow, or a product experience that gets measurably better the more a specific customer relies on it. The practical test is simple: if a technical user could get most of your product's value by pasting your core prompt into ChatGPT directly, you don't have a moat yet.
Why do most AI wrapper startups fail to build a lasting business?
Most AI wrapper startups build a thin layer over a foundation model's API without creating any of the three things that actually create defensibility: proprietary data, workflow integration, or genuine switching costs. Industry data on AI wrapper companies shows the majority generate little to no revenue, and the ones that do succeed early often see that advantage erode quickly once a competitor copies the same flow or the model provider ships the same feature natively. The wrapper itself isn't the problem. Treating the wrapper as the entire product, rather than as a starting point for building something harder to replace underneath it, is what causes most of these products to stall.
Is my data really a moat, or just storage?
Data only becomes a moat if it feeds back into the product getting better, not simply because you're collecting and storing it. Having a large dataset sitting in a database doesn't create defensibility on its own. The test is whether each additional customer interaction makes the product measurably more useful for that specific customer or for the product as a whole, in a way a competitor starting from zero can't replicate quickly. If your data just sits there without improving outputs over time, it's an asset, but it's not the kind of asset that protects you from a competitor with access to the same foundation models.
How do I know if my product is just a wrapper around an LLM?
Run a direct substitution test. Take your product's core feature and ask whether a technically capable user could replicate most of its value by writing a similar prompt and pasting it into ChatGPT or Claude themselves. If the answer is close to yes, the parts of your product that feel valuable right now, your interface, your onboarding flow, your branding, are real but they're a head start rather than a structural advantage. A second useful test: if your model provider cut off your API access tomorrow, would your product still deliver value to a customer mid-session? If not, the value in your product is concentrated somewhere other than your own code.
Should I avoid building AI features if I don't have a strong moat yet?
No, but you should be honest about what each feature is actually accomplishing. Easy-to-build AI features can still be useful for proving demand, generating usage data, and giving customers a reason to engage more deeply with your product, even if they aren't independently defensible. The mistake isn't building those features. It's mistaking a pile of them for a strategy, or assuming that shipping enough AI features eventually adds up to a moat on its own. The discipline is building toward the data layer, workflow integration, or compounding experience that will eventually make those features hard to copy, rather than treating velocity as the goal in itself.
