From our blog
When you should buy instead of make
On whether to make or buy in the era of unlimited lines of code at seemingly no cost.
October 13, 2026
By David Bloomer, Founder
The question of whether to build software or buy it from a vendor has been more relevant than ever. In the past, this question was usually only on the table for businesses that had access to a dev budget, technical expertise, or a particularly enthusiastic colleague who'd do it for you. Nowadays, however, the scene has completely changed.
With the advent of AI, the choice of whether to make or buy is one that's facing even the one-man teams of our world: all you need is a subscription to ChatGPT or Claude, the slightest knowledge about how computer programs work, and some patience in prompting, and voilà: your software is ready. Or at least the first version of it.
The point I'll be trying to make throughout this blog isn't that AI coding tools aren't good, because, damn, they are. Rather, I'll be trying to shed light on the pitfalls you could face when your business adopts a build policy.
AI is here to stay and is only getting better
Before going into the pitfalls, it's important to note what everyone already knows: AI has seen tremendous growth in capabilities over the last couple of years, and will only continue to become better. Up until recently, sceptics could, amongst other things, still hide behind the fact that AI coding has already led to some quite scandalous bugs, like the Amazon E-Commerce issue [1]. But bugs have been here forever, and with the significant surge in code output, I'd argue that those accidents are no statistical outliers tied to AI coding.
Though highly controversial, the Navier-Stokes saga [2] has shown us that flagship models, if given enough time and resources, can compete at the forefront of scientific discovery. It shouldn't be a stretch to expect that those same models can also help write and maintain increasingly complex software.
You think you know the requirements, but you don't
The problem however isn't that AI models aren't intellectually capable of building your dream software, it's that you don't know what that dream looks like. When you have an idea in your head, you often think you know exactly what it should look like. That is, until you start writing it down.
Fred Brooks put it neatly in No Silver Bullet: “The hardest single part of building a software system is deciding precisely what to build.” [4]
You might know the outcome you want: manage your leads, send invoices, keep track of employees. But turning those goals into explicit, programmable rules means answering questions you probably haven’t considered yet. Who can change what? What happens when someone leaves? Which information should remain accessible, and to whom? That's why gathering requirements, i.e. doing the work of a functional analyst, has arguably been the most difficult part of the software lifecycle since the beginning of time, and continues to be so in a world of AI.
Now, for smaller projects, iteration through Claude or ChatGPT can help you figure those things out, but for bigger software systems like ERPs, CRMs, etc., this iterative process will often start to crumble at some point if it's just the AI buddies you're relying on.
Let's take the example of the evolution of a vibecoded CRM system. You might start out small and have no access control in place at all. That works until you onboard team members who shouldn’t be changing each other’s leads. Fine: you call on your buddy Claude and ask it to restrict editing to the person who created the lead.
As your team grows, you come up with a manager concept: a manager should be able to change the leads of his or her direct reports. You call your favourite AI agent again, and make the change.
Next, you want to onboard actual customers who should be able to put in requests through your CRM. What should they be able to see? Should they be able to change requests in flight? Again, requirements have to be gathered, and another change is required to your access control system.
After a few more of those iterations, you're left with an incoherent monster that works based on hard-coded rules and one-off exceptions. Your initial reaction will be to tell Claude to come up with a better, more unified access control system, but since the codebase was AI-generated spaghetti to begin with, crucial features begin breaking and your well-intended CRM project starts crumbling down.
The above example is not an exaggeration; it's a fact. The whole reason why the industry shifted from a waterfall paradigm to an agile one is that software needs evolve over time. Your initial requirements will never satisfy your needs in a year's time, and without proper architectural planning, the software will degrade through this evolutionary process. A technical yet interesting take on this is the University of Antwerp's research on Normalized Systems Theory [3].
So what should I do?
The question now remains on what you should do as a company that's facing this decision. Having sat through my fair share of economics classes throughout Uni, I'll resort to saying “it depends,” or “ça dépend” for the French readers. On what you might ask? The below mental model should give some guidance, but its basic premise is the following: consider buying a core system that holds your data and tackles the cross-cutting concerns, and use that to build around it.
Besides the above model, I'll also leave a couple of practical guidelines that should help you understand the decision process.
- Think in terms of opportunity costs: this sounds like an obvious one, but it is very often overlooked by people, myself included. If building your own CRM will cost you five days of prompting Claude, you'll have to factor in those five days in your decision to make or buy. As we discussed before, for more complex systems you should almost always factor in the maintenance cost as well, which can be more costly than the MVP.
- Consider scope and change. A small tool with clear boundaries can be a good candidate for building yourself: a dashboard using existing business data, a script automating one process, or a simple landing page. A system connecting sales, finance, and HR involves more dependencies and more opportunities for a change in one area to affect another. This means you shouldn't try to evaluate what your system will look like today, but what it could look like a year from now. If, aside from some small changes, it remains fairly static, go ahead and use AI to build it yourself! If not, reconsider.
- Ask whether custom software creates a meaningful advantage. If your process is central to what makes your business different, custom development may justify its cost. If your needs are fairly standard, an existing product may already solve them well.
- Factor in AI improvements: But just because maintenance might be a headache today doesn't mean it has to be tomorrow. Today's AI models are great at producing nearly production-ready first versions. It's almost a given fact that your second, third, and fourth versions will require structural changes that might break things if scalability wasn't an initial concern. However, it wouldn't be too bold to assume that this migration process could be handled solely by AI in the future. I know that this one is a bit of a gamble, but it is worth considering nonetheless.
Having said all that, buying deserves the same scrutiny. A vendor’s subscription price is only part of the cost: searching, implementation, training, limitations, and eventually switching systems matter as well.
Where BloomERP comes in
Although I occasionally enjoy the now ancient craft of writing without AI, this is still a company blog. So yes, there’s a BloomERP connection.
The make-or-buy decision doesn’t always have to mean choosing between a fixed product and building everything from scratch.
BloomERP starts with the customer’s processes and builds around them, using a framework for recurring software concerns such as data relationships, permissions, dashboards, and other everyday operations. The aim is to spend less time rebuilding those foundations and more time on what your business actually needs. On top of that, BloomERP's open-source & plug-and-play nature allows you to engage in a hybrid approach: you can maintain a structured and battle-tested core (the data, permissions, etc.), whilst building out those edge cases that make your business competitive.
AI makes building software more accessible. The question worth asking is whether owning and maintaining that software is the best use of your company’s time.
Sources
[2] https://www.science.org/content/article/how-ai-math-breakthrough-ignited-controversy
[3] https://normalizedsystems.org/product/normalized-systems-theory/