Build Versus Buy: Software Development in the AI Era
I was a fly on the wall at a conference where owners were asking how to implement AI in a legacy business. I wanted to know what the speakers would suggest, and I wanted to know what the audience needed.
The question that was asked most frequently was, should I build or should I buy? Across two talks, some version of it came up seven times. “How do you think about legacy tools that use AI versus building your own tools with AI, and what should be the right balance there?”
The panel couldn’t give a straight answer. I think they didn’t have a clear structure for how to answer that question. They didn’t have the straight answer ready. So I’m going to try to answer that question.
What the stage said
I heard both answers, buy and build.
Panelist one: “you should really think about investing and maybe having one software engineer at your company to go build systems for you guys. Because you’ll build a better software than anything anyone can ever sell to you.”
Panelist two: “you can be live with our software and only spend $30,000 a year rather than spending $120,000 a year with a software engineer that will get you something in a year and a half. … If you’re buying up laundry places, heck yeah, I think you should get a software engineer”
Audience member: “Earlier in the talk, you both said we should hire you so we don’t have an employee runoff. A couple minutes ago, you just said we should hire a software engineer in-house. How do you reconcile that, and what are they doing?”
What the room said
Some people are running with a software development team. They’re moving fast and getting things done.
Some are novice builders and have had trouble starting after the build. Maintenance. Who owns the project once the executive is done with the build and it’s working. One owner who had built his own said “I can’t continue to be the software developer.”
Buying software that gets you to 80%, the room split.
Audience member: “the off-the-shelf software gets you 80% of the way there a lot, but then you could vibe code on top. … Or you could take way too long to vibe code something, so you could have just bought it off the shelf for a reasonable price.”
Audience member: “they’re not really incentivized to improve that model, or if they add a feature to it, they want to monetize that feature. … that software that gave you the 80%, 80% hooks you, and it slows you down.”
It depends
It’s kind of like, should you buy a house? It depends. Are you in a place where that makes sense for you?
I want to frame the decision with a few questions.
First, if you haven’t bought or built anything yet, this is probably a type 2 decision. You can undo it. Since you have nothing yet, whatever you decide probably won’t leave you worse off than you are today.
How important is the thing you’re trying to solve? If it isn’t an actual business bottleneck, it probably isn’t worth anything more complex than having your AI agent scan your email.
Assume we’re on a real bottleneck, and fixing it will drive revenue or cut operating cost. Then do the napkin math. Back into a budget from what the problem is worth: what investment makes sense to solve it.
From here we can assume the choice is reversible, the problem matters, and we have a rough number for what it’s worth to solve.
How fast do you want to go? Is there anything off the shelf that does a good enough job? Is 80% enough, and is there an 80% product? That product is a price.
If your budget is about $10,000 a month, you could hire a good developer. You don’t need a top 1% developer to solve 90% of problems, just like you don’t need to fly in the best carpenter in the world to replace your window.
At that budget you could go either way. You could hire a developer. If it’s going to be one person, there are notes on hiring I’m not going into here. You can find somebody who’s competent, can communicate, and can manage themselves. Those people exist.
If you can’t find anything off the shelf, building is the option.
If the problem doesn’t warrant a $10,000 a month budget, hire a contractor, and find someone on your team to skill up in basic software development, and maybe basic software management.
Either way you have to deal with change management and training your team. It will never be completely without bugs, so there’s ongoing maintenance, and a documentation and handoff process.
You can build it yourself, or you can buy it. Hopefully the questions above make it clear which one is better for you and your team. Don’t let me put you in a box. This is one person’s answer to when you should build versus buy, for software and automation in your business.