What a $600K Cut Reveals About AI-Built Software

A health insurance company canceled a six-figure annual enterprise software contract, replacing it with an internally built system developed in about two months using AI-assisted coding. Curative, the company involved, has said the change eliminated roughly $600,000 a year in licensing costs for its customer relationship management platform, Salesforce.

The decision drew wide attention, and for good reason. It puts a concrete number on a build-versus-buy question a growing number of builders are already weighing on a smaller scale: keep paying for established software, or build a faster, cheaper alternative in house.

Reducing a build timeline from years to weeks does not reduce the actual surface area that needs verifying, particularly for a system handling customer records, communications, and other sensitive data the way a CRM does. Curative's own executive publicly acknowledged that ongoing maintenance was one of the more difficult parts of this approach, which suggests the tradeoff involved is a genuine, lived one rather than a hypothetical concern.

A system can look complete and function correctly on day one while entire categories of risk remain untested, since they only surface under conditions a first pass of usage does not happen to trigger. Access control, third-party integrations, and edge cases that only appear with real, varied use are the parts of a build that a clean demo rarely reveals either way.

A working system is not the same claim as a system that has been checked for what could go wrong.

The significance of a decision like this is not really about one company's cost savings. It is what the decision signals: a company operating at real scale was willing to make this call publicly, which suggests the economics of AI-assisted building have moved from theoretical to something larger operators are now acting on. That shift raises the stakes on similar decisions elsewhere, without removing the underlying need to verify that a fast build actually holds up under real conditions.

A decision like this depends on more than the initial build succeeding. It depends on independent verification that was not part of building the system in the first place, ongoing capacity to maintain it once it is live, and an honest distinction between a system that works and a system that has genuinely been checked for what could go wrong.

For AI-built software specifically, that distinction is exactly where structured human testing adds the most value: real testers, with no assumptions about how a system is supposed to work, checking whether it actually works. Jellar connects builders with testers who do precisely that, on projects at any scale, before a launch or a cancellation decision depends on guesswork.