The End of SaaS (As We Know It)

A few weeks ago we cancelled our DataGrip licenses. Not all of them. All of them.

JetBrains has been a good vendor for years. DataGrip is a serious product built by serious engineers. There was nothing personal in this. What happened is simpler and, I think, more interesting: one of our engineers spent a couple of weeks building an internal database client tailored to how we actually work, plugged a real AI model into it, and quietly the JetBrains tab stopped getting opened. When renewal came, we did the math, looked at each other, and clicked cancel.

That cancellation wasn’t a one-off. In the last few months, we’ve also rebuilt our error tracking and stopped paying Sentry and Bugsnag. We’ve quietly demoted Salesforce to a database underneath an interface we built ourselves. We’ve moved from Notion to Outline and started building the missing features as plugins. Each move had its own internal logic. Together, they tell a story that I think most SaaS founders, and a lot of CTOs paying SaaS bills, haven’t fully absorbed yet.

The story isn’t “SaaS is dying.” SaaS is fine. Stripe is fine. Cloudflare is fine. Datadog is fine. What’s ending is a specific version of SaaS — the one that dominated the last fifteen years, the one that sold software to people who needed software. That version is over. And the reason it’s over is that the two moats it stood on — code customers couldn’t build, and know-how their teams didn’t have — both quietly collapsed.

Most SaaS vendors haven’t realised it yet. The ones who do will move up the value chain and survive. The ones who don’t will be cancelled, wrapped, or quietly replaced by plugins.

Let me walk through what happened, with the real examples, and then what should come next.

The Two Moats SaaS Rested On

For roughly the period from 2010 to 2024, almost every successful B2B SaaS company stood on two moats. Most of them couldn’t have articulated it this clearly — they would have said “product” or “execution” — but underneath the marketing copy, the actual defensible thing was always one of these two, and usually both.

Moat one: code your customers couldn’t write. A serious enterprise tool — a database client, a CRM, an analytics platform, a documentation system, an error tracker — is not a weekend project. In the pre-AI era, it was a multi-year effort by a team of specialists, plus a long tail of small interactions that only show up after thousands of users have hit them in production. The customer might have brilliant engineers, but those engineers were busy building the customer’s actual product. Diverting them to rebuild a database client was economically irrational. So the customer paid the vendor.

This moat was real. Twenty engineers at JetBrains writing DataGrip for a decade produced something that any individual customer’s team would have needed five years to even attempt. The premium pricing was the rational reflection of that asymmetry. The vendor wasn’t extracting rent. They were genuinely selling a thing you couldn’t make yourself.

Moat two: know-how you didn’t have, and couldn’t easily acquire. This one is subtler, and it’s the one most people miss. The bigger SaaS vendors didn’t just sell code. They sold accumulated industry expertise encoded into product decisions. Salesforce knows what a sales pipeline looks like across ten thousand customer organisations. Sentry knows what error tracking should do because they’ve watched a hundred thousand production incidents. Notion knows how documentation systems get used at scale because half the tech industry has built knowledge bases on top of them. That knowledge isn’t in any single feature. It’s diffused through the product — in defaults, in field names, in the shape of the data model, in the workflows the UI nudges you toward.

When you bought Salesforce, you weren’t just buying software. You were buying the embedded answer to “what does a sales process look like?”, refined over twenty years of customer feedback. Your team didn’t have to figure that out from scratch. The product carried the answer with it.

Both moats were genuine. Both justified the prices. For fifteen years, the math worked: paying SaaS vendors was cheaper than rebuilding the code yourself, and using their products was smarter than acquiring their industry know-how from first principles.

In 2026, both moats are mostly gone.

How AI Dissolved Moat One

The dissolution of the code moat is the easier of the two to see, because anybody who has watched a competent engineer work with modern AI tooling has watched the proof in real time.

The cost of building a tool used to be measured in engineer-years. The cost of building the same tool, today, with one engineer using AI well, is measured in engineer-weeks. Not for everything — not for products that genuinely require deep research, novel algorithms, or specialised infrastructure. But for the long list of B2B SaaS that consists of “a sensible UI on top of a sensible data model that does sensible things to a sensible workload” — which is most of it — the engineering cost has collapsed by something like an order of magnitude.

This brings us to the first example, which is the cleanest illustration.

Example one: DataGrip, and the cancelled subscription

For most of the last decade, DataGrip’s pricing was protected by three real moats: engineering hours (a competent SQL client across fifteen database engines is a multi-year project), accumulated polish (ten thousand small interactions that don’t annoy you), and brand trust (you want a serious vendor logo when you’re connecting a tool to production databases). That bundle justified the price tag.

Two things changed almost at the same time. The engineering-hours moat got crushed: a single engineer with modern AI coding can produce in a few weeks what used to require a team and a year. And the AI inside DataGrip became the weakest part of it. The most important feature in a 2026 database client is no longer the editor — it’s the assistant that helps you write queries, explain results, and avoid nuking production. JetBrains’ built-in AI is, to put it generously, far behind what a well-prompted Claude or GPT-5.x can do when you wire it correctly.

So when we built our internal client, we didn’t try to match DataGrip feature for feature. We built the four things DataGrip wasn’t going to give us no matter how much we paid:

• A real AI assistant, not a feature retrofitted into a 2014 architecture. It understands our schema, our naming conventions, our domain language. It knows the difference between a restaurant in our production model and a restaurant_legacy in deprecated tables.
• GDPR compliance by construction. Every query runs through our infrastructure, with our access controls and audit boundaries. With DataGrip, queries left the laptop and went to external AI servers, and from a compliance perspective that was a constant low-grade headache.
• Full audit of who ran what. We can answer, in seconds, “who queried the users table in the last 24 hours, and what did they ask for?” — a question DataGrip structurally cannot answer because the tool runs on the laptop and the audit trail doesn’t exist.
• Server protection before the query lands. This is the one I’m proudest of. Before any query is dispatched, our tool runs EXPLAIN, has the AI analyse the execution plan, and flags queries that are about to scan a hundred million rows or lock a critical table. Junior engineers used to bring down staging once a quarter. That hasn’t happened since we shipped this.

None of those four things are exotic. None are out of scope for a vendor like JetBrains to build. But they require betting the architecture on AI-native primitives and on customer-specific deployment, and that’s not what a horizontal SaaS sold to a hundred thousand companies is structured to do. They ship the lowest common denominator. We get to ship exactly what we need.

The market tell came a few months ago: JetBrains released a free tier of DataGrip, after years of charging serious money for it. The official framing was the usual “expanding access for the community.” The reading any vendor watcher would do is different: when a market leader cuts the price to zero, what they’re telling you is that they’re losing seats faster than they’re winning them. That same tell, in a dozen other SaaS categories, will be the story of the next eighteen months.

How AI Dissolved Moat Two (The One Nobody Saw Coming)

The second moat is more interesting, because it’s the one most SaaS founders still think they have. “Sure,” the argument goes, “AI made coding cheaper, but our real moat was never the code — it was twenty years of domain expertise built into the product. The customer can’t replicate that.”

That argument was solid until about two years ago. It is now visibly falling apart, and the reason is not subtle: the same LLMs that made coding cheap also made domain expertise cheap. The internet’s accumulated writing on every B2B domain — sales processes, support workflows, error tracking patterns, documentation taxonomies, payroll regulations, project management methodologies — was the training data. A team in 2026 with a competent LLM has functional access to the consensus best practices of every industry, expressible in plain language, queryable on demand, applicable to whatever specific problem the team is currently solving.

This is not a small thing. It used to be that “what does good support case management look like?” was a question you could only answer by hiring someone who had run support at three companies, or by buying Salesforce and absorbing the answer through the product. Today, that question can be answered competently by anyone with an LLM and an hour to read the answer. The answer won’t be perfect. It will be roughly as good as what you’d get from a competent industry consultant — which is to say, roughly as good as what most SaaS products encode anyway.

The vendors who thought their moat was “we know your industry better than you do” are about to discover that, in 2026, every team can rent the equivalent of a thoughtful industry consultant for twenty dollars a month. The know-how moat hasn’t been crossed by the customer — it’s been undercut by a third party that the SaaS vendor doesn’t control and can’t outspend.

Which brings us to the second example, and one that’s harder to swallow than the DataGrip one because here the price was never the problem.

Example two: Sentry and Bugsnag, replaced even though they were cheap

We were paying for both Sentry and Bugsnag because different parts of the stack had landed on different vendors over the years. Combined, the two were not an expensive line on the budget. The kind of cost where, if you asked finance to flag it, they’d laugh and tell you to focus on the AWS bill.

We replaced them anyway. With an in-house tool built in Go.

The reason matters, because it’s the part of the SaaS story most CTOs miss: when SaaS is cheap, replacing it for cost reasons is dumb. Replacing it because you can build something better — that’s the new pattern. There’s a category of SaaS tools that survived for years on what I’d call the “too cheap to fight about” defence. Error tracking is the textbook example. The price was low enough that nobody on the engineering team wanted to be the person who tried to justify rebuilding it. Year after year, you renew on autopilot.

This anaesthetises the customer. The question “is this actually what we need?” stops being asked.

What we actually wanted, and weren’t getting:

• A system that understands the error, not just its shape. Classic fingerprinting groups by stack trace and exception type. It’s stupid. Two errors with different root causes get grouped because they throw in the same logging utility. Two errors that are the same bug get separated because the call stack varies slightly. We wanted semantic grouping. AI is good at that.
• A system that does the first ten minutes of triage before a human sees it. When an error fires, an engineer normally opens the issue, scans the trace, jumps to the offending file, looks at the last three commits, checks if anything changed in the deploy that preceded the spike. We wanted that done automatically, with a structured pre-investigation waiting when the engineer opens the issue: “this error started 17 minutes after deploy a3f4c2, which touched OrderProcessor.go line 84, and the new code path doesn’t handle the case where customer.region == null. Suggested fix attached.”
• Ranking by business impact, not frequency. Sentry will happily tell you an error happened ten thousand times. It won’t tell you that those ten thousand were all an internal bot, while the error that fired eleven times hit your three largest customers. A horizontal SaaS can’t know who your customers are or what they’re worth. Ours does.
• A UX that matches how we debug. The keyboard shortcuts, the panels, the inline links to our deploy pipeline and customer admin — none of that was ever going to be in any vendor’s roadmap.

The implementation took about six weeks of one engineer’s time, plus a couple of weeks of UI help. Go for ingestion, because the workload is exactly what Go is built for. The AI parts went into prompting and evaluation, not engineering — getting a model to consistently produce a good triage summary across thousands of different error shapes is the hard part, and it’s the part no off-the-shelf vendor is going to do for your codebase, with your conventions, with your domain language.

Here’s the calculation finance never makes correctly: the cost of a SaaS tool isn’t the subscription. It’s the subscription, plus the engineering hours spent working around its limitations, plus the hours spent doing manually what a better tool would automate, plus the decisions not made because the data is the wrong shape. When I added those up for Sentry and Bugsnag, the subscription was the smallest by an order of magnitude. The hours we spent triaging that should have been automated were the biggest. We’ve cut that, conservatively, by half.

The subscription was never the cost. The cost was the resignation. We had stopped expecting the tool to give us what we needed, because we’d been trained that horizontal SaaS only gives you the average product.

When You Can’t Replace: The Overlay Pattern

The two examples above assume something most enterprises can’t assume — that you can actually cancel the contract. Real enterprises are full of vendors you can’t politically remove, audit dependencies you didn’t know existed, and reporting pipelines that route through systems whose owners retired five years ago.

There’s a saying that’s been around in enterprise IT for forty years, originally about IBM mainframes: nobody ever got fired for buying IBM. It survived because it captured a real, unspoken contract between buyer and vendor. You pay the premium. They give you cover. If the project succeeds, you look smart. If it fails, you bought the safe option. The price tag was, in part, the price of plausible deniability.

In 2026, the modern version of that rule is sharper and worth saying out loud:

Nobody gets fired for buying Salesforce. Plenty of people get fired for removing it.

That asymmetry is the entire game. When you sign Salesforce, the risk is distributed. When you remove Salesforce, the risk concentrates on exactly one person — usually you — and the failure mode is spectacular. Sales productivity drops for a quarter because the new tool isn’t quite right. The CFO asks why. The CRO suddenly remembers he was always uncomfortable with the migration. You, the person who proposed the change, become the explanation.

So we made peace with it. We were not going to replace Salesforce for support cases. We were going to do something more interesting.

Example three: Salesforce, demoted to a database

Anybody who has used Salesforce for support cases knows what I’m about to describe. You open a case. To understand what it’s actually about, you click through the description tab, the comments thread, the related records tab, the activity timeline, the customer profile panel, and two or three custom objects somebody configured in 2019 that everyone is too afraid to remove. By the time an agent has clicked enough panels to understand a single case, three minutes are gone. Across a few dozen agents handling hundreds of cases a day, the math isn’t subtle.

The official answer is to configure Salesforce better. Hire a consultant. Roll out Lightning. Then roll out Lightning again, but the new Lightning. The configuration surface is enormous, and a healthy ecosystem of consultancies makes a good living telling you that if your UX is bad, you just haven’t configured it correctly yet. There’s some truth to that. A skilled admin can absolutely make the UX less bad. But “less bad” is the ceiling, because the underlying product is a configurable form engine from a different era.

So we stopped trying to fix the inside of the box. We built our own box around it.

When a support agent on our team starts their shift now, they don’t open Salesforce. They open our internal tool. The Salesforce window still exists, somewhere, on their machine. They rarely look at it. Cases still live there. Statuses still update there. Reports still come from there. The contract is honoured. The Salesforce users, in any meaningful UX sense, no longer exist on our team — they were replaced by users of our tool, which talks to Salesforce underneath.

What our overlay does that Salesforce doesn’t:

• One-sentence summary of what the case is actually about. AI reads the description, the customer’s recent activity, the product context, and the last few interactions, and produces a paragraph at the top of the case view. The agent opens the case and the first thing they see isn’t twelve fields — it’s plain English. “Customer X is on plan Y, has had two billing cases in the last sixty days, is reporting that the export feature on the Z report produces duplicate rows since this morning, and based on wording is more frustrated than average.”
• A suggested response before the agent types anything. For routine cases, the AI drafts a candidate the agent can edit, approve, or reject. We’re not autoresponding without review — that’s how you end up apologising on Twitter. But the rhythm changed entirely.
• Tool suggestions in context. Our team has a dozen internal tools — refund processors, log inspectors, the customer impersonation console. Knowing which to open used to be tribal knowledge. The overlay surfaces the right one, with the customer’s ID pre-filled. New agents become productive in days, not months.
• Duplicate detection across cases. When two customers report the same underlying problem within an hour, classic case management treats them as independent tickets. Our overlay clusters them and shows: “third report of the same issue in 40 minutes — probably an incident.” That feature alone has changed how fast we escalate real outages.
• Native domain language. The model knows what a “restaurant” means in our product, what a “deployment” looks like in our infrastructure, what a “plan downgrade” implies for billing. Salesforce never will.

The vendor still owns the database. We own the workflow again. The deepest moat any incumbent SaaS has is not the contract — it’s the calcified habits of the humans using it. The overlay breaks that. And once you own the workflow, swapping the database underneath becomes a future option you didn’t have before. You don’t have to commit to that. You just have it, quietly, as leverage.

Sun Tzu has a line I think about often when this topic comes up: the supreme art of war is to subdue the enemy without fighting. The mistake most “we should replace Salesforce” projects make is showing up to the fight. They start a war they cannot win, against an incumbent that has been winning these wars for two decades, and they lose, predictably, and the only legacy is that nobody will be willing to try again for another five years.

Extensibility: The Property Nobody Puts in the Evaluation Matrix

There’s one more pattern worth pulling out, because it changes how I now think about every new SaaS contract I evaluate.

Example four: Notion to Outline, and the Kanban built in a weekend

Notion at 300 seats is an expensive bet on a product most of your team barely opens. Per-seat pricing has a property that nobody flags in the original buying conversation but which becomes obvious about thirty months in: it scales with your headcount, not with your usage. At 300 people, you’re paying for 300 seats. Maybe 80 use Notion daily. Maybe 120 weekly. The rest log in once a month to find a link and close the tab. The vendor’s revenue is a function of how many humans you employ.

We moved to Outline. Open source, self-hostable, the licensing model doesn’t impose the seat tax the same way, the product itself is solid. A few weeks of work, careful planning around active documents, the usual migration theatre. By the end of the quarter, the company was on Outline.

If that was the whole story, this section would be boring. But the cost saving wasn’t actually the point. The point showed up later.

A team lead came to me asking for a Kanban view to manage tasks. The standard request. The kind that, in 95% of companies, kicks off a small bureaucratic process: evaluate Trello, Asana, Linear, Jira, ClickUp, Monday, Notion’s own Kanban view. Three weeks later there’s a deck, a recommendation, a procurement conversation, a security review, a fresh subscription, a migration plan, and a new tool that 80 people log into and 220 don’t.

I almost started that process out of habit, and then caught myself. Outline is open source. Outline has a plugin architecture. The data model is already there: documents with metadata, statuses, assignees. A Kanban is, at its core, a way of displaying data the system already has. The hard part of a Kanban isn’t the Kanban. It’s the data layer underneath. We had the data layer.

So I built it. As a plugin. Over a weekend. Not a polished SaaS-grade product — a Kanban that did exactly what our team needed, with the keyboard shortcuts we use elsewhere in the company, integrated with our auth, deployed in our infrastructure. The team lead used it on Monday. By Friday, three other teams asked to use it too. A month later it had quietly become how we do task management.

This is the moment, sitting on a couch on a Saturday afternoon writing Go code, that I realised the whole framework of “evaluate SaaS vendors for each missing feature” was a habit from a previous decade. The property nobody puts in their SaaS evaluation matrix, and which in 2026 quietly matters more than almost any other:

If our team needs a feature that doesn’t exist in this product, can we build it ourselves in a week?

For Notion, the honest answer is no. For Salesforce, no. For most SaaS, no. For Outline, for tools built on plugin architectures, for open-source platforms with real extension surfaces — yes. And that “yes” is worth more than most of the features in the comparison.

Six months after the Kanban, we had also built a customer-feedback view, a quarterly OKR tracker, a meeting-notes template with AI summaries inline, an internal-events tracker for the people team, and a slightly embarrassing number of smaller tools that solved real problems for individual teams. None of those would have justified their own SaaS evaluation. Each one would have correctly failed the procurement test — “we’ll evaluate, buy, integrate, and pay forever for a tool that only affects 15 people” is rejected by every CFO on earth. In a non-extensible world, those problems would have stayed unsolved. In an extensible world, they get solved on Saturdays, and your platform gets a little more native to how your company actually works.

What’s Left: The Moats That Actually Survive

Strip away the code moat and the know-how moat, and you’re left with a much smaller, much more specific set of structural advantages. These are the moats that will define which SaaS companies are worth a damn in 2030. There are roughly five.

Network effects, in the literal sense. The product is valuable because other companies use it, not because the software is clever. Stripe is the textbook case. The reason Stripe wins isn’t an incomparable API; it’s that every payment provider, banking partner, fraud network, and compliance regime has already integrated with it. You can’t build that yourself in a weekend. You can’t even build it in a decade.

Absorbed regulatory burden. The vendor takes the legal, compliance, and audit risk that the customer cannot or will not take on themselves. Payroll. Tax engines. Identity providers with the right certifications. Healthcare data processors. The product, in some sense, is the indemnification clause, and the software is the delivery mechanism. AI doesn’t dissolve this moat because AI doesn’t sign contracts and doesn’t get sued.

Genuinely complex computational infrastructure. Cloudflare’s edge network. Snowflake’s query engine. The kinds of systems where the hard part is years of research and physical infrastructure, not a couple of engineers with an LLM. These vendors are fine.

Real-time, mission-critical operation. SaaS that doesn’t just give you software but actively runs the system on your behalf, with on-call rotations, SLAs that mean something, and operational expertise you can’t easily hire for. This shades into “professional services with a software wrapper”, which is a category that’s about to get more valuable as the pure-software category gets less valuable.

Distribution as a moat. Being the default. Being where the buyer’s procurement department has a relationship. Being installed at every Fortune 500 already. The weakest moat on this list, but real.

What’s missing, conspicuously, is “the software is genuinely better than what the customer could build.” That moat is gone. It survives, residually, in places where the customer’s engineering team is junior or under-resourced. For any company with serious engineers and serious AI tooling, the software-quality moat has been priced down to roughly zero.

This is the part SaaS founders have to internalise. The product you’re selling — the code, the features, the workflow logic — is no longer the moat. It’s the entry ticket. Table stakes. The price you can charge is set by what your customer’s least-busy engineer can build over a weekend, not by what your team can build over a decade.

What SaaS Has To Become

If “the software” is no longer enough, what is?

The honest answer, the one most SaaS strategy decks are too polite to articulate, is that SaaS has to move from selling tools to selling outcomes. The unit of value has to change. The pricing model has to change. The sales conversation has to change. The product itself, in many cases, has to change.

A tool-selling SaaS says: “We give you software. You use it. You get results. We charge for access to the software.”

An outcome-selling SaaS says: “We take accountability for a result. We run whatever software we need to run to get there. You pay us when the result happens.”

The first is what almost every SaaS has been doing since 2010. The second is what survives.

Consider what this looks like. Today, you buy Sentry, and Sentry gives you a dashboard, and you hire engineers to look at the dashboard. An outcome-selling Sentry would say: “We will reduce your production error rate by 30% in the next quarter. We will configure ourselves, triage your errors, route them to the right person, and surface the ones that matter. You pay us based on error-rate reduction, not seat count.” Different product. Different business. Vastly more defensible — what you’re now buying is something AI alone can’t deliver: accountability, judgment, operational ownership.

This shift is hard for incumbents because their organisations, sales motions, and pricing models are structured around the tool-selling business. It requires giving up the seat-based recurring revenue safety blanket. It requires being actually responsible for outcomes, which most SaaS companies have spent years carefully avoiding in their contracts.

But the alternative is being slowly, then suddenly, replaced. By internal tools, by overlays, by plugins, by the next generation of AI-native vendors who don’t have a legacy business model to protect.

Bezos has a line worth dragging into the conversation. He’s said, in various forms, that your margin is my opportunity. He was usually talking about retail. The same principle is now playing out in SaaS. The margin SaaS vendors have been collecting on the code-and-know-how moat is the opportunity that AI-equipped internal teams are now taking back. Every overpriced seat, every renewal signed out of habit, every “we’ll evaluate alternatives next year” — that’s the margin, and it’s the opportunity, and somebody is going to capture it. If it’s not the vendor (by repricing toward outcomes) and not the customer (by building internally), then it’s a new entrant who’s structured for 2026 from day one.

The Real End, And The Real Beginning

The title of this piece was deliberate. The end of SaaS is not the end of paying vendors for software. It’s the end of a specific implicit contract: you give us money, we give you code your team couldn’t write and know-how your team didn’t have. That contract is dissolved. Not because customers got smarter, but because the supply curve of code and know-how shifted underneath the entire industry, and the people who were charging for what used to be scarce are about to discover that scarce became abundant when nobody was looking.

If you’re a SaaS buyer, the practical takeaway is to walk through your line items this quarter and ask, for each one:

1. Is this expensive and politically removable? → Cancel and build. (DataGrip pattern.)
2. Is this cheap but capability-limiting? → Replace anyway. The subscription was never the cost. (Sentry/Bugsnag pattern.)
3. Is this politically immovable? → Demote it. Build the overlay. (Salesforce pattern.)
4. Is this closed where every new need will mean a new vendor? → Replace with something extensible, then extend it yourself. (Notion/Outline pattern.)

Three out of four answers say do something different. The fourth — extensibility — is the one I most want you to think about the next time you sign a new contract. Stop optimising for the polished demo. Start asking whether, in eighteen months, when your team needs the feature that nobody thought of yet, you’ll be at the mercy of the vendor’s roadmap or writing a plugin on a Saturday.

If you’re a SaaS founder, the practical takeaway is harder. Stop treating your software as the product. Start treating it as the implementation detail. The product is the outcome. The pricing should follow the outcome. The sales motion should be about whether you can deliver, not whether your dashboard is prettier. And the part of your roadmap that talks about “AI features” should be replaced by a roadmap that talks about which currently-human steps in your customer’s workflow you’re going to take over with AI on your side of the wire, sold as a service.

What survives the transition is a healthier industry. SaaS that sells outcomes is more honest than SaaS that sells tools. SaaS that has to be responsible for results is harder to build, more expensive to sell, and more aligned with the customer’s reality than the seat-based, click-through, take-our-product-as-it-comes model that ate the last decade. The vendors that make the transition will be smaller in number, larger in market cap per company, and meaningfully more useful than what we have today. The ones that don’t will become line items that finance teams quietly cancel between renewal cycles, while their customer success teams keep sending emails asking what could possibly be wrong.

The customer is still there. They just stopped paying for what you were selling, because what you were selling stopped being scarce.

Code was never the moat. Know-how isn’t either. What you do with both, on behalf of your customer, is. The vendors who figure that out get to keep playing. The rest of them — and they are most of them — are going to be cancelled, wrapped, replaced, or quietly demoted to a database underneath someone else’s UI.

We’ve been writing plugins on Saturdays. It turns out that’s most of the moat.