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 rest.”

Not gonna lie, I’ve said it myself once or twice. 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, and you don’t want to wait on budget approval to start proving impact. That instinct is a good one, and I’d never try to talk someone out of having it.

You can build the first version, too, by the way. A motivated person with a few hours to spare on a weekend can spin up something that looks functional. Heck, I could probably vibe-code an advocate tracker before my daily ‘yes-you-have-to-wear-pants-today’ negotiation with my toddler wraps up. 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.

---

Building is the easy part

True, the initial build has never been cheaper or easier. But the honeymoon phase of vibe-coding your way to a solution fades quickly.

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 and never makes the pitch deck.

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?

I’ve been the ‘who’s on call’ more than once, and it’s never at a convenient time.

---

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 will bite you, though. It’s operationally complex, highly cross-functional, and time-sensitive in ways a lot of internal tools were never built to handle. A few places where I’ve watched a stitched-together stack quietly start to crumble:

If the builder leaves, so does the system. Nobody puts this one in the initial pitch, for obvious reasons. If the person who built the system moves to a new role or leaves the company, the system usually goes with them, taped together automations and all.

Not because anyone did anything wrong. Documentation is hard to keep current and tribal knowledge doesn’t exactly transfer over a Slack handoff doc. Whoever’s left is either reverse-engineering it or starting from scratch.

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, all of that lands on whoever owns the tool, on top of everything else already on their plate. I, for one, 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 for me and hits close to home. When you use LLMs for customer evidence and advocacy, you’re trusting AI-generated outputs, and without a validation layer, it’s shockingly easy to end up acting on something that sounds airtight 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.

In summary…

---

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 explains it well:

“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.”

Advocacy has purpose-built tools 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 starting line.

What a year looks like, each way

Here’s a breakdown of both paths, side by side.

The gap here isn’t really about capability as much as it is 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 re-duct-taping whatever broke that week. I’ve lived enough of that left-hand column to know it by heart.

---

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

You might be thinking, “sure, but my leadership team wants us to crawl before we walk.” In this case, crawl means DIY-ing your approach before committing budget to a tool. Sometimes there’s no way around it, and you’ll just have to roll up your sleeves to prove it out.

But I’d like to offer some food for thought: building your own tooling infrastructure isn’t actually the crawl stage. It’s an extra step before you even get there.

Here’s what crawl, walk, and run should actually look 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.

---

Where to go from here

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 commit a quarter to building your own. Here’s our UserEvidence Advocacy platform for whenever you’re ready to poke around. Book time with us if you want to talk through how this could work for your team specifically.

And if you’d rather just talk it through first, no pitch required, shoot me a message! Happy to brainstorm, talk strategy, or commiserate over our shared woes.