Build in Salesforce vs Buy a Point Solution

The instinct to "just build it in Salesforce" usually wins the first meeting and loses the next eighteen months. Admins nod, the RevOps lead spots a clever workaround with flows and a custom object, and the budget request for a point solution dies on the vine. Six quarters later, nobody can explain why the lead-routing logic takes a week to change.

The opposite mistake is just as common: buying a $60K/year tool to solve a problem that two formula fields and a validation rule would have handled. Both errors come from the same place — treating "build vs. buy" as a gut call instead of a decision with criteria.

Here's the framework that actually holds up under pressure.

Start with the half-life of the requirement

The single most useful question is rarely asked: how long will this requirement look the way it does today?

Lead routing, territory carving, opportunity stages, forecast categories — these reflect how your company sells. They change when you reorg, launch a new segment, or move upmarket. Build them in Salesforce. The logic needs to live where your data lives, and the cost of ripping out a third-party router every time you redraw territories is brutal.

Conversation intelligence, email deliverability monitoring, intent data enrichment, e-signature, prospecting databases — these reflect how the market sells. The underlying tech evolves faster than any internal team can keep up with. Buy.

A practical test: if you can imagine the requirement looking meaningfully different in 18 months, lean build. If the requirement is a moving target driven by external forces (AI models, deliverability rules, buyer behaviour on LinkedIn), lean buy. You don't want your admin team chasing Gmail's latest authentication changes.

The hidden cost nobody models

Build-vs-buy calculations almost always understate the build side. The visible cost is admin hours. The invisible costs are what kill you:

• Opportunity cost on the roadmap. Every custom object your admin builds is something they're not building next quarter. RevOps backlogs are already a year deep at most growth-stage companies.
• Documentation debt. Custom flows built by the admin who left in 2024 are now load-bearing and nobody knows why they exist. This compounds.
• Upgrade fragility. Salesforce releases three times a year. Your custom build gets retested every time. A vendor absorbs that work for you.
• The "we already paid for it" trap. Sunk-cost reasoning keeps homegrown tools alive long after a $20K/year SaaS would outperform them.

Run the hypothetical honestly. Say your admin spends 40 hours building a sequencing tool in Salesforce, then 4 hours a month maintaining it. At a fully loaded admin cost of $120/hour, that's $4,800 upfront and $5,760/year in maintenance — before you count the AE hours lost to a worse UX than Outreach or Salesloft. Suddenly the "free" build is competitive with a paid tool only if the paid tool costs more than roughly $10K/year and delivers no productivity lift. Most don't clear that bar.

When the platform is genuinely the right answer

There are cases where building is the obvious call, and they share a profile:

1. The logic is proprietary to your GTM. Custom scoring that blends product usage signals with firmographic fit, written by your data team. No vendor knows your ICP better than you do.
2. The data already lives in Salesforce and shouldn't leave. Account hierarchies, opportunity splits, commission calculations. Pulling these into a sidecar tool creates a sync nightmare and a compliance headache.
3. The workflow is a thin layer on top of standard objects. A custom approval process for discounts above a threshold. A queue-based routing rule. A renewal alert. These are 2-day builds with near-zero ongoing cost.
4. You've already paid for a Salesforce SKU that covers it. Sales Engagement, Revenue Intelligence, CPQ — if you own the license, exhaust it before adding another logo.

The honest test for case 4: are you actually using the SKU, or did it come bundled and sit dormant? A dormant Sales Engagement license is not a reason to skip Outreach; it's a reason to either turn it on properly or stop paying for it.

When buying is the only sane move

Buy when the problem requires specialised infrastructure that you'd be insane to build:

• Anything touching email deliverability at scale. Warmup, inbox rotation, DMARC monitoring. This is a full-time engineering discipline.
• Conversation intelligence. Transcription accuracy, speaker diarisation, and the ML pipeline behind coaching insights are not weekend projects.
• Contact data and intent. You're paying for a data co-op and a crawl infrastructure, not software.
• Anything where the vendor's network effect is the product. LinkedIn Sales Navigator is the obvious one. You cannot rebuild the graph.

A useful gut check: if the vendor's core IP is data, infrastructure, or a network — buy. If the vendor's core IP is workflow logic you could describe in a one-page spec — consider building.

The decision framework, compressed

When the request lands on the RevOps desk, run it through four questions in this order:

1. Does the logic encode our specific GTM, or does it encode general market practice? Specific to us → build. General → buy.
2. Will the requirement change shape in the next 18 months due to forces inside our control or outside? Inside → build. Outside → buy.
3. What's the true total cost of ownership over three years, including admin hours, documentation, and upgrade risk? Model it honestly.
4. Is there a Salesforce SKU we already own that covers this? If yes, pilot it before evaluating outside vendors.

Teams that run this exercise consistently end up with a smaller, cleaner stack — and a Salesforce instance that reflects how they sell, not a graveyard of half-finished builds.

The takeaway

• Audit your custom Salesforce objects this week. Flag any built more than two years ago whose original owner has left. Those are the candidates for replacement or retirement.
• Before your next tool evaluation, list the Salesforce SKUs you already pay for. Confirm whether the capability you're shopping for is already sitting in your contract.
• Apply the half-life test to your next build-vs-buy decision. If the requirement will look different in 18 months due to external forces, default to buy. If it encodes your GTM, default to build.