AI, Security, and Software Ownership: Why Businesses Are Building Again

h2>Three forces are changing the business case for custom software—and giving companies new reasons to build.

For most of the past decade, the build-versus-buy decision around business software has been fairly predictable. If a commercial product solved most of the problem, companies generally bought it, configured it as best they could, and adjusted their processes around whatever limitations remained. Custom software was typically reserved for situations where the requirement was highly specialized, the application itself was part of the product, or there simply wasn't an off-the-shelf option capable of doing the job.

Well..... That calculation is beginning to change.

It isn't because every company suddenly needs to start building its own software, and it certainly isn't because AI has somehow made application development free or effortless. Granted, it has made it somewhat easier, but it still takes proper engineering or else your AI-crafted prototype may blow up. Rather, several forces are converging at the same time, and together they are changing the economics and the strategic value of building software.

From where we sit as a development agency, three stand out: companies need existing systems to work with AI, aging applications are becoming increasingly difficult to secure and maintain, and businesses are beginning to question whether it makes sense to keep renting certain software capabilities indefinitely.

Each of these existed before generative AI arrived. What's different now is that companies have more reasons to revisit decisions they may have made five, ten, or even fifteen years ago.

Software Needs to Be Ready for AI

Almost every conversation about business technology eventually gets to AI right now, and the first question is usually some version of: how do we add AI to what we already have?

That question makes sense, but I think it often starts one step too late.

There is a meaningful difference between adding an AI feature to an application and having an application that is actually capable of participating in an AI-driven workflow. A chatbot, natural-language search feature, or summarization tool can certainly be useful, but the larger opportunity appears when AI can access business information, understand context, interact with existing systems, and take meaningful action.

Consider something as straightforward as customer service. An AI assistant that answers a question about your return policy is one thing. An assistant that can identify the customer, retrieve the correct order, determine whether a return is permitted, initiate the appropriate workflow, and escalate an exception to the right employee is something entirely different.

At that point, the AI model is only one part of the application.

The real challenge becomes whether the underlying software can provide reliable access to data, expose the right actions, enforce permissions, and support the rules that govern what the AI should and should not be allowed to do.

This is where I think a lot of organizations are going to discover that their AI problem is actually a software problem.

Many existing applications were built around a human user clicking through screens. The data may technically exist, and the business rules may technically exist, but they are buried inside interfaces, old code, databases, spreadsheets, or processes that were never designed to be accessed programmatically.

Making those systems AI-ready might mean building APIs, creating better integrations, reorganizing data, exposing existing functionality in a more structured way, or in some cases replacing parts of an application altogether.

It doesn't necessarily mean rebuilding everything.

But it does mean businesses are going to have to ask a new question about the software they already depend on:

Can our existing systems actually support the work we want AI to do?

As AI moves from answering questions to participating in real business processes, that question is going to become increasingly important.

Working Software Can Still Become a Liability

The second reason companies are going to build has much less to do with new functionality and much more to do with the applications they already have.

Countless business systems run today and still do exactly what they were originally designed to do. Employees log into them every morning, customers use them, transactions flow through them, and from the outside there may be no obvious reason to replace them.

The issue is what sits underneath.

The application may depend on a framework that is no longer actively supported, libraries that are increasingly difficult to update, infrastructure that was designed around older assumptions, or years of custom modifications that make even routine upgrades risky.

In other cases, the application itself may be perfectly functional, but institutional knowledge around it has disappeared. The person who originally built it is gone. Documentation is incomplete. Nobody is entirely sure what will break if a particular component is changed.

This is where "it still works" starts to become a fairly low bar.

An application doesn't have to fail before it becomes a business risk. If keeping it patched is getting harder, if security updates require increasingly complicated workarounds, or if every change carries a disproportionate amount of risk, then the organization has a legitimate reason to evaluate whether the software can continue supporting the business for another five or ten years.

Security is a particularly important part of that conversation.

Older software is not automatically insecure, just as newly written software is not automatically secure. A poorly designed new application can introduce plenty of risk on its own. But software built around unsupported components or architectures that are difficult to update creates a very different maintenance challenge than a modern system designed around current security practices.

And as expectations around cybersecurity continue to increase, businesses are being asked to pay closer attention to access controls, patching, logging, monitoring, dependencies, and how quickly vulnerabilities can be addressed.

At some point, the effort required to continually compensate for an aging platform begins to compete with the effort required to modernize it.

That does not mean the answer is always a massive rewrite. In fact, in many cases that would be the wrong approach. An organization might replace a customer-facing interface while keeping a stable back-end system, modernize one particularly problematic component, or gradually move functionality onto a newer architecture over time.

The objective shouldn't be to replace software because it is old.

It should be to determine whether the organization can continue to secure, maintain, and improve the application with confidence.

That is a very different business case, and I think it is going to become one of the more common reasons companies invest in custom development over the next several years.

Companies Are Going to Reconsider What They Rent

The third reason is less technical, but potentially just as disruptive.

Over the past twenty years, businesses have moved aggressively toward software-as-a-service. In many cases, that has been an enormous improvement over the old model. Instead of installing and maintaining software internally, companies can subscribe to a mature platform, let the vendor manage the infrastructure, and continuously benefit from new features.

There is a reason SaaS became the dominant software model.

But it has also created an interesting situation where businesses now rent an enormous amount of the functionality they depend on every day, often indefinitely.

You start with a handful of users and a relatively inexpensive plan. Then the team grows. You need another feature. That feature requires a more expensive tier. Another department needs access. You add another platform to solve something the first one doesn't do particularly well, then another product to connect the two.

Over time, the stack gets larger, the recurring cost goes up, and employees may still be using spreadsheets or manual processes to bridge the gaps. Crazy! This is where custom agentic AI solutions make the most sense - streamlining business operations..

This doesn't mean companies should start rebuilding every SaaS product they use. Nobody needs to recreate every feature of Salesforce, Slack, QuickBooks, or whatever other mature platforms happen to be part of their stack.

But there is a more focused question that I think more companies are going to start asking:

Are there capabilities we currently rent that would make more sense for us to own?

The distinction is important.

If a company is paying for an enormous software platform because it needs three relatively narrow capabilities, the alternative isn't necessarily to recreate the entire platform. It may be to build a focused application around the specific workflow the business actually cares about.

Likewise, if an internal process currently requires three SaaS products, multiple integrations, a spreadsheet, and someone manually moving information between them, there may be an opportunity to simplify the workflow with a purpose-built system.

This is where AI-assisted development starts to affect the economics.

The difficult parts of software development haven't disappeared. Applications still need to be designed properly, requirements still need to be understood, data needs to be handled carefully, and someone still has to test, secure, deploy, and maintain what gets built.

But AI is already changing how much time developers spend on certain parts of that work, and I expect that impact to grow.

If the cost of producing a focused business application comes down while SaaS licensing continues to be a recurring expense, some projects that would have been dismissed five years ago may deserve another look.

The comparison also needs to be made correctly.

A company shouldn't compare the cost of building an application against a single year of software licensing. It should look at the total cost of that decision over three, five, or even ten years, including implementation, maintenance, hosting, integrations, security, and whatever operational benefit one approach provides over the other.

Sometimes SaaS is still going to win that comparison easily.

But not always.

And the fact that the answer is becoming less obvious is what makes software ownership an increasingly interesting conversation.

AI Is Changing the Economics of Software Development

Most discussion about AI and software development focuses on how much faster developers can write code.

That's certainly part of what's happening, but I think the larger impact may be what companies decide is worth building in the first place.

An internal application that could never justify a large development budget may become realistic.

A modernization effort that seemed too expensive to undertake all at once may become easier to approach incrementally.

A workflow spread across several SaaS platforms may become a candidate for consolidation.

And companies that want AI to participate more deeply in their operations may discover that improving their underlying applications is a prerequisite to getting there.

This doesn't mean custom development suddenly becomes easy.

In many ways, writing code was never the hardest part of building useful software anyway.

Understanding how the business actually operates, defining the right workflow, dealing with bad data, managing edge cases, connecting systems, designing for security, and making sure the application behaves reliably in production are still the parts that determine whether a project succeeds.

AI can accelerate portions of the development process, but it doesn't remove the need for good architecture or good judgment.

What it does do is shift the economics enough that organizations should revisit assumptions they may have made when development was slower and more expensive.

The Build-Versus-Buy Conversation Is Changing

None of this leads to the conclusion that businesses should suddenly start building everything themselves.

If anything, the right software strategy is probably going to become more selective.

Some applications absolutely belong as SaaS products. Some existing systems simply need better integrations. Some older platforms can continue operating perfectly well with the right maintenance and security practices.

But there will also be applications that need to become more accessible to AI, legacy systems whose technical foundations have become too risky to maintain, and business processes where continuing to rent the underlying software simply stops making financial or operational sense.

The point isn't that building is always better.

The point is that the reasons to build are changing.

Over the next several years, I think more companies are going to find themselves asking three questions:

Can our software support the AI capabilities we want to introduce?

Can we continue to secure and maintain the software we already have?

Are we renting a capability that would make more sense for us to own?

Those are three very different questions, but each can lead to the same conclusion: a software decision made years ago may no longer be the right decision today.

Over the next few posts, I'm going to look at each of these areas separately, starting with what it actually means to make an existing application AI-ready, then looking at when older software becomes a security and maintenance liability, and finally at how companies should think about the economics of building versus continuing to rent software.

Because the next wave of custom software development may not be driven primarily by companies inventing entirely new products.

It may come from companies looking at the software they already use and realizing that the equation has changed.