High Tide, Low Trust: Why My Weekend App Explains Your CS Strategy

I live near the ocean and I love a swim, but only when the tide's in. Low tide is a mudflat with ambitions. So I built a little web app that pulls public tide data from an API and shows me the day's tide at a glance. Now I can plan my swims for maximum enjoyment. Winning.

Easy V1. Up in a day. Worked fine.

Fast forward a year and I've bolted on UV intensity, water quality, and a pile of other tidbits to enhance my experience. I'm now juggling a handful of APIs, plus one gloriously tedious PDF to parse, across a bunch of sources, consolidating it all into a database, so I can look at data that was already sitting in apps on my phone.

The PDF that gives me water quality, arguably the single most important number, breaks constantly. When it does, I lose anywhere from a few minutes to an hour untangling it. I could open my browser and get the same thing in two clicks. But I built an app, darn it, and I'm going to use it.

So: could this app be built? Yes. Did I need it? Absolutely not. Does it still quietly eat hours I could've spent, you know, swimming? Every week.

That's the whole build-versus-buy tension in one sunburnt little package. A couple of years ago the question was whether you could build something as complex as a CSP with AI. Today you can. The real question is whether you trust it to run your business, or, in my case, whether that water quality reading is actually right, or whether I'm going to emerge from the Pacific with an eye infection and a third arm.

And I can already hear you: "But Tomas, our APIs and data sources are way more reliable than your janky PDF. We'll be fine."

Are they, though? Really? Always?

Because once you build the tool, or the platform, the question isn't "did it work in the demo." It's: do you trust the answers? Do you have the checks in place so you're not spending every morning verifying and fixing it? And when it's wrong, who answers for it, the team that built it, or the vendor that sold it to you? In my case the stakes are a low tide and some water I'd rather not swim in today. No lost ARR, no missed churn signal. For you, the stakes have a dollar figure.

That's a much harder question than "can we build this," and hardly anyone asks it before committing to a direction. This isn't a pitch for one answer. It's a map to help you find the right one for your business, whatever that turns out to be. Because at the end of the day I still have my app, and I still ~~waste~~ spend time on it happily. It's a labour of love. Your CSP isn't. It's board decks and churn reports, and it doesn't get the same forgiveness.

Why This Got Harder, Not Easier

Before AI, build vs. buy was mostly an engineering and cost question. You could estimate the work, staff a team, and ship something that behaved the same way every single time.

AI breaks that. Because it's heuristic by nature, a model can hand you a confident, beautifully formatted, completely wrong answer; a hallucination, with no obvious tell that it happened. My tide app can be confidently wrong about water quality and the worst case is a rash. When your system is confidently wrong about a renewal, the worst case shows up in the forecast.

You also inherit a set of problems most CS teams have never had to think about. Can you trace a recommendation back to where the data actually came from (provenance)? Who's on the hook when the AI makes a bad call that costs you a renewal (liability)? And does it still work in six months, or does it quietly rot as your customers and product change (drift)? None of these get solved by "the model is smart enough." They get solved by everything you build or buy around the model.

What "Trust" Actually Requires

It's easy to nod along to the word "trustworthy" without pinning it down. There are four layers, and one weak layer anywhere drags down the rest.

Data. A unified view of the customer, CRM, product usage, billing, support, NPS, with clear lineage back to the source. My broken PDF is just a data-lineage failure; I happen to be the only one who suffers for it. In your world, PII needs real access controls, freshness needs monitoring, and schema changes need catching before they break something downstream.

Model. Outputs grounded in your actual data (that's what retrieval-augmented generation is for), not just the model's general training. Guardrails that keep it inside your business rules. And, critically, a way to say "I'm not sure" instead of guessing with total confidence.

Application. A human in the loop for anything that matters. A CSM should see why a recommendation was made and be able to override it, not accept it on faith. Evidence and citations on every output, so "the AI said so" is never the end of the sentence.

Governance. Access controls, audit logs, versioned prompts, and a real incident process for when, not if, something breaks. SOC-2 or ISO isn't a checkbox; it's what lets you tell your customers the system is being run responsibly.

Whichever way you go, these four layers are the actual product. Everything else is UI. And the "can I trust this?" question doesn't disappear when you pick a direction, it just changes what you're verifying.

Why Customer Success Makes This Harder Than Most

CS is a rougher environment for AI than most of the tidy use cases you'll read about. Your data is scattered by design, CRM, telemetry, billing, support tickets, NPS, all in different systems with different owners, none built to talk to each other. "Health" doesn't mean one thing either: enterprise and SMB define it completely differently, and a model that treats them the same is wrong for at least one of them.

CS also can't fully hand the decision to the AI. A CSM's read on a nuanced account is still what closes the gap between "the model flagged this" and "here's what we're actually doing about it." And it all runs on a clock, a usage drop or a renewal date doesn't wait for your evaluation cycle to catch up.

The Honest Case for Building It Yourself

There are legitimate reasons to build your own trust stack. Maybe your data model or workflows are genuinely weird enough that nothing off-the-shelf fits without heavy contortion. Maybe data-residency rules mean you can't hand customer data to a third party at all. Maybe you've already got ML and data infrastructure sitting idle. Or maybe how you assess and act on customer data really is part of what makes your business better than the next one's, not just "our CS team," but a genuine piece of your product or competitive position.

Any of those is real. What building buys you is control nobody else can offer: no vendor roadmap setting your pace, no paying for features you don't use, full customization to how you actually work.

Here's the part that gets glossed over. Every layer in that trust stack becomes yours, indefinitely. Grounding the model means owning a vector database and a retrieval pipeline. Guardrails and confidence thresholds mean building and maintaining them yourself, not adopting someone else's years of hardening. Explainability means engineering it in from day one, bolting it on later is much harder than it sounds. Governance means your own SOC-2 program, your own audit logs, your own incident response.

None of this happens in weeks. Getting from prototype to something you'd trust with a renewal decision takes quarters, not sprints, and it doesn't stop at launch. Models drift, prompts need re-tuning, and the team that built it is the same team you now need to keep it running. That's a standing headcount line, not a project with an end date. And this is my broken PDF at enterprise scale: I chose to keep fixing mine because it's a hobby. You'd be signing up to fix yours forever because a renewal depends on it.

If you've got a genuine reason and the team to sustain it, build is a legitimate choice. Just go in knowing you're not building a feature, you're building and staffing a small trust organization around it, for as long as you run it.

The Honest Case for Buying

Buying trades some control for speed and someone else's specialization. A vendor that's been solving grounding, governance, and explainability across many customers for years has almost certainly hit edge cases you haven't. You start from a hardened baseline instead of a blank page, and maintaining that baseline is their headcount line, not yours.

But buying isn't automatically the lighter load, it's a different one, and it deserves the same honesty. You take on lock-in: once your CSMs' playbooks and habits are wired around a vendor's system, switching later hurts. Pricing that scales with you can surprise you, what's cheap at pilot can become a real line item as seats and usage grow, so ask about the curve before you sign. And you inherit concentration risk: outage, acquisition, roadmap change, a deprioritized feature you depend on, you absorb all of it with less ability to fix it yourself.

There's a harder problem underneath all that: buying doesn't remove the trust question, it relocates it. When you build, you can inspect your own system end to end. When you buy, you're trusting a vendor's account of their own trustworthiness, with much less visibility under the hood. That's not a reason not to buy. It's a reason the diligence has to be real, not a formality.

So if you're buying, here's what I'd actually check, no matter who's across the table. Does the vendor ground outputs in retrieval with visible citations, or just serve confident text you can't verify? Can they show you PII handling, data residency, and tenancy isolation, backed by SOC-2 or ISO, not just claimed on a call? Do you get real explainability, evidence links and feature attribution, or a black box you're told to trust? Can you extend it with APIs and webhooks so you're not stuck with exactly what ships? And is the pricing genuinely transparent, LLM and usage costs included, not a seat price that surprises you at renewal?

That list holds up in any room, and it's worth turning on yourself. If you're building, hold your own team to the exact same questions. A trust stack you built but can't answer these about isn't safer than a vendor's, just less scrutinized.

Or, Often, Both

For a lot of teams the answer isn't a clean either/or. Remember: I built the whole app and still could've used the bookmark. Most teams need some of each. Buy the platform for the parts where reliability and integration matter most, the core trust stack above, and build thin custom layers on top: your own prompts, your own Claude actions, a Zap or two that fills a gap. Hardened foundation, plus room to fit your team exactly where it counts.

How I'd Actually Decide

Strip away the frameworks and ask these five honest questions, weighted equally, no thumb on the scale:

1. How much risk can you actually tolerate, given your regulatory environment and what a bad customer-facing mistake would cost you?
2. Is your data clean enough, and your team resourced enough, to sustain a build, not just demo one?
3. Is this genuinely your strategic differentiator, or table stakes you need running well without it being your whole identity?
4. How much time do you actually have before the business needs this working?
5. How deep does it need to sit inside your existing CRM, telemetry, and billing stack?

Answer those honestly and the decision mostly makes itself. Most of the work after that is discipline, not cleverness, whichever path you're on.

Trust Is the Strategy

Build vs. buy stopped being about what AI can do a while ago. It's about whether you trust what it produces enough to act on it, and whether you're set up to keep earning that trust every quarter after you ship. Build if you've got a genuine reason and the staying power to run a trust organization indefinitely. Buy if you'd rather point that energy at your customers and hold a vendor to real diligence instead of a pitch deck. Either way, hold whoever built it, including yourselves, to the same bar: grounded data, explainable output, real governance, and a system that gets more reliable over time instead of drifting.

If you land on build, I hope this was a useful map of what you're signing up for. If you land on buy or hybrid, this is the bar we hold ourselves to at Vitally, and we'd rather you hold us to it than take our word for it.

As for me, I still have my app. The PDF still breaks. I still fix it, happily, because it's a labour of love and the only thing at stake is a swim. Your CSP doesn't get that luxury. So make it something you can trust before it's the thing your renewals ride on.

PS: I wrote the outline of this article with my real brain, then gave Claude access to a variety of resources to help me beef it up, several revisions later you have this. If you’re a current customer, talk to your CSM about chatting with me about that process ;)