Article — "SaaS gets disintermediated: users bypass products for ChatGPT — and rebuild them in Claude Code": Christoph Janz reportedly replaced his own Knowledge Hub build with a simpler approach.
About a month ago he vibe-coded a Knowledge Hub: roughly 43,800 lines of Python, six data source connectors, a vector database, MCP servers, a process supervisor. Then, per his account, he moved to a simpler solution running in parallel.
Not because it failed. Because plugging his data sources — Attio, Slack, Zendesk — straight into Claude got him "90–95% of the value for about 10% of the effort. Especially 10% of the maintenance effort … and that matters a lot."
Plugging his data sources straight into Claude got him 90–95% of the value for about 10% of the effort — especially 10% of the maintenance effort.
Sit with that. The disintermediation case study is a product builder disintermediating himself, and the line he draws isn't around features or answer quality. It's around maintenance. The pre-indexed search was faster; keeping it alive was the whole cost.
Now widen the frame, because this is happening to products you don't own.
Martin Alderson reportedly cloned most of Linear's core functionality in about 20 prompts. A couple of evenings, a few million tokens, all covered by his $200/month Claude Max subscription. No source code — per his account, he opened DevTools, browsed the app, exported a HAR file of the network traffic, and set Claude Code loose on it. "Built entirely from reverse-engineering network traces."
Linear had nearly a decade of some of the best designers and engineers in the industry building it. Alderson's clone is buggy and missing pieces, and he's clear it's not production-ready. But his point isn't that he matched Linear. It's that he got a passable version while "paying very little attention," and most SaaS isn't anywhere near Linear's polish. If an agent can produce a passable Linear, it can do a very good job on the vast majority of software that is, frankly, barely functional.
Two fronts, one conclusion: the interface is now the disposable part. Janz proves you can walk away from your own build. Alderson proves a stranger can rebuild yours off nothing but the traffic your app already emits.
Which brings us to the advice everyone's giving, and why it's backwards.
The reflexive fix is to "become AI-native" by exposing an MCP server so you govern access instead of losing it. The pitch is seductive: your SaaS already has structured data models, multi-tenant architecture, APIs, access controls — you're practically AI-ready by accident, so build the intentional layer on top and keep users inside an experience you control.
Here's the problem nobody says out loud. A well-built MCP server is a clean, documented map of your business logic, packaged for machine consumption. The same artifact that lets a friendly agent "govern access" is the one that lets a cloner skip the HAR-file archaeology entirely.
Alderson had to reverse-engineer Linear from minified traces. Expose an MCP and you've done the reverse-engineering for him — and published it. You're not building a moat. You're shipping the blueprint.
And even if that weren't true, the MCP-as-salvation story has a second, quieter trap: MCP has its own retention curve, and it punishes half-measures brutally.
Apollo reportedly launched theirs with Anthropic in March 2026. Their MCP exposed only 20% of what the web app could do. Week-4 retention reportedly fell ten points; credits per team hit an all-time low. Builders trying to ship real GTM automations hit a dead end immediately and went back to the UI.
The fix wasn't cleverness — it was treating the MCP as a real product. Apollo shipped 30+ MCP features in twelve weeks, porting the classic product's capabilities over to the new form factor. The numbers flipped: week-4 retention up 34%, new teams per week up 47%, credits per team up 135%, each a new all-time high, plus millions in ARR.
Read that carefully. A partial MCP doesn't just fail to save you — it accelerates churn, because a dead-end workflow churns harder than a missing feature. An agent that can do 20% of the job trains the user to leave. So "expose an MCP" is either a massive product commitment or an own goal. There is no cheap version.
So if the interface is disposable and the MCP is a blueprint-plus-liability, what actually survives?
The Toyo team lived the answer. They cancelled their entire SaaS stack — CRM, email automation, website builder, prospecting tools — and rebuilt what they needed in Claude Code. The CRM took an afternoon. Then they went further: they gave the agent database access and let it operate the CRM too, and threw away the interface entirely. Their framing is the sharpest in the whole discourse: software was valuable because it helped humans work; agents are valuable because they do the work; so the interface layer looks like overhead.
But notice what Toyo is: a team of seven, running its own tools, absorbing its own maintenance. That's the fair critique of the whole "build your own SaaS" narrative — building it is one thing, but running the infrastructure, updating it, and babysitting the integrations forever is quite another.
That gap is your business. Not the code. The headache.
Look back at Janz. What he fled wasn't complexity for its own sake — it was connections getting lost, MCP servers going down, sync jobs failing silently, sources reporting success while nothing landed in the database. That operational burden is exactly what a customer with Claude Code inherits the moment they rebuild you. The clone is free. Keeping it alive at 2am is not.
So here's the audit to run on yourself, ruthlessly, before Andrew Wilkinson runs it on you. He looked at Wispr Flow and reportedly said: "I don't know how Wispr Flow is a business in 2027. Literally weeks away from not needing to exist. I have never seen a clearer example of Feature Not a Product." Treat "feature, not a product" as a diagnosis, and self-administer it first.
For every capability you sell, ask what survives a customer realizing they could rebuild it.
The code doesn't. Alderson proved that. The interface doesn't. Janz and Toyo proved that. So four things are left standing, and they're the only things worth pricing around.
Maintenance: the burden Janz ran from and Toyo took on. You keep the thing running so the customer never has to. Sell that explicitly — you are the on-call engineer they don't want to hire.
Accumulated data: the history that took years to build and can't be regenerated by a prompt. A clone starts empty. Your gravity is the data that's already inside.
Deep, live integrations: not the connectors — the ongoing work of keeping six of them alive when every upstream API breaks on its own schedule. Janz's connectors kept failing silently. That failure mode is your value proposition, if you actually solve it.
Trust: whose problem is it when the data is wrong, the sync lies, the automation fires on stale context? A DIY rebuild makes you the operator of your own liability. A vendor absorbs it.
Now use Apollo's parity test — but point it at survival, not just at MCP coverage. Put your product's full capability list next to what a customer could plausibly rebuild in a weekend. Sort the gaps not by how hard they are to build but by how central they are to the job the customer hired you for. For the top ones, write the sentence a churning customer would say out loud.
If that sentence is "I could just build this myself" — you're a feature.
If it's "I could build it, but I don't want to own the maintenance, I can't regenerate the data, I can't keep the integrations alive, and I don't want to be the one holding the bag when it breaks" — you're a product.
The retention playbook that follows is uncomfortable but simple. Stop selling the interface; it's the first thing to go. Stop treating a thin MCP as insurance; it's an accelerant. Price and position around the burden you absorb, because in a world where anyone can rebuild the software in 20 prompts, the durable thing was never the software.
It's that they'd rather pay you than own the headache.