Build versus buy is a real decision, not a reflex. Build when the workflow is specific to how you work and your stack can support it. Buy when the capability is a commodity or needs specialist upkeep. Often the answer is both.
When a team decides it needs a capability — faster lead response, better routing, automated reporting — it usually frames the choice as “buy a tool or keep doing it manually”. That framing leaves out the option that is often best: building the capability inside the tools you already own and have already approved.
We call that stack-native. It is the practical form of the principle build inside the stack you already own. This article is about how to make the decision well, because stack-native is not always the right answer either.
What stack-native gets you
- Builds ship in days rather than quarters, because there is nothing to procure.
- Nothing new for IT, procurement or security to clear, because the tools are already approved.
- Adoption is automatic, because people keep working where they already work.
- No new contracts, logins or renewals.
- You own the system, which matters most on the day you would otherwise be negotiating an export.
A framework for the decision
Ask these questions about the capability you need:
| Question | Points towards building | Points towards buying |
|---|---|---|
| Does your stack already support it? | Yes, with configuration | No, or only with heavy workarounds |
| Is it specific to how you sell? | Yes — it encodes your process | No — everyone needs it the same way |
| What does it take to maintain? | Occasional adjustments | Constant upkeep: data, deliverability, compliance |
| Who will own it? | A named person who can document it | Nobody internally |
| How much data does it need? | Your own data is enough | It depends on large external data sets |
| What does leaving cost? | Low — it is yours | Acceptable, and clearly understood |
When to build
Build when the workflow is specific to your process and your existing tools can support it. Most of the six pipeline automations fall into this category: routing rules, follow-up logic, CRM hygiene and pipeline reporting are all closely tied to how your team works, and modern CRMs, inboxes and calendars can handle them.
The value of building here is not only speed and cost. It is fit. A workflow built around your process fits your process. A product built for everyone fits everyone approximately.
When to buy
Buy when the capability is genuinely a commodity, or when it depends on something that is expensive to maintain yourself:
- Large external data sets, such as company and contact data, which need constant refreshing.
- Email deliverability infrastructure, where staying on good terms with inbox providers is a specialist job.
- Compliance-heavy capabilities, where regulations change and keeping up is a full-time responsibility.
- Capabilities your stack simply cannot provide, however it is configured.
And buy when there is nobody to own a build. A stack-native system that only one person understands becomes a liability the day that person leaves. If you cannot name an owner and commit to documenting the build, a well-supported product is the safer choice.
Often, the answer is both
The most common good outcome is a hybrid: buy the specialist component, and build the workflow around it inside your stack. Buy a data enrichment service; build the routing and research that use it inside your CRM. The specialist part is maintained by specialists, and the part that encodes how you sell stays yours.
The questions to ask a vendor
- What would we need to build ourselves to get the same result with tools we already own?
- Where will our team actually use this — in a tool they already open, or a new one?
- If we leave in two years, what do we take with us, and in what format?
A good vendor will answer all three plainly. If they cannot, that tells you something.
Where to go next
The six pipeline automations lists what is typically built stack-native. Audit, sprint, scale explains how to build one workflow at a time. And the sales pipeline automation guide covers implementation in more depth.