.png)
AI and Customer Success Tech Stacks: The Build v Buy Playbook
- Gemma Cipriani-Espineira
- 1 day ago
- 7 min read
The Customer Success tech stack landscape is evolving faster than ever. I hosted a pay it forward webinar with Jeff Kushmerek (Infinite Renewals), Chad Horenfeldt (Avoca), Graham Gill (Precursive), and Josh Schachter (Gainsight) to discuss the Build v Buy debate. Read on for an actionable playbook based on their insights. Scroll down for the full session on YouTube.
There is a white rabbit in every Customer Success team right now. Picture Alice in Wonderland's white rabbit, pocket watch out, muttering "I'm late, I'm late." Or Neo in the Matrix, told to follow the white rabbit into a world he cannot see yet. Either way, the instinct is the same. The future is calling and you feel behind. I know these rabbits well. I am them, bolting down the hole after the next AI thing.
The panic is not that we are lost. It is that everyone feels behind, chasing a schedule the technology keeps resetting. And so we bolt. Buy a thing, build a little on top, discover the thing we built needs another thing, buy that, and look up to find ourselves at a stranger door in a stranger room. Curiouser and curiouser. Build vs buy is not one decision you make on time. It is a world you have to learn to move through without running yourself ragged.
First, the honest truth: nobody is all-in team Build or Buy
Ask a consultant, a vendor, and two leaders "build or buy" and you expect a fight. We got a spectrum instead. Here is where each of them actually stands, so you can find your own coordinates:
Jeff: as a consultant, helps clients build, buy where they lack staff, or go hybrid on a platform they can build custom agents on top of.
Chad: a leader building with Claude right now, on top of HubSpot.
Graham: another leader building with Claude right now, on top of Salesforce.
Josh: a vendor at Gainsight, recommending to buy, then build on top.
And the room agreed with them. When I polled the CS leaders in the audience, only 11% said they were still exploring and evaluating. Everyone else was already down the rabbit hole: 32% building custom team tools and integrations, 25% enhancing the CSPs and CRMs they already pay for, and another 32% with individuals using AI ad hoc and no team strategy at all.
Sit with that last number, because it is the one that should keep you up at night. It is not the stragglers who are exposed, it is the teams moving fast with nothing holding the work together. Nearly two thirds are building in some form, which means the question is no longer whether you go down the rabbit hole. You are already falling. The only choice left is whether you fall with an owner and a budget you can see, or whether you do it ad hoc and call the chaos a strategy.
So can you just build it yourself now?
The short answer is Yes. Genuinely. With Claude, Codex, or a few no-code tools, Chad and Graham on this panel already have. The tools crossed the line where a small, scrappy CS team can stand up the dashboards, coaching engines, and handoffs that used to need a vendor and a roadmap. That part is real, and it is new.
But being able to build it is the easy 20%. Owning it, securing it, governing it, paying for the tokens, keeping it alive when the builder moves on, that is the other 80%, and that is where this decision actually lives. So the real question is not "can I build it." It is "can I build the right thing and keep it standing."Everything below is going to help you navigate this, decision by decision.
The Build vs Buy Scorecard
Fair warning before you start. This is work. If you want a plug-and-play answer that lets you skip the thinking, this is not the scorecard for you. If you want to operationalize AI for your CS program in a way that survives six months, this is the scaffolding. Use it to find where you land on the build v buy spectrum for the problem you are trying to solve. The scorecard is interactive, click through to see your score and re-use it as many times as you please.
The hidden build bill (total cost of ownership)
Now let's take it a step deeper. Building is, IMHO, the fun part. Just me, my Mac, and a good Spotify playlist. Then the real weight arrives, piling up on my screen. Graham said it plainly:
"Building software is easy, maintaining it is hard."- Graham Gill, CCO Precursive
Before you commit to build, add up the hidden costs most builders forget:
Build hours (the only cost most teams count)
Maintenance hours (bug fixes, updates, breakage, forever)
Security and compliance (usually an afterthought, always expensive late)
Token and inference cost, per team (the blind spot on every panel)
Opportunity cost (what your best people are not doing instead)
Nobody on the panel had fully cracked token economics, and that is the tell. You can blow through your limits fast, and the moment you do, your "cheap" internal build starts to cost like a platform anyway.
The build ownership flow (so it does not rot)
Here is the quiet failure. Your most innovative team members are already building beautiful workflows. Multiple skills, projects, reports, and dashboards, different versions of the same thing. They do not care about your architecture. They care about their experience. And if nobody is unifying the work, your governance is already leaking.
To balance innovation with long-term adoption, run everything you build through three gates:
Prototype freely. Let people spin things up. Encourage it. Time-bound hackathons like Atlassian's ShipIt Days are a great way to do this.
Standardize ruthlessly. Chad is moving someone into an AI operations role to run a centralized, standardized library of skills, so a new hire can install a proven workflow on day one instead of reinventing it.
Assign a named owner. If no one owns it, it does not ship. Graham recommended internal app stores to govern which tools employees can use.
The build value formula
Proving value for something you build is not a fine science yet. The one that holds up best right now is value by time saved.
Track it simply: hours saved per week, times your team's loaded hourly cost, plus the improvement in time-to-value for customers.
Graham's proof point: he has agents optimizing handovers for implementation teams, improving TTV, and other agents cutting SOW reviews from two hours to ten minutes. Real hours back.
Jeff's method: start with the customer journey, find where your team loses the most time, then point AI at that. Jeff built an AI Capability Maturity Model to help demonstrate what this might look like for your business.
Claude builds worth stealing
You do not have to invent these. Steal from Chad, or ask your existing vendor if they have something comparable.
Dashboard layer on your CRM. Chad's CS Command Center, built with Lovable on top of HubSpot, pulls onboarding, at-risk accounts, churn, capacity, and goals into one view the whole org can see.
Evidence-based coaching from call data. His coaching tool, built with Claude and DM'd to reps via Slack every Monday, scans calls and gives feedback tied directly to recordings. The exact prompt is public.
Automated handoff summaries. When a deal closes, Claude pulls every relevant call and email into a brief and Slacks the implementation manager a link to everything they need.
A CSPs vendor's honest truth
Josh had the least defensive vendor take I have heard in a while. His view is that buyers want to build, so let them, stay close, and most come back to build on top. He has written about it, and it holds.
He also named the reflex to watch. Spend drift. Who knows how LLM costs will move over the next few weeks, let alone budget cycle? His advice is to keep core, repeatable agents in a purpose-built place, and save open-ended experimentation for the LLMs where it genuinely earns its cost. Graham agreed. He originally took a liberal approach to usage, starting with ChatGPT, then moving to Claude. Now, two years in, he is starting to think about guardrails for tokens. As CFOs take note of unprecedented AI costs, the tokenmaxxing trend is starting to get... old ;)
The part I stand by
You are not just choosing tools. You are choosing what kind of operation you want to run. As Head of Digital Success at Atlassian, I ensure our team leans heavily on Rovo, our own AI teammate, for a lot of the work behind the scenes. We have more agents than people supporting our digital motions now. The stance is simple. Drink our own champagne wherever we can, and partner with best-in-class vendors where they deploy fast, stay low-maintenance, and do not compete with our core.
That balance is the whole reason CS Angel exists. I launched this community in 2023 because I saw a gap in the post-sales stack, and I set up an angel syndicate dedicated to it. I still see the gap. The difference is that AI has made it impossible to ignore. The old CS stack was built to manage customer data and human workflows. It was never designed to help you orchestrate the right balance of people, agents, and digital systems across the journey. No one has cracked that yet. Not the vendors, not the builders, not me.
But the teams keeping pace are not waiting for someone to. They build with AI where the work is truly theirs, and buy from vendors integrating AI where it is not. Not fence-sitting. Just more ground than either path covers alone. And by Sod's law, whatever I write today, the tools will have moved by the time you read it. So trust in your ability to ask the right questions and place yourself on the spectrum, not on a side.
Keep going
If strategy, budget, or data foundations are your blockers, our angels have you covered. Check out these blogs from our pay-it-forward series:
How to secure budget for CS technology: multi-thread, tie spend to top-line goals, show how it scales with revenue.
How to build data foundations for digital success: clean inputs are the fuel for agentic AI.
How to use AI in customer success without killing trust: the hurdle is rarely vision, it is operationalization.
Thanks to Jeff, Chad, Graham, and Josh for paying it forward to our community!
For more content like this, follow CS Angel on Linkedin
Interested in joining our angel investing group? Apply here
