The views expressed here are solely my own. They do not represent the opinions, positions, or policies of any current or former employer, client, or affiliated organization.
Here's a prediction worth sitting with: over the next couple of years, a growing number of executives are going to announce they've "cut Salesforce" or "replaced their CRM with something built in-house in a few weeks," and frame it as a story about AI and efficiency. Some of it will be genuine. A lot of it will be something else: a convenient way to blame the software for problems that were never the software's fault, while taking a shortcut that avoids ever answering the harder question of why the underlying operation was broken in the first place.
The bias this plays into is well documented, and it isn't about AI
Organizational psychology has a name for this pattern: self-serving bias, the well-studied tendency for people, and especially leaders, to attribute success to their own skill and failures to external factors. Research on this bias in the workplace describes almost exactly this dynamic: a manager under-delivers, and instead of examining their own process or decisions, points to something outside their control. A sales team misses target and blames market conditions instead of its own strategy. A leader glosses over poor numbers in a report and attributes the shortfall to the team, never their own management of it.
A canceled SaaS contract is a nearly perfect vehicle for this bias, because it comes with a built-in villain that can't defend itself in the room. "We were failing because Salesforce didn't fit how we work" is a much more comfortable story for a VP to tell than "we never fixed the handoffs, the ownership gaps, and the workarounds our own team invented to survive a process we designed badly." One of those stories ends with a press-friendly announcement. The other ends with an uncomfortable internal review of leadership's own decisions.
Why building your own tool in two months is the perfect shortcut for this
This is where the AI-assisted internal build becomes so useful, not necessarily as engineering, but as narrative. A two-month rebuild is fast enough to look decisive and modern, and it conveniently skips the one step that would actually surface the truth: sitting with the people who run the process daily long enough to find out what was actually broken, and admitting that some of it was a leadership decision, not a platform limitation.
This is the same failure pattern documented across enterprise software for years, just running in the other direction. Gartner attributes roughly 75% of system implementation failures to end-user adoption problems, and the research on why that happens keeps landing on the same root cause: the people who decide what the solution should look like are rarely the people running the process, and by the time frontline knowledge enters the room, the contract is already signed. Shadow IT is the visible symptom of that gap, tools people adopt because the approved system was designed without them.
Notice what doesn't change when the "fix" becomes building your own tool instead of buying one. If the same executives who never talked to their team about the real workflow now sit down to design the internal replacement, the diagnosis problem is identical. The only difference is that this time, the fast build lets leadership claim the win before anyone has time to ask whether the underlying process, the one that was actually broken, ever got examined at all. Two months is not just fast. It's short enough that nobody has to find out.
The discipline this is designed to avoid
This is the exact failure I built a discipline around after watching it repeat across consumer goods, financial services, and automotive content operations. I call it Fix to Flow, and the core diagnosis is the same one showing up in the self-serving-bias research above: the solution gets chosen at the managerial layer, far from the friction, by people who see the dashboard and the missed target but never the workaround the team quietly invented to hit it anyway. By the time the tool arrives, the question has already changed from "what's actually wrong, and is any of it on us?" to "how do we get people to adopt what we bought, or built?" Adoption resistance isn't the disease. It's the symptom of a solution, any solution, chosen before anyone was willing to sit with the actual problem.
The method is four movements, and the name is also the order: Map the workflow as it actually runs, not the org chart, not the story leadership tells about it. Fix what's broken and validate the repair with the people who run it, before any platform, vendor or homegrown, enters the conversation, because a surprising number of problems resolve at this step alone, for the cost of attention rather than the cost of a license or a sprint. Only then let it Flow, introducing technology in small, co-created steps built alongside the people who'll use it. Then Prove it, measuring whether the process is actually lighter and faster, not just whether the new system went live on schedule.
Get that sequence right and there's no room left for the scapegoat story, because the diagnosis happened in the open, with the people who run the process in the room, before any tool, bought or built, took the blame or the credit.
Not every in-house build carries the same risk, and Curative's own second example proves it
It's worth being precise here, because Turner's story actually contains two very different bets, not one, and lumping them together is part of how the scapegoat narrative gets its cover.
Gwen, the agent Curative built to negotiate contracts with small healthcare providers, sits on solid ground. It automates a genuinely branching process, researching a practice, pricing against what competitors pay, negotiating terms, redlining a contract, where each step depends on what the last one found and a wrong outcome on any single small-provider contract is cheap to catch and fix. And there's no market alternative built around Curative's specific pricing logic and provider mix; no vendor sells that. That's precisely the combination, real decision-making under real branching, paired with genuine absence of a market substitute, that makes building instead of buying the right call.
The CRM replacement is a different animal entirely. It's a linear pipeline, log a contact, track a relationship, follow up, not a task with meaningful branching that justifies letting a system make its own judgment calls. And it does have a market answer: it replaced one of the most commercially generic, widely used categories of enterprise software there is. Where Gwen automated a specific, repeatable, previously expensive workflow that nobody sells off the shelf, the CRM rebuilt something everybody already sells, at company-wide scope, in eight weeks.
That contrast matters for the scapegoat argument specifically. Gwen is the kind of win that survives scrutiny: narrow, measurable, genuinely without a substitute. The CRM is the kind of win that's easy to announce and hard to verify, a company-wide platform swap compressed into two months, with the CEO's own admission that maintenance is already proving difficult. Pointing to Gwen's real success is a good way to make the CRM's more uncertain one sound just as solid. They aren't the same bet, and treating them as one story is exactly the kind of blurring that lets a genuinely broken process hide behind a genuinely good one.
Which brings me back to Curative
Fred Turner's team reportedly built their CRM replacement in two months. That may well be a genuine engineering win. But it's also worth naming the incentive that now exists for any executive telling a similar story: a fast, AI-assisted build is the easiest way to announce a fix without ever having to say which parts of the old failure were the software's fault and which parts were leadership's. I don't know, and the public reporting doesn't say, how much of that build involved the people who negotiate contracts and manage accounts daily, versus how much was leadership deciding what the story should be. Turner has already said maintenance is one of the hardest parts of what they built, which is at least consistent with a process that got automated before it got examined.
That's not an accusation. It's the question worth asking of every one of these announcements going forward, because the incentive to skip it has never been stronger: did leadership actually find out what was broken and admit their part in it, or did they just find a faster way to make the software look like the problem.
Juan Carlos Vásquez has spent ten years inside enterprise content operations, repairing content supply chains before scaling them. Fix to Flow is the discipline that work produced. The views here are his own.