I was drinking my coffee last night and reading about Curative, the US health insurer whose CEO has been talking up how much of their operation now runs on AI agents. One line stood out and stopped me. They’re spending millions of dollars a month on AI, and the headline they’re celebrating is cancelling a $600,000-a-year Salesforce contract because they vibe-coded their own CRM. Saving $600k a year is a good day. It just looks a bit different sitting next to a bill climbing into the millions a month, and it got me thinking about what actually gets counted when a story like this gets shared.

In their defence, some of what they describe sounds genuinely good. They’ve got an agent negotiating provider contracts for about $70 per contract, down from $1,500 to $2,000 when people did it by hand, and credentialing that used to take two months now apparently takes about half a day. If that actually works and holds up at volume, it’s a real improvement and a better use of the Curative staff’s time. Whether the sums work depends on how many contracts they’re doing against that seven-figure monthly spend, but directionally, using AI to take two weeks of repetitive work off a person is exactly the sort of thing it’s good at. I’ve got no argument with that part.

The point where I’d slow down is turning that demo into a production CRM, and not because vibe coding is bad. I’d take a working demo over a couple of lines of requirements in an email any day (I got two of these last week). It’s a genuinely great way to build a prototype and work out what someone actually needs, because people are far better at reacting to something in front of them than describing it in the abstract. We saw this years ago on a project with a local council that had never run an IT project before. Rather than keep talking in circles about requirements, we opened a platform and built the thing live in the room, adding fields and screens while they watched, and the conversation changed completely once there was something real to poke at. Vibe coding is the same trick, which is now available to anyone, and that’s a good thing. Requirements tend to be discovered, not described.

But there’s a difference between a working demo and a system you run your business on. I learnt this properly working with a startup on a consumer irrigation product, where I assumed the hard part would be the technology, and it turned out the technology was the easy bit. The support, the operations, the hosting costs, the whole business around it, that was the real work. Building software and building a product are not the same thing, and the software is often the easiest part. A vibe-coded tool is the software. Everything after it is the product.

So when a working prototype turns up and someone wants to run the business on it, these are the boring questions I find myself asking. Did they roll their own authentication, or use a proven flow that thousands of other systems have already stress-tested? Is there any authorisation behind it, role-based access, or can anyone who gets in see everything? What happens to the data, is it encrypted, is it private, does it leave the country? Does the thing survive anything other than the happy path it was demoed on? Are there tests that prove it works, or does it just look like it works? What’s it built on, current libraries, or a pile of dependencies riddled with known vulnerabilities? And how is it hosted, something that scales, or a Python script running on someone’s laptop or that old desktop in the corner? None of these are exciting questions, but they’re the ones that decide whether you’ve got a tool or a liability.

The failure mode that worries me most isn’t the tool that falls over loudly. You notice that, and you fix it. It’s the one that looks completely fine and is quietly wrong. We had an incident recently on a system we host where a single mistyped character in a config meant the app had been running on a fifth of the memory it should have had. It ran fine for months, then stopped doing its overnight work for the better part of two days while every health check happily reported it as up. The process was running the whole time; the thing the process existed to do was dead. A tool that’s confidently wrong is more dangerous than one that’s obviously broken, because nobody goes looking.

That matters even more when there’s money involved. A long time ago I worked on rewriting a financial system for a government revenue office, and the highest-risk part, the payments and reversals and the transactions that had to be exactly right. We spent a single day in a tiny meeting room with a whiteboard, hashing out the complete design and working through every transaction scenario we could think of. Then we spent the month before go-live making that design real and pushing for complete coverage of those financial transactions. Not because coverage is the goal, but because confidence was. And I’m proud to say it went live with zero defects, while the expensive off-the-shelf product it sat alongside had a steady backlog of failures. Zero production defects was the standard we held ourselves to, because people were relying on the finance system numbers being 100% accurate. That’s not something you get from a weekend of prompting.

Which brings me back to the money. The $600,000 is the easy number to put on a slide. What’s harder to put on the slide is the person who now owns that CRM, keeping its dependencies patched and answering the phone when it breaks, and the day the underlying model changes or its price does. I’ve felt a small version of this. We were happily paying about $120 a month for our AI coding tooling at Biz Hub until the pricing model shifted, and the projection jumped past $2,000 a month almost overnight. Curative’s own AI bill has reportedly been sextupling month over month with no sign of slowing, the same curve, a couple of orders of magnitude up. I’m not saying don’t spend it. I’m building tooling at the moment to measure our actual return on AI spend, precisely because spending without measuring is the part I’d question. Celebrating $600k saved while the AI bill climbs into the millions, with no measure of the return, is optimising the number you can see.

I don’t jump straight to selling someone a custom software solution just because they have a problem and a budget. Sometimes an off-the-shelf product will do the job, sometimes the problem genuinely is better suited to a spreadsheet, and sometimes there are other places they could spend the money for a much bigger win. The rule I keep coming back to is simple enough: build it if it’s how you compete, buy it if it’s how you operate. Biz Hub used to run its own email server years ago, and eventually we stopped, because email isn’t how we compete; it’s just how we operate. Microsoft 365 costs us more in licence fees than the server did, but the couple of hours a month the server used to eat up was worth more than the licence fees, so it was an easy call. A CRM, for most companies, sits on the same side of that line. The tools genuinely worth owning are the ones where owning them is your advantage, and even those still need someone to take them the rest of the way to production.

So if you’re a CIO or an ops lead who’s tried this, or who’s being shown the Curative story by someone on your board and wondering whether to have a go, I’d say two things. The demo is the exciting five per cent; it’s real, and you should absolutely keep doing it. It’s the best requirements tool we’ve had in years. Just know the other ninety-five per cent is still there: the compliance, the security, the testing, the hosting, the ownership, the boring stuff that decides whether your data (and your client’s) stays safe. That’s the part worth doing properly, or worth having someone do properly for you, so you keep the leverage without taking on risks you didn’t know you’d signed up for.

Sources

Further reading: