← Back to blog

Building vs. Buying Software in the Agentic AI age

Throughout my career, I’ve held several positions as a software engineer. When developing an in-house solution,
the “Build vs. Buy” argument was always a hot topic.

Why pay a developer “X” dollars to build a feature that “Y” developers already built? Shell out the cash, and move on, right?
Even before the advent of Agentic AI, I often fell on the “build” side of the argument. For reasonably complex problems,
an off-the-shelf solution often would require heavy customization, a team around it, and a lot of time. Why not just build it?

But now, with Agentic AI, the “build” side of the argument is becoming even more relevant.

Building vs. Buying

One of the basic premises of the build vs. buy argument is that software engineers are expensive. Purchasing an off-the-shelf solution
is a fixed cost. Later we’ll dig into the cost of operating the software and modifying software that surrounds the purchased solution.

Lowering the cost of building

Offshoring has been available for a while now. It’s a way to lower the cost of building software by engineers with
lower fixed costs. Essentially playing arbitrage with the global software development market.

First Problem

You don’t always get what you pay for. Working with contractors can be a crap-shoot. Especially when you’re dealing with
a larger project. Factor in the time-zone penalty, and what you make up for in saved dollars is lost in overall velocity.

Second Problem

The larger the team - the slower the velocity. I’d take 2 or 3 highly skilled engineers (local to each other) than a team of 10 contractors.
That small team will be able to deliver a solution faster - most of the time.

The new “low-cost” solution

With agentic AI, the “low-cost” solution is to build the software yourself. You can build it in your own time-zone,
and you can build it in your own team. What helps (in my experience) is to make sure that the human directing the AI has
a thorough understanding of the problem domain and experience in software development.

Build what you need—how you want it

Going back to the original build vs. buy argument, the “build” side of the argument is now more relevant. Instead of cobbling together
bespoke solutions, you can simply build the software that solves your problem—cheaply. I’m doing exactly that by building
Zixel, my own 2D game engine. There are very specific problems I’m trying to solve for The Vendor
which could be solved by modifying existing game engines. However, by building my own engine, I have the freedom to
easily modify it to suit each game’s need.

Why there will still be resistance

DevOps. Ug. I loathe the concept. But it’s our current reality. Entire teams exist only to cobble together off-the-shelf
solutions for deploying, running, and maintaining software. These teams will NOT take kindly to software developers jamming with
AI to create custom solutions.

Case-in-point

I could use Kubernetes or Terraform (or a combination of both) to set up and deploy server infrastructure.

Or....I could fire up Claude Code and have it build out the entire infrastructure for me. Tough to hire someone full time
when a $30 / month agent can handle it all.

Of course, there are plenty of large-scale projects that may require dedicated resources for deployment. However, I believe we’re
going to see a lot more teams choose to be lean and delegate building and deploying to AI.

An argument for buying

Not every solution warrants building it yourself. Take, for example, a task tracker such as todoist.
I use todoist every day for both personal and professional task management. It’s a great tool - although it could use some fun gamification features.
The current pricing for a professional annual subscription is $48 / year. It’s tough to justify the time of jamming with AI
to create a solution and then pay $50 / year for a VPS to host it.

Unless, of course, you wanted to turn that pet project into a business....

Conclusion

The build vs. buy dichotomy is no longer relevant. Agentic AI will allow us to build software that solves our problems,
and we’ll be able to do so cheaply.