Building a CRM from scratch: start from friction, not fields
In short. You don't design a custom CRM by starting from fields and pipelines. At Axend we didn't even design it: it grew out of the automations I was building wherever the team was losing time and leads. I owned the priorities, the CTO wrote the code. The result is axendcrm.cloud.
Why a proprietary CRM instead of HubSpot?
We didn't decide it on a whiteboard. We got there. I started with automations on the handoffs where the team was losing time, then a dashboard to see the numbers in one place. At some point we had something useful in our hands that wasn't a CRM yet, but looked like one. That's when we decided to build our own, around our own needs.
The CTO wrote the code. I decided the priorities, what was P0 and what could wait, based on what the team needed. And I gave input on where to use AI and how each feature should fit into everyday work.
That's why it worked: every piece already existed as the answer to a problem before it became a feature.
For most companies it's still true that HubSpot or Pipedrive are enough. A custom CRM makes sense when you get there this way: you already have the automations, you know which problems they solve, and someone can maintain the product over time.
Where do you start, if not from the fields?
The natural reflex is to draw objects, stages and fields. It's the easiest work and the least useful: a field changes in an afternoon. What doesn't change in an afternoon is the team's habit of working outside the CRM.
The starting point is the work, not the schema. You look at where things get stuck: a lead nobody picks up, a missed call nobody follows up, a quote rebuilt by hand, a commission calculated on a separate sheet. Every blocker becomes a line in the backlog.
Which automations came out of that?
| The problem it solved | Automation in the CRM |
|---|---|
| New leads with no owner, or assigned to the wrong rep | Automatic routing and assignment to reps |
| Missed appointments nobody followed up | No-show handling with scheduled re-contact |
| Reps walking into calls with no context | Pre-call brief ready before the call |
| Follow-ups written from memory after the call | Call recording, follow-up email and automatic reminders |
| Quotes and proposals rebuilt by hand | Quotes and proposals generated from the deal |
| Commissions calculated outside the CRM | Sales commissions calculated inside the CRM |
| Data scattered across Apollo, Instantly and the CRM | Integration into a single source of truth |
| No single view of the numbers | Dashboard |
None of these is an original feature. The difference is that each one answers a problem the team had already named, so nobody had to be convinced to use it.
How do you decide the order?
By the cost of the friction, not by how easy it is to build. Three questions: what does it cost each time it happens, how many times a week does it happen, who pays the price.
In practice it was my P0 list: what the team needed at that moment went in first, not what was nicest to build. What loses leads beats what saves time. I wrote about it in May, in "What commercial friction really costs you".
How do you make sure the team actually uses it?
A CRM gets used when it's the place where the work happens, not the place where you log it afterwards. The pre-call brief and the automatic follow-up pull the rep into the CRM because it pays off for them, not because someone is checking.
The rule I use: every time a feature asks the rep for one more piece of data, it has to give them something back right away. A mandatory field with no return is new friction, and you built it.
What would I do differently?
I'd measure adoption from day one. I often asked the team what they needed, but I didn't track which features were actually being used. A feature that barely gets used is a signal: either the problem wasn't the right one, or nobody explained why it pays off. In the first months I'd track usage feature by feature and push adoption wherever it lags.
When is it done?
A CRM is done when the team stops keeping parallel spreadsheets. As long as a "support" Excel file exists, there's friction the system hasn't absorbed yet. It's the same principle as "You don't have a lead problem. You have a system problem": work that lives outside the system is the system that's missing.
- Custom CRM or HubSpot?
- For most SMEs, HubSpot or Pipedrive. Custom makes sense when the process has steps a standard CRM only covers with workarounds, and someone can maintain it over time.
- Which automation should you start with?
- The one that loses leads. Usually that's lead assignment to reps or handling missed appointments.
- Do you need a developer to automate your CRM?
- For a proprietary CRM, yes. To automate an existing CRM, a tool like n8n connected to its APIs is often enough.
- How much does it cost to build a CRM from scratch?
- The real cost isn't the initial build, it's the maintenance. A custom CRM has to be treated as a product, with someone owning its roadmap.
You don't draw a CRM. It accumulates, one friction solved at a time, until the team has no reason left to work anywhere else.
Is your team still keeping a spreadsheet next to the CRM?
Start with the pre-diagnosis