Build vs. Buy: A CSM’s Guide to Navigating the Conversation
A practical guide for Customer Success Managers. How to have a complete, confident build vs. buy conversation with customers who are considering going it alone.
Not A New Conversation, Just Changed
The build vs. buy objection is not new. What’s new is who’s having it.
Two years ago, a customer saying “we’ll just build this ourselves” implied a serious engineering commitment, a full team, a multi-quarter roadmap, real resource allocation. That threshold kept a lot of half-baked build plans off the table before they started. Today, AI coding tools have collapsed the perceived barrier to entry. A technically-competent founder or a CS Ops person with some engineering exposure can ship a V1 in weeks. The conversation now shows up earlier, with more confidence, and from customers who would have never seriously entertained it before.
That’s not a problem. It’s an opportunity, if you know how to navigate it.
The CSMs who struggle in this conversation are the ones who treat “build” as a single objection to rebut. The CSMs who win it are the ones who understand what the customer actually means when they say they want to build, and who can hold both the technical and financial picture at the same time.
This guide is designed to give you that edge. 🔪
📂 Visit tomaswilliams.com for a downloadable cheat sheet to help CSMs navigate these conversations with customers.
Step One: Find Out Which Conversation You’re In
Before you say anything else, ask one question:
“When you say build, are you thinking about an internal engineering project, or are you thinking about using AI tools to approximate this?”
The word “build” is doing a lot of heavy lifting in these conversations, and it can mean three fundamentally different things. Each one leads to a different discussion with different risks and a different response strategy.
The Classic Engineering Build — An internal engineering team is tasked with designing and building a homegrown tool from scratch. Full ownership, no vendor dependency, built to spec. This objection requires you to make the invisible visible: what looks like “building a dashboard” is actually a commitment to building and indefinitely maintaining multi-layered technical infrastructure.
The AI-Assisted (”Vibe Coding”) Build — A technical founder or ops person uses AI coding tools to ship a V1 in weeks. The V1 often works. That’s the problem. Success at V1 creates the illusion the hard part is done; when in reality, the hard part (maintaining, extending, debugging, and owning a live system a team depends on) is just beginning. A working prototype is not a product.
The AI + CRM Substitution — The team concludes they don’t need a purpose-built platform if they can just point an AI tool at Salesforce or HubSpot. This isn’t really a “build” in the traditional sense, it’s an assumption that a general-purpose AI layered on top of existing tools can approximate what a purpose-built platform does. It can’t, and there are specific reasons why. More on that below.
The clarifying question matters because treating all three as the same objection puts you at a disadvantage. A response tailored to a classic engineering build lands flat against the AI substitution argument. Know which conversation you’re in before you respond to any of them.
Step Two: Name the Two-Track Structure
Once you know which type of build you’re dealing with, introduce framing before you start presenting information:
“I want to walk you through two lenses on this separately, the technical reality and the financial reality, and then show you how they connect. Most teams I talk to are only fully seeing one side.”
This does two things. It signals that you’re about to bring something complete, not just a rebuttal. And it gives structure to a conversation that can otherwise sprawl.
Most customers arrive at this conversation from one direction only, either the financial side (”we could build this for less”) or the technical side (”our team can handle it”). Your job is to ensure they see both tracks and understand how they compound.
The Technical Reality: What “Build” Actually Means
For the classic engineering build and the AI-assisted build, the conversation almost always underestimates scope. Here’s what needs to be built and maintained; not once, but indefinitely.
Data infrastructure — A tool needs to pull from a CRM, product analytics, billing systems, and support platforms. That means building pipelines for every source, handling API rate limits, managing schema drift when upstream tools change their data models, rotating auth tokens, and building backfill logic when syncs fail. “Connecting to Salesforce” is the beginning of the sentence, not the end of it. The ongoing cost of keeping integrations working as external systems evolve is consistently the most underestimated part of any build project.
Scoring and automation engines — A health score is not a formula in a spreadsheet. It’s a dynamic, multi-source system with versioning, audit trails, and the ability for non-technical CS operators to adjust inputs without filing an engineering ticket. Playbooks aren’t scheduled jobs, they’re event-driven workflows with conditional branching, time delays, and re-entry logic. The gap between “a health score” and “a health score your CS Ops team can actually manage” is enormous. It’s entirely invisible until you’re already building.
AI architecture — Embedding AI into a CS workflow requires a retrieval-augmented generation (RAG) system that indexes customer data so the model can retrieve only relevant context, rather than processing everything each time. Without it, token costs become unmanageable at scale. On top of that, teams need prompt versioning, output validation, and the internal expertise to maintain AI systems as underlying models change.
Security and compliance — The average custom application contains 26.7 serious vulnerabilities. For enterprise-facing companies, SOC 2 Type II compliance is eventually non-negotiable, and it cannot be retrofitted cheaply after V1. For customers in regulated industries, building internally may not be a viable compliance path at all.
The bus factor — This is the risk that critical system knowledge lives with one or two people, and when one of them leaves, that knowledge walks out with them. Documentation helps but doesn’t solve it: there is always implied, experiential knowledge lost when the person who built something moves on. A team that set out to build a dashboard has effectively become the product and platform team for a mission-critical tool, with no dedicated roadmap, no PM, and no documentation culture.
Frame to keep in mind: Industry data shows only 29% of large custom software initiatives are delivered successfully, and 35% are abandoned entirely. When an engineering team says “we’ll build this,” they are implicitly betting they’ll be in the top third, with no structural reason to believe they will.
The Financial Reality: Where the Model Breaks Down
The most common error in any build vs. buy financial model is treating the build cost as a one-time line item. The data says 78–80% of a software system’s total lifetime cost occurs after initial launch.
Ongoing maintenance runs at 15–20% of the initial build cost every year, indefinitely. A $300K build generates $45–60K in annual maintenance before a single new feature is added. That figure tends to grow, not shrink, as integrations multiply and technical debt accumulates.
Compliance costs — SOC 2 Type II costs $50–200K to initiate and $20–100K per year to maintain. This tends to be treated as something to “figure out later.” Later is when it becomes most expensive.
The integration tax — The perpetual engineering cost of keeping third-party connections working. Every system a CS tool depends on will change its API. With a purpose-built platform, that cost is distributed across hundreds of customers. With a homegrown tool, your company absorbs it entirely and alone.
The productivity gap — During the 6–12 month build window, the CS team operates without health scores, playbooks, or automated risk alerts. The accounts that are yellow or red today are the ones least able to absorb that gap. This is a risk to retained ARR, not just a project management headache.
AI token variability — Token pricing is set by the model provider and can change without notice. Teams building AI functionality into their CS tools have no contractual protection against cost increases, and real-world usage at scale is consistently higher than initial estimates suggest.
The line that tends to land: “The savings calculation only works if you value your team’s time at zero. The build path looks cheaper on paper because it hides its costs inside your engineering team’s calendar rather than on an invoice.”
The AI Substitution Objection: A Specific Response
The “we’ll just connect Claude/ChatGPT to our CRM” objection deserves its own treatment because it’s increasingly common and requires a different response than the engineering build argument.
The honest starting point: yes, you can connect an AI tool to your CRM. The problem isn’t the ambition, it’s the architecture. Here are the specific gaps.
Memory — General-purpose AI tools have no persistent memory between sessions. Every conversation starts from zero, with no awareness of what happened with an account last week, what was flagged last cycle, or what was committed to in the last call. In a purpose-built platform, account history compounds in value as it grows. In a session-bound AI, you’re constantly re-establishing context.
Data foundation — Connecting an AI to multiple systems doesn’t normalize them. A CRM, a product analytics tool, a billing system, and a support platform all use different schemas — different words for the same things, different identifiers, different data structures. The AI sees several disconnected sources it has to reconcile each time. A purpose-built platform unifies them into a single CS-native customer record before any AI layer touches it.
Proactive alerting — An AI connected to your CRM can be scheduled to run on a timer. But a timer fires when the clock says to, not when something actually changes. A customer whose health score drops on a Tuesday waits until Friday’s scheduled run. A purpose-built platform fires the instant a threshold is crossed. That gap is not a minor inconvenience — it’s the difference between catching a churn risk and missing it.
Workflow and accountability — AI tools produce output. They do not create accountability. Nothing gets assigned to a specific CSM, nothing has a due date, nothing escalates, and nothing gets tracked to completion. Ten CSMs running the same prompt produce ten different definitions of “at-risk” and ten different versions of what should happen next.
Team visibility — AI sessions are individual and session-bound. There’s no shared portfolio view across the book of business, no audit trail, and no live risk view for leadership.
Cost structure — At scale, the economics shift quickly. 500 accounts at 50K tokens of context each runs approximately $2,000–$2,500 per month in API fees alone — before infrastructure, before a RAG layer, before engineering time. And token pricing can change without notice.
The framing that works: “An AI tool is an intelligence layer. A CS platform is the infrastructure that makes that intelligence reliable, persistent, actionable, and accountable across an entire team. A general-purpose AI connected to disconnected systems produces insights. A platform turns insights into outcomes.”
Where the Two Tracks Connect
This is the most important structural point in the entire conversation: every technical complexity has a direct financial shadow, and those shadows compound.
The bus factor isn’t just a knowledge risk, it’s a cost multiplier. When the engineer who built the system leaves, every other technical cost becomes harder and more expensive to manage. A compliance gap isn’t just a security risk, it’s a financial exposure with no ceiling. The V1 trap isn’t just a product management headache, it’s an unplanned engineering commitment that competes with revenue-generating work indefinitely.
A customer’s spreadsheet that doesn’t include these categories isn’t wrong by a little. It’s wrong by a multiple.
Discovery Questions by Stakeholder
The right question for a CTO is different from the right question for a CFO. Here’s a starter bank.
For technical stakeholders (CTO, VP Eng, lead engineer):
“When you think about connecting to your CRM, product analytics, billing, and support tools, who owns keeping those integrations working when any of those systems changes their API?”
“How are you thinking about what happens when the engineer who builds this moves to a different project or leaves the company?”
“Have you modelled the ongoing maintenance cost as a percentage of the initial build cost, or just the build cost itself?”
For financial stakeholders (CFO, VP Finance):
“Has your model included the annual maintenance run-rate, or just the initial build investment?”
“Have you factored in the compliance path, specifically SOC 2 and what it would cost to initiate and maintain that?”
“What’s the value of the ARR at risk during the 6–12 month window where the team is operating without health scores or automated risk alerts?”
For the AI substitution objection:
“When your CSMs need to know what happened with an account three weeks ago, how does the AI surface that across sessions?”
“If a customer’s health drops on a Tuesday, what’s the process for the AI to surface that to the right CSM before Friday?”
“If ten CSMs all run the same prompt today, what ensures they all take the same action?”
None of these are gotcha questions. They’re the questions of a strategic partner who has done the work to understand the full picture and wants to make sure the customer has too.
The Decision Framework
Not every customer who raises a build objection is wrong. Sometimes building makes sense. The discipline is knowing when.
The honest version of this framework: most SaaS companies should default to buying more than they currently do, while building more intentionally at the edges where their specific workflow creates genuine competitive differentiation.
The Winning Pattern
Buy the platform layer, the CRM, the CS platform, the ticketing system, the communication tools. Build the intelligence layer, custom health score logic, workflow automation tailored to your CS motion, reporting that reflects how your team actually operates.
This gives you speed on the commodity infrastructure and control over what actually differentiates your CS motion. The failure mode is the reverse: building the platform layer from scratch, then having no capacity left to build what actually makes your CS team distinctive.
Summary: The Conversation in Four Moves
Identify the type of build — Ask the clarifying question before you respond to anything.
Name the two-track structure — Signal that you’re about to cover both the technical and financial picture.
Make the invisible visible — Walk through what the build actually requires, starting with the track the customer is underweighting.
Connect the tracks — Show how the technical and financial realities compound each other. A spreadsheet that doesn’t include both isn’t wrong by a little, it’s wrong by a multiple.
The goal isn’t to win an argument. It’s to make sure the customer is making a fully-informed decision. That’s the job of a strategic partner and it’s the CSM who can hold the complete picture who earns that label.
📂 Visit tomaswilliams.com for a downloadable cheat sheet to help CSMs navigate these conversations with customers.