Build vs. Buy When Claude Can Build Anything

Chris Fournelle

October 7, 2026

9 min read

The hard part of software has never been writing it. It has been owning it. 

You’re starting to hear it at industry conferences, and it’s a growing topic in think pieces: now that AI can write the code, why buy software when you can build it yourself? For a handful of narrow jobs, that is the right call. For a while, it will look like the right call for almost everything. 

“For a while” is the key phrase, because most of what is happening right now is not companies replacing what they bought. It is experimentation. 

Experimenting is a human instinct and a useful one. A capable person with an AI agent can stand up a working prototype over a weekend, and for a content business watching software costs climb, the temptation that follows is rational: if we can build the tool, why are we renting it? 

I’ve watched capable people do just that to replace an internal tool. The pull is real, and almost addictive, because the feedback from AI is immediate, and immediate feedback is hard to put down. The mistake the build-it-yourself crowd makes is assuming the prototype was ever the hard part, or that the interface you are looking at is the product. As developers know, there is considerably more to a platform than a clean UI. 

We were here pretty recently. A couple of years ago the same energy was pointed at the public cloud. AWS and its peers gave developers new tools and a pay-as-you-go meter, and the pitch was the one we are hearing again now: why buy a finished product when you can assemble exactly what you want from parts? Plenty of teams did. A lot of them are the same teams that drifted back toward managed services once the cost of running what they built came due. The pendulum swings toward build every time the parts get cheaper, and it swings back toward buy every time the bill for owning them comes due. AI just gave it another push. 

It is fair to say the pendulum swings the other way too. A handful of companies have pulled workloads back in-house to control cost. But that is an economics decision made at the extremes, by teams large enough to run infrastructure well. For everyone else, the gravity still points toward buying the parts you don’t compete on. 

Every new wave of technology makes building look affordable again and tempts everyone to forget that part. 

Even as building gets cheaper, most companies still buy the bulk of what they run rather than build it, and for good reason. Building has a long track record of going sideways: the Standish Group’s long-running research on IT projects has found only about a third are judged fully successful, with custom builds routinely blowing past their original estimates. Even AI’s loudest backers concede the point: companies are not going to want to build, run, and maintain their own core software, because it is too costly and too big a diversion of scarce engineering talent. 

What is hard to copy was never the code. It is everything wrapped around it, the operational depth that only shows up once real work runs through the system. 

That is the market view. The engineering view says the same thing, and it is where the “just build it” instinct quietly falls apart. Here is what the weekend demo hides, and why none of it gets easier the bigger you get. 

Your prototype works when everything cooperates. It does not handle the wonky input, the dependency that goes down mid-job, the sudden peak when everyone hits it at once, the newsroom that still has to get the story out after a crash. Nobody designs those behaviors in an afternoon. They get beaten out of the software over years, in failure conditions no training set ever saw. AI is excellent at the code that has been written a thousand times. It has never seen your 2 a.m. version. 

Trust is not given because the UI looks clean. Users want the assurances, SOC 2, TPN, the audits that get renewed whether or not anyone remembers. AI makes that bar harder, not easier. Veracode tested code from more than 100 models and found it introduced security vulnerabilities 45 percent of the time, and a year of newer models left that rate essentially unchanged. The speed you feel while vibing is the same speed at which you generate flaws someone now has to own. 

The integrations decay the day after you ship. Nothing you build holds still. A partner changes an API, a format you depend on moves, and the tool quietly breaks. That maintenance never ends, and it is all yours. It is one reason the industry keeps drifting toward managed services for the parts that aren’t differentiating: running them in-house pulls the team off the product and onto upkeep. 

Building your own tool is a down payment, not the price. The build is the cheap part; the keeping is the expensive part, and AI made only the cheap part cheaper. Back when the question was cloud build vs. buy, the same handful of cost traps caught media companies again and again. 

And you carry it alone. A tool you built learns only from your own outages, one painful lesson at a time. A platform thousands of companies depend on sees a failure once and fixes it for everyone, so you inherit the benefit of every other customer’s bad day for free. That is the real purchase: not a feature list, but a decade of other people’s edge cases already handled, and one organization whose whole job is staying ahead of the next one. The old IT phrase for it is one throat to choke. Build, and the only throat in the room is your own. 

At scale, accountability beats autonomy. It is why teams that start by rolling their own so often end up buying instead, and why pure pay-as-you-go rarely survives contact with scale. 

None of this argues against building with AI; it’s about where to point it. Gartner’s framing only got more relevant: buy what you can, build what you must, and blend the two. The instinct that AI overturns this has it backward. Cheaper building makes the discipline matter more, not less. 

Build the narrow thing that is genuinely yours, the workflow or creative capability a competitor cannot buy off a shelf. Buy the commodity beneath it and put that commodity on someone you can hold to account. 

In media and entertainment, the line is clearer than we would like to admit. Our advantage is the content and the judgment that goes into it. The unglamorous work of keeping that content secure, organized, and trustworthy as it moves between people and systems is foundation. It is hard and it matters, and it is still not where any of us made our name. 

That is the bet Signiant has always made: the work underneath the content is too important to be a side project for a team whose real job is making and distributing it. Buy the foundation from someone who answers for it. Spend your people on the work only they can do. 

AI changed the answer to “can we build this?” For most teams, it is now yes. It left the harder question untouched, the one worth asking before anyone opens an editor: should we own this? 

The pendulum will swing back toward buy, the way it always has. The teams that come out ahead will be the ones that built only what was theirs and let someone else carry the rest.