Before buying another platform, ask what the tools you already pay for could do if someone built on them. The answer is usually: most of it, faster, and without an adoption problem.
When a problem shows up in a marketing or sales team, the reflex is to buy something. A new platform for lead routing. A new tool for follow-up. A new dashboard for reporting. There is always a vendor with a demo that makes the problem look solved.
Sometimes that is the right call. More often, the capability already exists inside the tools you pay for — the CRM, the inbox, the calendar, the ad accounts — and nobody has built on it.
The hidden cost of another platform
The price on the proposal is the smallest cost of a new tool. The bigger ones arrive afterwards:
- Procurement and security review. In any organisation of size, a new vendor means contracts, data processing agreements and security questionnaires. That is weeks or months before anything is built.
- Integration. The new tool has to talk to the CRM, which it will do imperfectly, which creates a new place for data to drift out of sync.
- Adoption. This is the real killer. A new tool asks people to work somewhere new. Reps already live in their inbox and their CRM. Every additional login is a small tax, and small taxes are how tools become shelfware.
- Renewal and lock-in. Once your process runs on someone else’s platform, leaving means an export project, and export projects are always larger than anyone estimated.
What building in your stack gets you
Most modern CRMs, inbox and calendar suites and ad platforms have serious automation capability built in: workflow rules, triggers, scripts, APIs and integrations that teams have never switched on. Building there has four consequences that compound:
- Days, not quarters. There is nothing to procure. You start with the access you already have.
- Nothing new to clear. No new vendor for IT, legal or security to approve. The tools were already approved.
- Adoption is automatic. Reps keep working exactly where they already work. The automation shows up inside their day rather than asking them to visit it.
- You own it outright. No vendor lock-in and no negotiation on the day you want to change direction. The system is yours.
When buying genuinely is the right answer
This is a principle, not a religion, and it would be dishonest to pretend the answer is always build. Buy when:
- The capability really does not exist in your stack and cannot reasonably be built there.
- The vendor maintains something expensive to maintain yourself — large third-party data sets, email deliverability infrastructure, compliance-heavy capabilities where staying current is a full-time job.
- Your scale requires specialist infrastructure that a general-purpose tool will not handle well.
- You have nobody to own the build. A stack-native system that only one person understands is a liability the day that person leaves. If nobody can own and document it, a well-supported product may be safer.
The point is to make it a genuine decision rather than a reflex. That decision is laid out in more detail in build vs buy, and stack-native.
Three questions before you sign
- Can the tools we already own do this? Ask someone who knows those tools deeply, not the vendor selling the alternative.
- Where will people actually use it? If the answer is “in a new tab they have to remember to open”, budget for an adoption problem.
- What happens when we want to leave? If nobody can answer that clearly, you are not buying a tool. You are buying a dependency.
Where to go next
The six pipeline automations is a list of what can typically be built inside an existing stack. Audit, sprint, scale describes how to build them one at a time without a migration project. And AutomateSales is the practice built on this principle.