Buy or build now that code is cheap
The old buy vs build math is broken
For years the buy vs build decision came down to a rough rule: buying is fast and expensive over time, building is slow upfront and cheap later, if you have the engineering hours to spare. That rule assumed writing software took a predictable amount of human time. AI coding agents have knocked a hole in that assumption. A script that used to take a day to write, test, and wire into your existing tools can now take an hour, sometimes less, if the task is well scoped.
That doesn't mean building always wins now. It means the variable that used to dominate the decision, engineering time, has gotten cheap enough that other variables matter more: maintenance, reliability, and what happens when the thing breaks at 2am and you're not around to fix it.
I run AI automation in production every day, mostly content pipelines, rendering jobs, and agents that talk to real tools through MCP. I've bought software I should have built, and built software I should have bought. Here's how I actually think about it now.
What "code is cheap" really means
When people say code is cheap because of AI, they usually mean the first draft is cheap. An agent can read your existing scripts, understand a rough spec, and produce a working integration against an API in a fraction of the time it used to take. That part is genuinely true and it's changed how I plan work. I don't ask "do we have the engineering bandwidth" as the first question anymore. I ask "is this worth owning."
What's still expensive, and what AI agents don't remove, is everything that happens after the first draft ships. Someone has to notice when an upstream API changes its response format. Someone has to handle the edge case that only shows up once a month. Someone has to keep credentials rotated, keep the server patched, and keep the whole thing running when you're asleep or busy with something else. Writing code got cheap. Owning code did not.
That's the actual shift buy vs build has to account for now. The build side of the ledger got a lot lighter on the initial cost line and stayed exactly as heavy on the ongoing cost line.
When building makes sense
Build when the thing is close to your core workflow and you need to see exactly what it's doing. If a task touches something you'd want to debug yourself at 2am, a bought tool that hides its internals behind a dashboard is a liability, not a convenience. I build the pieces that sit directly in my content and rendering pipeline because when something silently produces bad output, I need to trace it back to the exact step, not open a support ticket and wait.
Build when the task is narrow, repetitive, and specific to how you work. Generic tools are built to serve everyone, which means they carry configuration and assumptions you don't need. An agent that reads your own folder structure and calls your own scripts doesn't need a settings page. It just needs to do the one thing correctly.
Build when the cost of being wrong is low and recoverable. A local script that mislabels a file is annoying. A vendor tool that mishandles customer data is a different category of problem. Match the ownership model to the blast radius.
Build when you actually intend to maintain it. This is the part cheap code generation tempts people to skip. An agent can write you something impressive in an afternoon, but if nobody is going to look at it again until it breaks, you haven't built a tool, you've built a landmine with a delay timer.
When buying still wins
Buy anything where reliability matters more than customization. Payments, authentication, hosting infrastructure, transactional email delivery. These are solved problems where a vendor's whole business is making sure the thing doesn't go down, and that kind of operational discipline is hard to replicate with a script you wrote in an afternoon, no matter how good the first draft was.
Buy when the problem is genuinely commodity and well understood, and a mature tool already exists that does it. Rebuilding something that's already been built well, tested at scale, and hardened against edge cases you haven't thought of yet is rarely a good use of the time you saved by having an agent write the first draft faster. The time you save on typing gets spent on discovering the edge cases the vendor already found years ago.
Buy when you need someone else to be on the hook when it fails. If a tool goes down and it's core to your business, having a vendor with an SLA and a support line matters more than having written the code yourself. Self-built tools have exactly one point of escalation: you.
Buy when the integration surface is wide and changes often. Some categories of software have to keep pace with constant external changes: shifting API standards, new compliance requirements, browser or OS updates. A vendor who specializes in that category is tracking those changes as their full time job. A script you wrote once is not.
A framework that actually holds up
I use three questions before deciding, and none of them are about how fast an agent could write the first version, because that's now nearly always fast.
First, what breaks if this is wrong, and who notices. If the answer is "nobody, and I fix it next time I look," build it. If the answer is "a customer, and it costs trust or money," lean toward buying something with an operational track record.
Second, am I willing to own this in six months. Not write it, own it. Reading logs when it misbehaves, updating it when an upstream dependency changes, replacing it when it stops being the right tool. If the honest answer is no, buy, because a bought tool's maintenance burden is contractual and a built tool's maintenance burden is entirely yours.
Third, is this actually differentiated for me, or is it infrastructure everyone needs. Infrastructure that every operator in your position needs, in more or less the same shape, is infrastructure someone has already built well. The parts of your workflow that are genuinely specific to how you operate are the parts worth building, because nobody else is going to build exactly that for you.
Local vs cloud is the same decision in disguise
The buy vs build question shows up again once you decide to build, in the form of local vs cloud. Running a model or a pipeline locally means you own the hardware, the uptime, and the electricity bill, but you're not paying a recurring fee to someone else and you're not sending your data through a third party. Running it in the cloud means you're paying for someone else's uptime and someone else's hardware refresh cycle, and you get to walk away from a server room problem at 2am because it isn't your server room.
I run rendering locally because the workload is heavy, predictable, and mine to control. I use cloud services for things where I want someone else answering the page when it goes down. Same framework, same three questions, just applied one layer lower in the stack.
The bottleneck moved, it didn't disappear
Cheap code generation changes what's scarce. It used to be engineering hours. Now it's judgment about what's worth owning, and discipline about actually maintaining what you build. An agent will happily write you ten integrations in a day. Whether that's a good idea depends entirely on whether you, or someone, is going to keep those ten integrations alive next quarter.
Buy vs build was never really about the cost of writing the code. It was about who's responsible when it breaks. That hasn't changed, even though the code got a lot cheaper to write.
If you want more on how this plays out with real agents, MCP, and local vs cloud AI setups, you can find more breakdowns on the [home page](/).
Get new guides and videos first — join the Telegram channel.