The wrong question and the right one
The question usually asked is whether the team can build a CRM. For most software houses the answer is obviously yes, which makes the question useless for deciding.
The right question is whether building a CRM is the best use of your engineering capacity over the next twelve to twenty four months compared with other work the same team could do.
Costs that are always underestimated
- Proper multi tenancy. Isolating tenant data sounds simple until you must guarantee that no query leaks across tenants, including in reports, exports, and search.
- Channel integrations. Every messaging channel has its own rules, rate limits, and policy changes. This is endless maintenance, not one time work.
- Reliable realtime. Conversations demand fast delivery with handling for dropped connections, message ordering, and cross device sync.
- Roles and permissions, which always grow more complex than the original design.
- Migrations and upgrades. Once production clients exist, every schema change becomes a risky operation.
- First line support. User questions land on your engineers unless a separate support layer exists.
When building is the right call
- Your core workflow is genuinely unique and is the main differentiator of what you sell.
- Compliance or data residency requirements cannot be met by anyone else.
- You intend to sell the product itself, not use it to serve clients.
- You have spare engineering capacity that is currently not generating revenue.
When using an existing platform is more rational
- Clients need a solution in weeks, not years.
- Your value is implementation and guidance, not the base code.
- You serve many clients with similar needs, so standardisation beats customisation.
- Your team earns more on client work than on internal product work.
The middle path people overlook
There is a third option: use a ready foundation while owning the source so you can extend it. This gives a starting point that already solved the tedious parts such as multi tenancy, authentication, and channel integrations, while leaving room to build what actually differentiates you.
Before choosing this path, answer the technical questions: how good is the code, how readable is it for your team, is there architecture documentation, and how does the upgrade path work once you have modified things.
Technical evaluation checklist
- Where tenant isolation is enforced and whether there is a second layer of defence.
- Permission model: role based, policy based, or mixed.
- Audit trail, especially for sensitive data changes.
- Data export capability. If your client cannot get their data out, you are selling a trap.
- Server resource requirements, which determine your cost per client.
- Ease of installation on client servers, which determines onboarding cost.
Frequently asked questions
Does using a third party platform mean losing control?
It depends on the ownership model. Subscribing to someone else service does place control outside you. Owning the code and running it on your own infrastructure is a very different position.
How do you calculate the break even point?
Compare two years of engineering cost to build and maintain against the cost of using an existing platform for the same client count. Include opportunity cost, the project revenue lost while the team builds.
Can this decision be reversed later?
Yes, but asymmetrically. Moving from an existing platform to your own build is much easier than the reverse, because by then you know exactly what clients need.
Next step
Write an honest twenty four month estimate including maintenance and support, then compare it against the project revenue the same team could deliver in that period. The numbers usually end the debate. See the full ownership option at WhatsCRM Hub.
