How AI is rewriting the build-versus-buy decision
For CIOs and enterprise architects, the warning sign is not simply poor user experience or a delayed project. It is when requirements start being negotiated around the limitations of the tool rather than business outcomes. That is a governance problem: who has the authority to challenge the platform, how often the original rationale is re-tested, and what evidence is required to keep, replace, or supplement a long-standing vendor product.
AI changes the economics, but it also changes the risk profile. A custom build may now be faster to produce, yet leaders still own maintainability, support coverage, resilience, security, and key-person dependency. The decision should therefore move beyond license cost comparisons toward a fuller operating-model question: what capabilities must remain configurable by the business, what should be productized internally, and what belongs with a vendor?
Practical next steps include reviewing major platforms at renewal and at major change points, not just for price but for constraint cost. Ask: Where are we rewriting business needs to fit the system? What capabilities differentiate us enough to justify internal ownership? And do we have the product, engineering, and governance discipline to sustain what AI now makes easier to build?
A website rebuild is meant to improve the experience for visitors and site owners. You take what the company has become, what customers need to understand, and what the team needs to manage through the site. Then you transform it into something faster and more friendly throughout the experience.
When we commissioned an outside agency to rebuild our company website on a well-known commercial platform, the opposite happened. The project ran months behind schedule, and once it was on track, the new site was slower than the one it replaced.
It’s certainly nothing unusual for a project to overrun its original timeline. It happens often. What I did not notice back then was how we got there, something I would now treat as a signal worth staying attentive to.
Somewhere in the middle of the build, the project started to creep and bend around the platform. Features were simplified, interactions were dropped, and small compromises kept piling up because they seemed the most practical way to complete the site. By launch, we had something closer to what the platform could comfortably support. Yet it wasn’t what we had set out to build, and the workarounds made even basic updates harder than they should have been.
When it’s time for a new tool
The real signal we should watch out for is when the tool starts to shape the work. I believe that’s the most useful thing to recognize here, because it applies far beyond websites.
Most organizations have software that made sense when it was chosen but no longer fits the way the work is done. The original decision may have made sense, but the mismatch has grown over time. The cost of switching is easy to see, while the cost of staying is easier to miss, so teams often stay put even as the platform slows them down. On top of that, the migration work itself and the disruption potential seal the deal. So teams stay put, even when the platform is slowing down, forcing compromises or making ordinary work harder than it needs to be.
The moment to watch for is when requirements start being written backward. For example, a team notes, “We can’t do that in the system,” and instead of questioning the system, everyone adjusts the requirement. That may be reasonable sometimes, but when it turns into a pattern, the platform is no longer supporting the work. It is setting the boundaries, letting the platform decide what the site should become.
What changed the arithmetic
We rebuilt our site on a static framework, moved hosting and solved the performance problem. But that created a new question: How do we keep the speed and control without losing the one thing the commercial platform did well, which was letting nontechnical people edit and publish without a developer?
A few years ago, that tradeoff probably would have ended the discussion because building and maintaining a content management system is real work. But AI has changed the math. I built our replacement with AI assistance, not because I am a career developer, but because the cost of creating certain internal tools has fallen enough that some old buy-versus-build decisions deserve another look.
Old technology decisions need a second look
Here’s the part of this I would flag for anyone running technology decisions beyond a single website: Many build-versus-buy decisions were made under assumptions that were true when they were made — such as how long a custom build would take, what it would cost, and how difficult it would be to maintain. Some of those assumptions have changed, especially with AI assistance, yet the decisions often stay in place because nothing forces a fresh look. While vendors might be reviewed at renewal, the reasoning behind the original choice usually is not.
I am not arguing that every organization should build more. Buying is still the right answer, most of the time, and a custom tool that nobody maintains can become a bigger problem than the subscription it replaced. The point is that the reasoning behind these choices doesn’t have infinite shelf life. When a platform has been in place for years, especially one that forces compromises in important work, it is worth asking whether the original decision still makes sense.
I’d put two important questions to any longstanding platform. “Are we changing our requirements to fit the tool, and when did that start?” And, “If we were choosing today, with what building now costs, would we make the same decision again?”
If the answer is no, that does not automatically mean switching. Migration has its own cost, and staying put is sometimes the right call. But it does mean the decision deserves another look. Otherwise, the platform is being kept by default, not because it still makes sense.
We spent time and money learning that the mistake was not choosing the platform but failing to notice when it stopped being the right one.
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.