Introduction
Recently, during a job interview, a candidate asked me a question I genuinely appreciate: "Are you open to using new tools? Do you have budget for that?"
My answer fits in one sentence: if we want to stay at the top of our craft, we need to use the best tools available. The tooling budget is not a cost line we reluctantly absorb; it is a condition for staying competitive. So the real question is never "do we invest in tools," but "how do we choose," and more importantly, when do we decide to build something ourselves rather than buy it.
At every stage of our prospecting work, we use multiple tools we have tested in every possible way. Over time, our decision process has settled into three steps. Here they are, with what each one means in practice.
Step 1: Test Everything, Fast and Thoroughly
I have to admit something: I have never understood resistance to new tools. That reflexive skepticism, the "we already have what we need," the "it's just another gimmick," before anyone has even tried. An opinion about a tool you have not tested is not an opinion; it is a bias. There is only one way to know whether something works for us: test it.
So our first instinct is to test everything. A new tool launches in a segment relevant to us? We try it quickly. Not a thirty-minute sales demo: a real-world test, on our actual campaigns, with our actual metrics running alongside.
And this is not naive technophilia; it is actually the opposite. This step eliminates a huge number of candidates, because a tool can look excellent on paper and be completely unusable in our context. We experienced this firsthand with the automatic call logging feature on one of our telephony platforms: connected to shared lines, it was logging every call twice, sometimes three times. From the outside, the feature worked perfectly. From our dashboards, it was inflating our stats by two to three times, enough to corrupt every decision we made. We turned it off. No product brochure would have shown us that; only a real-world test, numbers in hand, revealed it.
That is the real answer to skepticism: neither blind enthusiasm nor reflexive distrust. We test fast, we measure, and the tool is judged on our numbers, not its reputation. The skeptic and the technophile share the same problem: they both have an opinion before they have data.
The corollary is that you need to be able to measure. Without proper instrumentation of your activity, you cannot compare one tool to another on anything other than gut feel, and gut feel is wrong more often than not.
Step 2: The Full Cost, Dependency Included
Once a tool has passed the real-world test, the cost question comes next. And here, we look at three things, not just one:
- What it costs us: the listed price, but also the time spent on integration, training, and maintaining the connection with the rest of our systems.
- What it earns us: measured, not estimated. How many additional conversations, how much time saved, what improvement on the metrics that actually matter to us.
- The dependency risk: and this is the point almost everyone overlooks. How exposed are we if this product raises its prices, degrades its service, changes its terms, or shuts down?
That third point deserves attention. A tool can be profitable today and become a trap tomorrow, simply because we let our data, our processes, and our workflows get locked inside it. The true cost of a tool always includes the cost of getting out of it.
Step 3: Criticality, and the Build Question
Third filter: is this component critical for us? Critical means: if it goes down, our output stops or our quality collapses.
If the answer is yes, we systematically run one exercise: evaluate what building this component in-house would actually mean. Not necessarily to do it, but to know. Do we have the expertise? How long would it take? What do we gain in control, and what do we lose in focus?
Two possible outcomes:
- We can build, and the calculation from step 2 tilts in the right direction: then we build. That is what we did for our own calling infrastructure, when French regulation on number display (caller ID rules) made clean caller ID a full infrastructure topic in its own right. On something this central to a calling business, we wanted to own the component end to end.
- We cannot build, not the expertise, not the time, not the strategic fit: then we buy, but with one non-negotiable requirement: the ability to switch providers easily. Exportable data, replaceable integrations, no business logic locked inside the vendor.
The Cross-Cutting Principle: Never Critical and Captive at the Same Time
If I had to summarize our doctrine in one line, it would be this: a component can be critical, a component can make us captive, but never both at once.
A non-critical tool we depend on heavily? Uncomfortable, but manageable. A critical component we control or can replace? Healthy. A critical component we cannot exit? That is where companies really hurt themselves, and that is precisely the box we refuse to be in.
Three Examples from Our Business
Without naming any vendors, here is how this plays out in phone prospecting:
- Telephony. This is the core of the operation, so critical by definition. We work with several platforms in parallel rather than a single one, which lets us compare, switch, and never depend on one provider. And on the most sensitive layer, we built our own component.
- Data enrichment. Useful, but not critical in the strict sense: if one vendor drops in quality, we plug another into the flow. We think in terms of cascading, interchangeable providers, never a single source.
- The CRM. The classic captivity trap: this is where data accumulates. Our rule is to maintain our own internal data reference layer; the CRM is a working interface, not the vault. We have already switched CRMs, and that went smoothly for exactly this reason.
The Framework, Summarized
If you need to make a build vs. buy call, here is our method in reusable form:
1. Test in the real world, fast and thoroughly. No decisions based on brochures. Measure with your own metrics.
2. Calculate the full cost: what it costs, what it earns, and what it would cost to exit. Dependency is a cost, even when it never shows up on an invoice.
3. Qualify the criticality. If it is critical, run the build exercise, even if you end up concluding no. And if you buy a critical component, demand reversibility.
4. Never be critical and captive at the same time. Everything else is negotiable; this is not.
This framework does not always tell us what to do on the first pass. But it guarantees one thing: when we commit to a tool, or when we decide to build one, we know exactly why, and we know how we would get out.
