The Build vs. Buy Equation Has Changed: Why AI is Making Custom Software Viable Again

This article was originally published on Forbes.

For most of the past decade, the conventional wisdom for non-software companies has been clear: don't build what you can buy. That calculus is shifting faster than most business leaders realize.

I've spent years advising my own team to follow that principle. It sounds counterintuitive coming from someone who runs a Drupal agency. You'd think I'd champion custom development at every turn. But running a services business teaches you hard lessons about where to invest your energy. Every hour spent maintaining an internal tool was an hour not spent serving clients. Every custom system eventually became a liability: updates, security patches, institutional knowledge walking out the door when employees moved on.

So we committed to SaaS. Did these tools meet every requirement? Rarely. Perhaps 70 to 80 percent of what we needed. But the maintenance burden we avoided justified the functionality we sacrificed.

That approach wasn't wrong. But the constraints that made it right have fundamentally changed.

Over the past year, I've been experimenting with AI-assisted development platforms like Replit. Building internal tools, workflow automations, custom dashboards. And something became clear that I hadn't anticipated.

The AI doesn't write perfect code. That's not the point. What's changed is the entire experience. I describe what I need. It builds a working version. I explain what's missing. It iterates. I ask it to write tests. It writes them. I ask it to run those tests. It runs them. Security scanning happens continuously. Dependency updates get flagged automatically.

That maintenance burden that used to make custom software untenable? It hasn't disappeared, but it's become manageable enough that the economics look fundamentally different.

Consider where custom software has historically sat on a risk-reward matrix.

Before AI-assisted development, custom software occupied a precarious position: high risk, uncertain reward. You committed significant resources upfront with no guarantee of success. Development timelines stretched. Requirements evolved faster than the software could. The potential reward (software tailored precisely to your operations) rarely justified that risk profile.

SaaS tools occupied safer territory: moderate risk, reliable reward. Predictable costs, someone else handling maintenance. Not transformative, but not dangerous either.

Here's what's happening now: custom software is migrating across that matrix. The risk dropped because development cycles compressed from months to days, iteration became inexpensive, and maintenance shifted from a dedicated headcount problem to an AI-assisted workflow. The reward increased because organizations can now iterate toward what they actually need rather than locking in requirements before they understand the problem.

SaaS remains valid for many use cases. But it's no longer the only rational choice.

The practical differences I've observed come down to a few key shifts.

1. Speed and cost. What took weeks now takes days or hours. The upfront investment shifted from substantial developer allocation to primarily my own time. Professional developers used to be essential. Now domain experts can participate directly.
2. Iteration and risk. Every change used to require a full development cycle. Now you describe the change and see results. Being wrong about requirements used to mean significant sunk costs. Now it means you iterate again.
3. Maintenance. This was always the killer. Manual updates, patches, the constant anxiety of technical debt. With AI assistance, that burden is genuinely reduced. Not eliminated, but manageable.
4. Knowledge transfer. When key personnel left, you scrambled to understand the codebase. Now AI can explain any part of the code to anyone. The bus factor problem shrinks considerably.

No single factor represents a revolution. But the cumulative effect, with nearly every variable shifting in the same direction, creates a fundamentally different decision landscape.

If this shift proves durable (and I believe it will), the implications extend beyond individual decisions.

We may be entering an era where custom software becomes accessible to organizations that never considered it viable. Small businesses. Nonprofits. Agencies like mine where engineering teams are dedicated to client work, not internal tooling. The barrier dropped far enough that a new category of organizations can walk through the door.

This doesn't signal the end of SaaS. Platforms delivering genuine value through network effects or deep domain expertise will thrive. But the "good enough" tools surviving primarily because custom alternatives were too expensive? Their position looks increasingly vulnerable.

I've developed strong instincts over the years about technology decisions. What to build, what to buy, when to commit resources. Those instincts were calibrated in an environment where certain constraints were treated as fixed.

Those constraints are shifting. Not disappearing, but shifting. Which means my instincts need to evolve as well.

The build-versus-buy decision isn't going away. But for the first time in my career, "build" is winning more of those arguments. Business leaders who recognize this shift early will have a meaningful advantage.

The equation has changed. It's worth doing the math again.