The Short Answer
An integration connects the CRM you already rent to the rest of your tools. A build creates the CRM itself: a database designed around your process, permissions enforced at the data layer, and full ownership of every record. I advise on and build both. Rima Taha, Technology and Digital Innovation Advisor, has spent 17+ years working with governments, enterprises, and agencies across EMEA, and the pattern is consistent: organisations default to integration because it feels smaller, when the honest question is whether the CRM they are integrating deserves to stay.
Integration is the right choice when your current platform genuinely fits: the pipeline stages match how you sell, the licence cost is proportionate, and the data lives where your regulators and your board are comfortable with it living. A build is the right choice when you are working around the platform instead of with it, paying per seat for users who only need to read records, or holding sensitive client history on infrastructure you do not control. The full decision framework, tiers, and pricing are on the Automation & Software Intelligence page; this article is the reasoning behind it.
What an Integration Buys
A good integration removes retyping. Forms feed the CRM directly, the CRM feeds the email platform, closed deals raise invoices, and reporting pulls itself together without anyone exporting a spreadsheet. When the underlying platform fits, this is real leverage at modest cost, and it is often where an engagement should stop.
What an integration cannot do is change the platform's nature. The schema is still the vendor's schema. The permission model is still whatever tiers the vendor sells. The records still sit in the vendor's cloud under the vendor's terms, exportable through whatever process the vendor allows. Every workflow you wire up makes the platform harder to leave, which is precisely why vendors encourage integration so warmly.
"Every workflow wired into a rented CRM is leverage for you and lock-in for the vendor. Both are true at once."
Rima TahaWhat a Build Changes
A built CRM inverts the relationship. The data model is designed around how your organisation actually works: your stages, your fields, your qualification logic, not a template you bend to fit. Access follows your org chart, enforced with row-level security at the database rather than by interface convention. Capture, routing, and reporting are built against that schema as first-class citizens rather than bolted on through connectors.
Ownership is the structural difference. The database is provisioned in your organisation's accounts from the first day of the build. When the engagement ends, you keep the database, the schema, and the code. There is no per-seat licence scaling against your headcount, no export process to negotiate, and no point at which continuing to operate the system requires continuing to pay the person who built it.
The Decision Test
| Signal | Points to integration | Points to a build |
|---|---|---|
| Process fit | The platform's pipeline matches how you actually work | Your team maintains spreadsheets alongside the CRM to cover what it cannot model |
| Licence economics | Seat count is small and stable | You pay full seats for users who only need read access, and headcount is growing |
| Data sensitivity | Client records are low-sensitivity and jurisdiction is not a concern | Regulated, governmental, or competitively sensitive data sits on infrastructure you do not control |
| Permissions | Everyone can reasonably see everything | Teams, regions, or entities must be isolated at the data layer |
| Horizon | The tool is tactical and replaceable | The CRM is core operating infrastructure for the next decade |
Two or more signals in the right-hand column is usually the point where a build stops being the ambitious option and becomes the economical one. One signal alone rarely justifies it; a good systems review exists precisely to make that call honestly, including recommending against a build when integration is enough.
Five Questions to Answer Before You Decide
The table gives you the signals. These questions help you apply them to your own organisation, ideally with the people who use the CRM every day in the room.
- Who edits and who only reads? Count the people who change records and the people who only look at them. If most users are readers, per-seat pricing is the first place to look.
- What lives in spreadsheets? Every spreadsheet kept next to the CRM is a field or a process the platform cannot hold.
- Which records are you uncomfortable seeing on someone else's servers? Name them. If the list is long, ask where they are stored and who can reach them. The permission architecture article shows what controlling that looks like.
- What would leaving cost? If the vendor doubled the price or changed its terms next year, how many workflows would have to be rebuilt, and how would you get your records out?
- Who runs the system when the project ends? Whichever option you choose, a named person on your side should be able to operate it without calling the builder. The same test applies when hiring a firm for custom enterprise software.
The Middle Path: Integrate Now, Build Later
If the signals are mixed, you do not have to choose permanently. Integrate first and keep a regular export of your records so that moving remains possible. Write down the stages, fields and routing rules your integration depends on. That document becomes the specification for a build if you ever need one. Review the five signals every twelve months, or whenever headcount, regulation or the vendor's terms change.
The Cost Logic
Key Insight
Subscription pricing scales with headcount. Build pricing scales with scope. The moment your organisation grows faster than your process complexity, renting becomes the expensive option, permanently.
A subscription CRM is cheap to start and expensive to succeed with: growth adds seats, seats add cost, and the cost never converts into an asset. A build is the reverse: a fixed, scoped fee agreed in writing, from 8,000 euros for a CRM Foundation, that produces infrastructure your organisation owns outright. Running costs do not scale against your headcount, and the follow-on work, capture pipelines, permission architecture, and reporting, compounds on a foundation you control.
FAQ
Related reading: When Not to Automate, and What to Look for When Hiring a Firm for Custom Enterprise Software.
Not sure whether to build or integrate?
A systems review establishes which side of the line your organisation is on before any build decision is made.
Request a Systems Review →
