The Real Cost of DIY Customer Advocacy, from a Customer Marketer Who’s Done It

I’ve heard some version of this in almost every budget conversation:

“We could probably just build something ourselves. Throw it together in Google Sheets, wire up some Zapier automations, use AI to handle the messy parts.”

I get it. If you’re the kind of customer marketer who’s already thinking about how to build a real advocacy program instead of just checking a box, building your own system makes total sense as a first instinct. You’re resourceful. You don’t want to wait on budget approval to start proving impact. That instinct is a good one.

You can build the first version, too. A motivated person with a few hours to spare on a weekend can spin up something that looks functional. AI coding tools have made that first step faster than it’s ever been.

So my question isn’t whether you can build it. It’s whether building it is actually the best use of your time.

---

The 10% that fools you

Here’s the thing about building internal tools in 2026: the initial build has never been cheaper or easier. I could vibe-code a functional advocate tracker in an afternoon if I wanted to.

Vanta recently modeled what “building vs. buying” actually looks like over five years for a similar kind of platform decision. Even with AI cutting initial development time by 40 to 60 percent, the five-year total cost of ownership for building still comes out 3-6x higher than buying.

Why? Because coding is only about 20 percent of the total cost of software. The rest is everything that comes after the demo.

Amit Bendov, the CEO of Gong, put it well in his LinkedIn post:

“Building is 10%. Running and supporting is the unglamorous 90%.”

He followed that with a few questions I think are worth asking before you start:

• Who’s on call when something breaks?
• Who’s in charge of ensuring customer data is being handled properly (especially if you’re in a regulated industry)?
• Every integration you build is one you’ll maintain forever. What’s your plan for when Salesforce changes an API and your Zapier chain quietly stops working?

These aren’t hypothetical risks for me. They’re the costs that show up right after the initial build feels like a win.

---

What makes advocacy specifically hard to DIY

Not all internal tools are created equal. A basic customer examples library or a references tracker? Totally reasonable to build yourself, at least to start.

Advocacy is a bit different, mostly because it’s operationally complex, highly cross-functional, and time-sensitive in ways a lot of internal tools aren’t built to handle. A few places where I’ve seen the stitched-together stack start to crack:

If the builder leaves, so does the system. This is the one nobody talks about in the initial pitch. If the person who built the system moves to a new role or leaves the company, the system usually goes with them. Not because anyone did anything wrong, but because documentation is hard to keep current and tribal knowledge doesn’t transfer cleanly. Now, whoever’s left is either reverse-engineering it or starting over.

Security and compliance become your problem. When you buy, compliance certifications, data handling regulations, and security reviews are already built and maintained by a team whose full-time job is exactly that. When you build, that responsibility lands on whoever owns the tool, on top of everything else they’re already doing. I don’t want to be the one to answer the door when a Data Protection Agency comes knocking asking about my vibe-coded GDPR practices.

AI hallucination risk touches real customer data. This is a big one. When you use LLMs for customer evidence and advocacy, you’re trusting AI-generated outputs. Without a validation layer, it’s easy to end up acting on something that sounds right but isn’t sourced anywhere.

I ran into this exact issue while at a previous company: teams generating and circulating AI-fabricated stats and customer quotes with no clear source or way to verify who said what, or when. The issue compounded when other well-meaning marketers created content from these hallucinated assets. As you can imagine, this not only led to internal friction, but also stalled critical GTM communications while I worked to track down and clean up these pseudo-quotes. Once we plugged in UserEvidence’s MCP Server, that problem went away. We had third-party verified proof with original source links, so that all parties were working from the same well of truth and anyone could validate the work themselves. I get into the full story in this webinar.

Advocate burnout is easy to miss without the right signals. A homegrown system usually doesn’t have a built-in way to track how often you’ve tapped a customer, or whether they’re primed for another ask versus quietly tapped out. Without that visibility, most teams default to the same 10 customers, which is exactly how burnout happens.

Risks that don’t show up in the initial Pitch

---

The 90/10 rule, applied to advocacy

Jason Lemkin at SaaStr has been making this argument for years: buy 90 percent of what you need off the shelf, and reserve your building energy for the 10 percent where nothing solves your specific problem.

His take on vibe-coding specifically has stuck with me:

“I love vibe coding. I have built 10+ production apps with it… But here is what I have learned: you probably do not want to vibe code the things you actually depend on for your business, if there is anything reliable, proven, you can buy yourself.”

The advocacy category has purpose-built solutions now, UserEvidence being one of them. It really comes down to a choice: start your program in month one with something ready-made, or spend the next couple of quarters building the infrastructure just to get to the same starting line.

What a year looks like, each way

Here’s the honest version of both paths, side by side.

The gap here isn’t really about capability. It’s about momentum. Every month on a purpose-built platform compounds. Every month on a homegrown system tends to get split between running the program and keeping the lights on.

---

“Crawl, walk, run” and where “build” actually fits

I hear a version of this a lot: “we need to crawl first,” meaning try the DIY approach before committing to a real tool. But building the infrastructure yourself isn’t the crawl stage, it’s an extra step before you even get there. Here’s what crawl, walk, run actually looks like for advocacy:

• Crawl is getting your advocate list organized and running your first campaign.
• Walk is having a system that automates the operational parts for you.
• Run is the program operating at scale, with attribution, segmentation, and clear reporting to back it up.

---

The bottom line

AI has made the first mile of building something genuinely easier. Where I’ve seen teams get stuck is the remaining stretch: ongoing maintenance, security reviews, keeping AI outputs verifiable, and protecting your advocates from burnout without a system that’s watching for it.

If you’re weighing this decision right now, it might be worth looking at what’s already out there before you build. Take a look at UserEvidence’s Advocacy platform, or book time with us if you want to talk through how this could work for your team specifically.