Opinions expressed by Entrepreneur contributors are their own. I’ve had conversations with so many people who have built software in the past year, and I’m not just talking about engineers. I’m talking about people across a variety of professions and walks of life, many of them with no formal engineering experience beyond their own curiosity and experimentation. A few years ago, that would have been unthinkable.
But AI has completely changed what’s possible and who it’s possible for. If I could sum up the change in one distinct sentence, it’d be this: AI has collapsed the distance between idea and execution. When it comes to everyday people vibe-coding a fun app into existence, this is a truly exciting development. But it’s also forced us to re-interrogate one of the most central questions at the heart of business technology: Should we build it, or should we buy it?
That question is one of the many things that AI has changed forever. For most of my career, build vs. buy was mostly a capability question. Could your team actually construct and launch the software you need? Did you have the engineers, the time and the technical depth to pull it off?
The reason to build it yourself was simple: You’d be able to configure the software to fit your company’s hyper-specific needs. The alternative, buying software from a trusted vendor, was the faster and safer path. You might not get a tool that’s been 100% custom-fit to your company and your company alone, but you got a solution you could rely on — one that wouldn’t take months to deploy and exorbitant costs to maintain. In short, the “build it ourselves” path used to be a long, arduous one, full of hurdles that some companies were willing to navigate for the tailor-made solution waiting on the other side. Now, the road looks a lot less daunting on its surface.
In most cases, AI has answered the “can we build it?” question for you. The harder question is now “should we build it?” I’ve seen a lot of companies make a critical error when they answer this question. They see how much smaller the hurdles to deploying homemade software have gotten. And they underestimate the risks that running their homemade software creates.
The capability question may be settled, but the responsibility question isn’t. And before you decide to build software internally, you have to consider the financial and reputational costs you’ll be responsible for. First, there’s the issue of reliability. Your homemade solution might perform perfectly in a demo.
But running software that customers rely on is a different story. It has to keep running perfectly at three in the morning, every night, for as long as your business exists. It needs to hold up under unexpected volume. It requires entire teams of people whose job it is to make sure nothing goes down, and other teams ready for when something does.
Because when something inevitably does go wrong, you won’t have a vendor to call for help, with their own dedicated teams who fix problems 24/7. You’ll only have your own people and your own resources. Then there’s the ongoing cost of maintaining what you’ve built. Using AI to build a product might seem easier than it used to be, but running a serious AI-powered product isn’t cheap.
And that cost doesn’t stop the day you ship. Then there’s a much subtler cost: You lose the compounding value of everybody else’s experience. If you use a vendor’s product, that product will improve because thousands of other customers are using it, hitting edge cases, raising new questions and giving unique feedback. Build it yourself, and you’re on your own island, evolving only as fast as your own team can identify areas for improvement.
And last but certainly not least, there are the worst-case scenarios that none of us like to think about. You build your own software, and something goes catastrophically wrong — like your database getting corrupted or even completely deleted by some misconfigured AI. This isn’t a hypothetical; these stories have happened. As the CEO of a software company, I know firsthand that trusted vendors have a rigorous and expensive process for ensuring their data, and their customers’ data, remains safe, secure and protected from the aforementioned scenarios. If you build something yourself and don’t take the same steps, you’re risking catastrophe.
Of course, not every build carries the same stakes. I’ve seen teams have great success building things like internal dashboards: low-risk, custom-fit to exactly how they work and entirely internal. If something breaks, the blast radius is exceptionally small. They fix it as quickly as they can and move on.
Customer-facing technology does not offer that kind of grace period. I run a company in the CX space, where the stakes are high. If you build your own customer service tool and it fails, it doesn’t fail quietly. It fails for the customer who needed help and didn’t get it, at the exact moment your business was supposed to show up for them.
That’s not a bug you patch overnight or a mistake you chalk up to a “learning experience.” It’s trust you never get back. The question isn’t just whether you can build something that works. It’s whether you can build something that never fails, because you can’t afford it to. None of this means your teams should stop building things themselves.
AI has opened up a genuine world of experimentation, and your engineers should be encouraged to explore it. But freedom without guardrails is how companies end up in trouble. The rule I’d offer is simple. Experiment and build for the things that are low-stakes and safely contained inside your own walls.
Many of these experiments will break. And when they do, the damage stays small, and you learn something in the process. Customer-facing technology requires a completely different philosophy. The safety of your customers’ data and the trust they have in your business is at stake 24/7. A trusted vendor with its own security, compliance and infrastructure teams has spent years, and a lot of money, proving it can carry that weight.
You can’t replicate that kind of trust with a few weekends of vibe-coding or even a few months of dedicated engineering time. The companies that get this right are the ones that know where to draw the line. They’re the ones that encourage internal innovation within safe guardrails. And they also know when to rely on proven vendors who can not only customize solutions to their needs, but also bring the reliability, security and hard-earned trust that customer-facing technology requires.
I’ve had conversations with so many people who have built software in the past year, and I’m not just talking about engineers. I’m talking about people across a variety of professions and walks of life, many of them with no formal engineering experience beyond their own curiosity and experimentation. A few years ago, that would have been unthinkable. But AI has completely changed what’s possible and who it’s possible for.
If I could sum up the change in one distinct sentence, it’d be this: AI has collapsed the distance between idea and execution. When it comes to everyday people vibe-coding a fun app into existence, this is a truly exciting development. But it’s also forced us to re-interrogate one of the most central questions at the heart of business technology: Should we build it, or should we buy it?
