Why I stopped using HubSpot and built my own CRM from scratch
I used HubSpot for years across multiple ventures. I understood it well. When I built Ektie, I made the deliberate choice to build the CRM from scratch instead. Here's the reasoning — and what I learned about why AI-native architecture actually matters.

I used HubSpot for years. I've set up CRM pipelines, built sequences, configured workflows, run reports. I know the product well. When I started building Ektie, the obvious choice would have been to build on top of HubSpot — use their API, operate their CRM, integrate with their sequences. I chose not to. Here's why.
What is HubSpot actually designed for?
HubSpot is a well-built product. The problem is what it was designed for. Every object, every field, every workflow trigger, every activity log in HubSpot was designed around the assumption that a human would initiate and complete each action. A human creates the record. A human logs the call. A human moves the deal stage. A human triggers the sequence enrolment.
When you want an AI agent to do those things, you're fighting the data model. The agent isn't a first-class actor in HubSpot — it's a user making API calls that look like a human logging in.
What does an AI-native CRM actually need?
Every field needed agent-readable and agent-writable permissions. Not just read/write API access — a structured permission model that the agents use to understand what they can do with each field. HubSpot doesn't have that concept.
Every action needed to carry agent attribution. When Morgan updates a contact record, the record should know Morgan did it, when, and why. This isn't "created by [API key]". It's structured agent attribution that the rest of the system can reason about. HubSpot's activity logs don't support this.
Workflows needed native AI service calls. Not Zapier-based integrations — first-class AI actions inside the workflow runtime. HubSpot's workflow actions are a closed set. You can add webhooks, but you can't add native AI service calls as primitive workflow steps.
How we built it differently
Every object type (Contact, Company, Deal, custom objects) exposes typed JSON schemas. Every field has a definition that includes agent-readable and agent-writable flags. Every record write carries a created-by and last-touched-by agent reference. Every workflow action includes native AI service calls as first-class options.
This is what AI-native means. Not "we added AI features". The data model was built from the first commit for agents to operate as the primary actors. The default assumption is that an agent is acting, not a human.
What changes when agents maintain the CRM?
In HubSpot, if nobody logs the call, there's no record of the call. In Ektie, every action an agent takes is automatically logged, attributed, and timestamped. The CRM maintains itself because the agents who are doing the work are also maintaining the records as a byproduct of the work.
The data quality problem companies have with their CRM isn't a discipline problem. It's an architecture problem. When the data model assumes humans will maintain it, data quality depends on human discipline. When the data model assumes agents will maintain it, data quality is a byproduct of agents doing their jobs.
That's the whole thing. That's why I built the CRM from scratch instead of using HubSpot.