Before comparing options, run one test. If a vendor handed you their product free tomorrow, fully configured, would your number move?
If the answer is no, the problem is not the tool, and this decision is the wrong one to be making.
When to buy
Buy when the problem is standard, the product is mature, and your process can bend to it without breaking anything that makes you different.
Clear buys: email sending infrastructure and deliverability, CRM, calendar and scheduling, payments, enrichment data sources, calling infrastructure. These are solved, competitive markets where your version would be worse and cost more.
The question to ask a vendor: what percentage of customers use this without customisation? A high number means the product absorbed the complexity. A low number means you are buying a platform and building anyway.
When to build
Build the part that is actually yours. Usually three things:
- Routing logic. Which lead goes to which person, branch or queue, under your rules.
- Qualification. What makes a lead worth a human hour in your business.
- The attribution chain. What gets stamped where so you can walk from money back to source.
These encode how your business works. A product that imposes its own version quietly asks you to change the business to fit the software.
Build on an automation layer rather than from scratch. The point is owning the logic, not owning the plumbing.
When to hire instead
This is the common case and the least discussed one. You own the tools. They are half configured. Nobody can say who owns them or when they last broke.
Adding another product to that situation produces the same result with a new logo and a new invoice. What is missing is a person accountable for the outcome, with the decision rights to change things.
The costs each option hides
Buying hides: integration work, data migration, admin time, the annual renewal that is easier to sign than to question, and the process you bend to fit the product.
Building hides: maintenance forever, the bus factor, and the version that only one person understands. What has no error route fails in silence, and homemade systems are where that happens most.
Hiring hides: ramp time, your own team's time answering questions, and the handover if it ends.
A decision sequence that works
- Write down the process as it actually runs. If you cannot, stop here, because automating a process nobody can describe makes it confusing faster.
- Mark the steps that are genuinely specific to your business. Usually fewer than expected.
- Buy everything that is not marked.
- Build only the marked parts, on top of what you bought.
- Name one person accountable for the whole thing working, before any of it ships.
Step five is the one most often skipped, and it is the one that determines whether any of the first four matter.
The people who own this
MitHub publishes open profiles of GTM and forward deployed engineers with their work written out: what they built, on top of what, and who operates it now.