Read this before you cancel HubSpot or Salesforce

This week HubSpot announced it is cutting about 660 jobs, roughly 7% of the company. Its CEO said HubSpot has shifted from building software that helps customers grow to delivering outcomes for them with AI.

A few months earlier, the healthcare company Curative cancelled a $600,000 Salesforce contract after its team built its own CRM with AI coding tools in about two months. Business Insider confirmed the cancellation; SalesforceBen has a summary. The Information described a 55-person property manager that replaced a Salesforce bill of roughly $100,000 a year with an app built with Claude Code that costs about $300 a month to run.

The conclusion everyone is drawing is simple: rent less software, build your own. It is half right.

Why companies are leaving

A CRM like Salesforce or HubSpot was designed for a million customers at once. That is its strength and its problem. To make it fit your business you configure it through the tools the vendor gave you: custom fields, page layouts, workflow builders, a proprietary formula language, an admin certification. Every company ends up bending its process to the product, or paying consultants to bend the product to the process.

That trade made sense when code was expensive. It doesn't anymore. Describing what you want to an agent in plain language and getting working software back is now faster than learning where the setting lives. A pipeline with your stages, a lead screen with the fields your team actually uses, a scoring rule your head of sales can read: an afternoon of work.

There's a second reason, and it's the one a commenter under the HubSpot news put best: managing your own system is not just about cost; it is about data ownership. When the data lives on the vendor's side, the vendor decides what your AI may do with it. In 2025 Salesforce changed Slack's API terms to forbid bulk export and the use of that data to train language models. It was your data. It came back one query at a time.

Seat prices make the decision easier still. Salesforce Sales Cloud Enterprise lists at $175 per user per month. HubSpot's Sales Hub Professional is $90 per seat per month, plus onboarding. For a fifty-person go-to-market team that is real money, spent largely on features nobody opens.

The trap on the other side

So the team opens Claude Code and asks for a CRM. The screens come together in an hour. The demo is great. Then the questions start.

Can the new SDR see every deal, including the ones with pricing that only leadership should see? What happens when the agent you gave database access to decides a cleanup is in order? Who changed this deal's stage on Friday, and what was it before? How do you add a field without breaking the records already there? Where do the API keys live? And when you connect ChatGPT or Claude to it, what exactly is it allowed to do?

These aren't edge cases. They are what you were actually paying Salesforce for, under the screens.

The risks are well documented. In July 2025 an AI coding agent on Replit deleted the production database of SaaStr's founder during an explicit code freeze, records for more than 1,200 executives, and then generated thousands of fake records in their place. Veracode's 2025 study of AI-generated code found models chose an insecure implementation in 45% of tasks. The Model Context Protocol specification itself warns that tools an agent can call represent arbitrary code execution and must be treated with caution. Even the companies that made the switch admit that maintaining what they built is the hard part.

Writing the CRM was never the hard part. Running it safely is.

What an ontology is

Palantir made the word famous. Its Foundry platform describes the ontology as an operational layer for the organization: the objects a business runs on, their properties and the links between them, together with the actions that may change them and the security that governs who can do what. Microsoft now ships the same idea in Fabric IQ, and the semantic-layer vendors are converging on it from the analytics side.

The important part is what an ontology is not. It is not a database schema. A schema says a deals table has a stage column. An ontology says:

• there is a thing called a Deal, which belongs to a Company and is owned by a Person;
• its stage changes only through an action called move stage, which checks the deal isn't already closed and records why;
• people in sales may run that action, people in marketing may read deals but not move them;
• every change is kept, with who made it, when, and what it was before;
• and all of this is described in plain language, so a person, an API client and an AI agent all see the same model and the same rules.

That last point is what makes ontologies matter now. An agent pointed at raw tables has to guess what the columns mean and can run any SQL it likes. An agent pointed at an ontology sees the business in its own words and can only do what an action allows.

It also makes the ontology the single source of truth. A Deal, its stages and what "won" means are defined once, and every screen, report, API client and agent reads that same definition. A rep's pipeline view, the finance report and the answer Claude gives the CEO can't drift apart, because none of them carries its own copy of the logic. And an agent has far less room to hallucinate: instead of guessing which of three status columns is current, or inventing a field that doesn't exist, it picks from the objects, properties and actions the ontology declares, each with a plain-language description. We've written about why agents get numbers wrong on raw tables and how a semantic layer fixes the counting half of the problem; the ontology does the same for the records and what may be done to them.

The building blocks you shouldn't write yourself

Here is the layer under every serious business app, and the reason so many homegrown tools stall after the demo. These are the parts we built SegmentStream Cloud's ontology to provide, so the code your agents write can focus on what's specific to your business.

Objects, properties and links. The things your business runs on, defined in code in your repository: leads, companies, deals, contracts, orders. Each property has a type and a plain-language description, and every link has a name in both directions, so "a lead is owned by a person" reads the same in the UI, the API and an agent's tool list.

export const Lead = entity("lead", {
  label: "Lead",
  description: "A person who asked for a pilot or joined the waitlist.",
  properties: {
    email: p.email({ unique: true, description: "The address they submitted." }),
    status: p.select(
      [
        { value: "new", label: "New", description: "Nobody has replied yet." },
        { value: "won", label: "Won", description: "They became a customer. Final." },
        // contacted, pilot, lost…
      ],
      { managed: true, description: "Where the lead is on the way to a pilot. Changed by actions." },
    ),
  },
  relationships: {
    owner: rel.one(User, { inverse: "ownedLeads", phrase: ["is owned by", "owns"] }),
  },
});

Actions instead of writes. Records change only through actions: named, typed, described operations with your business rules inside. There is no raw update path to misuse. An action can refuse ("won leads are final"), validate its input, change several records in one transaction and leave a note explaining why. People, scripts and agents all go through the same door.

Roles and permissions. Every read and every action is checked. A role is a list of what it may do, written like lead:read or lead:changeStatus; people, service keys and agents hold roles, and a call without the permission is refused before any code runs.

export const sales = role("sales", {
  description: "Works leads to a pilot.",
  permissions: ["lead:read", "lead:changeStatus", "lead:assignOwner", "note:create"],
});

History on every record. Each change is stored with the action that made it, who ran it and the values before and after. "Who moved this deal on Friday?" is a lookup, not an investigation.

Safe changes to the model. Your agent will keep adding fields and objects as the business changes. Additive changes apply automatically; renames keep their data; anything destructive, like changing a type or dropping a property, is refused while the running version stays live. Each migration is rehearsed on a throwaway copy of the database before it touches the real one.

Workflows. Some actions start work that takes longer than a request: email the owner when a pilot is signed, enrich a new lead overnight, escalate a deal that has been stuck for two weeks. These run as durable workflows that survive restarts and retry on failure.

A UI, an API and an MCP gateway over the same model. Because every object, property and action carries a description, the ontology can generate the surfaces around it. Your team gets screens to browse and edit records. Other systems get a typed API. Agents like Claude and ChatGPT connect through one MCP gateway, where each action becomes a tool and each agent sees only the tools its role allows. Nobody hands an agent a database password.

Isolated infrastructure and secrets. Every workspace runs on its own infrastructure, with its own database, warehouse and secret store, and credentials never sit in your code. The model, the actions and the apps live in your repository, under your review, in code you can read and take with you.

The middle path

Put those pieces together and the choice stops being binary.

You don't have to pay for a suite designed for a million other companies, and you don't have to hand-roll security, permissions and versioning in an app an agent wrote over a weekend. Your agents write what's specific to you: the objects, the stages, the scoring rules, the screens your team wants. The ontology provides everything those need to run safely.

It also changes how the system evolves. In a rented CRM, a new requirement means a ticket to an admin or a consultant. Here it means asking your agent: add a "renewal date" to contracts and email the owner 60 days before. The agent changes the model and the action in your repository, you review the pull request, and the platform checks the change against the data before it goes live.

What it looks like in practice

The code in this article isn't a mock-up. It is abridged from the starter template every SegmentStream Cloud workspace begins with: a lead tracker for website sign-ups. The website's API key holds one role, intake, which may run exactly one action, submit lead. It can't read the leads it created, let alone change them. The sales team holds sales, which may read leads, move their status and assign owners, but not delete them. An agent connected on a salesperson's behalf gets the same rights and no more. Every status change is kept with who made it, and a won lead can't be reopened, because the action says so.

Before you cancel your CRM

If you're considering building your own, ask these questions about whatever you build it on:

1. Who can see what? Are permissions checked on every read and write, for people and agents alike?
2. How do records change? Through named actions with business rules, or through any SQL that reaches the database?
3. What happened last Friday? Is there a history of every change, with who made it?
4. What happens when the model changes? Can a field be added or renamed without breaking existing data or downtime?
5. How do agents connect? Through one governed gateway with per-role tools, or with database credentials?
6. Who owns it? Is the code in your repository, readable by your team and yours to keep?

If the answer to most of these is "we'll build that later", you haven't replaced Salesforce yet. You've replaced its screens.

Moving off HubSpot or Salesforce? See how a migration works: our engineers write the import, both CRMs run side by side, and teams switch one at a time. Or start a pilot: our engineers model your business, build the first app with your team, and hand you the repository. Or read how SaaS becomes company context and why your agents need both a semantic layer and an ontology.