At BookPrint I set HubSpot up for myself and was an accredited HubSpot marketer. I used the free sales CRM and paid for the marketing automation tools. I built custom forms in the CRM, and when I tried to feed the form responses into the marketing automation I couldn't, unless I upgraded to the paid CRM, so I exported my own data out of HubSpot forms through Zapier in order to import it back into HubSpot marketing. I don't want to hate on HubSpot; I'm picking on it because I know it. The frustration was never a missing feature. It came from the underlying data structure and the business model, and you see the same pattern across the legacy all-in-one providers.
The debate about software platforms is usually about features. The more important conversation is about architecture: where the source of truth lives, and how it is derived.
Two kinds of software
A workflow app is a highly polished filing cabinet. People type records in, the software keeps them tidy, and when a customer's status changes from Active to Churned the old status is overwritten. The record is right about today, and the system has lost the context, the history and the why. HubSpot, the project boards and most of what a business calls its system are, structurally, still just tables.
A data engine records every change as an event and never overwrites one. Because nothing is lost, you can ask it to replay a customer's state on any given day, and it can answer. That history is not a nice extra. It is the strict prerequisite for deploying AI or serious analytics, because a model that only sees the present is guessing at how the business got there.
People still need the filing cabinet. Someone has to enter the unstructured thing, make the subjective call and review what the system holds. Those jobs are done through a CRUD interface, the screens that create, read, update and delete records, and that does not go away. What changes is that the interface is decoupled from the master database: a lightweight control plane that reads from the core and writes to it, never the core itself.
The all-in-one dilemma
The promise of the all-in-one is seamless integration, because everything sits under one roof. As a business gets more complex that stops being true, in three ways.
Data lock-in. When the primary data layer lives inside a vendor's ecosystem, every new interaction and every historical record is held on their terms, and porting it out becomes cost-prohibitive. The data is yours on paper and theirs in practice.
Forced shapes. A vendor's data model rarely matches how the business actually runs. An ERP and an MRP, the systems that run the accounts and the factory floor, need completely different data shapes from a CRM, and forcing all three into one vendor's model means running disconnected systems in parallel and fighting to keep them in sync. My form data taking a trip through Zapier was a small version of the same fight.
Pricing leverage. Every new feature, every data expansion and every AI capability is priced at the native premium rate, because plugging in a specialised tool is not an option when the architecture is closed. The vendor's data structure and the vendor's business model are the same thing. Ask where a won deal goes next follows the same leverage into pricing by the credit, and puts each legacy CRM through the filing-cabinet test.
What it looks like on a Tuesday
A supplier emails to say a shipment is delayed. In the filing-cabinet business a person updates a date in a spreadsheet or the CRM, checks by hand which manufacturing orders are affected, and emails the plant manager. In the data-engine business the supplier's system logs a delay event to the core, the core maps the delay to the affected products, recalculates the inventory risk, and alerts the plant manager with recommended schedule changes. Same event, same people, and only one of those versions depends on somebody remembering every order the shipment touches.
You buy a new HR tool. In the filing-cabinet world you pay a developer to build a bridge between it and payroll so the two can share employee data, and every tool after that adds another bridge, until the integrations are a spaghetti network of point-to-point connections. In the data-layer world you define what an Employee is once, in the core. The new tool points at that definition and reads and writes to it, and adding or removing software becomes plug and play.
With a real core, a cascading update is literal: change the entity once and everything that reads it changes with it.
How to get there without a big-bang decision
The move toward an owned core does not start with a platform purchase.
First, build a simple internal CRUD system whose only job is to digitise and formalise the decision and information workflows the business already runs. Not to improve them yet. To write them down in a form a machine can hold.
Second, improve those workflows iteratively, updating the simple system as you learn what the business actually decides and in what order.
Third, build the modern data layer that the ERP, the MRP, the CRM and every rented tool read from and write to. By then you know the shape of your own entities, because you have been recording them.
Fourth, automate. Bring in outside expertise or use internal resource at any of the four steps.
The simple CRUD stage is the check. It digitises what the business actually decides before anything is built on top of it, which is the same discipline as validation on Traffic Plus Offer: find out what is true before you spend money scaling it.
Rent the edge as edge
Own the core: map the business's entities, its products, suppliers, customers and jobs, into a central data layer that belongs to no vendor. Rent the edge: treat the applications as interchangeable execution engines that read from that layer and write back to it. CRMs, marketing tools and the AI models are all edge.
A few of the articles on this site are that rule applied to real tools. Connecting Capsule CRM to an AI assistant found a CRM with no history of its own, and a short log that writes one down so an AI's confident wrong edit can be undone. Free appointment scheduling for Capsule keeps the booking record and the ad that caused it in the owned system and lets Google's free page do the slot picking. The record belongs to you; the slot picker can belong to anyone.
The privacy angle
Companies holding large datasets are looking at what those datasets are worth to AI providers and as enrichment data, and the all-in-one that holds your core may be pricing it. On 25 June 2026 HubSpot announced that, under terms effective 1 July, accounts using its enrichment would contribute business contact details, employer information and email deliverability signals to a shared dataset behind a new prospecting feature, Contact Discovery, and the way out was to turn enrichment off. It withdrew the plan on 5 July 2026 after a backlash, and said new enrichment capabilities using customer data would be fully and transparently opt-in. Its Product Specific Terms, updated 16 September 2026, still say that the enrichment data a customer sends to HubSpot may be copied into its commercial dataset. The full read of that episode, including the correction it needed, is on this site. Owning the core is not only about what you can do with your data. It is about who else can.
The same shape everywhere
The System Seed is the knowledge half of a company's source of truth: what it knows, how it sounds, what is verified. The core is the data half. A seed sitting on top of a vendor's database is a rented core, and the vendor decides what history you keep and who else gets to read it. Own both halves. Rent everything else, and rent it as an engine you could replace on a Tuesday.
Models are the edge too, and the advantage any one of them gives closes like every platform window before it; the arbitrage window is about what outlasts it. The Trust Algorithm draws the same shape around attention rented, proof built and reputation owned: the things you rent never compound, and the thing you own is the only one still working while you sleep. The 4-Quadrant loop runs on both layers, and it only produces its value when both are yours.