Move over SaaS, it's time for AI software architecture

The last thirty years of enterprise software have been built on a lie. Not a malicious one,  but a convenient one that has suited software vendors far better than their customers. The lie is this: that the way to run a business is to buy software designed for someone else's business and then organise your people and processes around it.

We called it digital transformation, but for most organisations it was really just digital conformity. SaaS was supposed to democratise enterprise software. In some ways, it did. It removed the need for costly on-premise infrastructure and made sophisticated tools accessible to organisations that couldn't previously afford them. But the heart of the SaaS business model contains a contradiction that vendors don’t want to talk about.

Bloat, bloat, and more bloat

SaaS software grows by adding features. More features attract more customer segments and verticals. More features mean the product can be positioned against more competitors. Most importantly for vendors, more features mean higher prices. The result is software that does a hundred things adequately and almost nothing exceptionally.  Bloated, complex, and expensive software, where you pay for 100% of the functionality but only use 20% of it.

Lock-in with an extra serving of lock-in

Worse still, every application is designed to be a system of record for its domain. Your CRM owns your customer data. Your project management tool owns your delivery data. Your finance application owns your commercial data. They are silos by design because data lock-in is not a bug in the SaaS model, it's a feature. The harder it is to leave, the longer you’ll stay.

Take marketing technology as an example. Organisations end up with a martech stack of 50-plus tools, each operating at a fraction of its capability, with humans acting as the integration layer between them. We've built an entire discipline called marketing operations, dedicated to making disconnected software talk to each other. This all stems from the core problem - when you buy software first and design your process around it, you are outsourcing your operational model to a vendor whose priorities don’t align with yours.

Think about a professional services firm. The real business process runs end-to-end: from the first conversation with a prospect, through the pitch and proposal, commercial negotiation, contracting, project setup, delivery, and retrospective. That’s a continuous process with a shared goal: delivering value to the client and capturing value for the firm.

In the current model, that process is fragmented across a marketing application, a sales application, a legal application, a commercial application, and a project delivery application. Each with its own data model. Each with its own interface. Each with its own vendor relationship and renewal negotiation. And humans are running around in between, manually moving information from one system to the next, introducing errors, delays, and friction at every handoff.

Nobody designed this. It accumulated. Each tool was bought to solve a specific problem, and the connections between them were never properly resolved because fixing them would require either expensive systems integration and software development, work or buying yet another platform to sit on top. Most of that work often gets left out of the business case for a new software purchase (if one ever existed).

The software landscape has changed dramatically

The cost of producing custom software has collapsed. Not to zero – that’s hype, and anyone selling you that story is oversimplifying. But the combination of AI-assisted development tools and a new generation of developers who can work with them has forever changed the economics of software development. What previously required a team of senior engineers working for months can now be produced by a small, capable team working in days or weeks.

At A Few Good People, we have been living this shift directly. We have been building our own internal software, the tools that run our business, using AI-enabled development. The experience has taught us something important: the bottleneck is no longer the cost of code production. It’s the quality of the business process thinking that precedes it.

It’s occurred to us that this shift has significant implications.

AI software architecture: a different model

When the cost of custom development drops dramatically, the rational response is not to build cheaper versions of the same SaaS tools you’re already buying. It’s to rethink the architecture entirely.

What we are calling AI software architecture is built on a different set of principles:

1.        Process first, software second.

Design the optimal end-to-end business process before a single line of code is written. The software reflects the process, not the other way around. Instead, you focus your energy on defining the most effective business process to efficiently meet your customers’ needs.

2.        Separated data and application layers.

The organisation owns its data and software outright. Data resides in a unified data layer that sits beneath the application. The application can be modified, extended, or replaced without touching the underlying data. That’s the opposite of SaaS lock-in.

 3.        Continuous, rapid iteration.

Traditional software development demands exhaustive requirements documentation because the cost of mistakes is high. In this model, changes are small, continuous, and reversible. An assumption that turns out to be wrong costs hours or even minutes to fix, not months. The safety net is embedded in the version-control and rollback model; it’s not managed through a cumbersome process. Think of it as Agile on steroids. Two-week sprints look glacial by comparison.

4.        End-to-end by design.

Rather than multiple applications connected by integrations, a single application governs the entire business process. The pitch, the proposal, the contract, the project, and the retrospective are different views of the same system, reading from and writing to the same data. The integration problem largely disappears because there is nothing to integrate.

 5.        Security and governance by design, not by assembly.

In the fragmented SaaS model, governance is a patchwork. Each vendor or application has its own security approach, data processing agreement, and access control model.  In a microservices model, data and security is scattered throughout the system, requiring complex management. A unified architecture with a single owned data layer allows security, compliance, and access governance to be designed once and applied consistently across the entire business process. For regulated industries in particular, this is a significant advantage over the current model.

 6.        AI agents as operational infrastructure.

With a unified data layer, AI agents can operate across the full business process in ways that are structurally impossible when data is fragmented across vendor systems. The data model becomes the intelligence layer.

 Who does this model work for?

Let's be honest, large enterprises will get to this eventually, once they have navigated the organisational politics, the cultural change, the legacy system and all the complexity that implies. But don't hold your breath.

The more interesting opportunity is in mid-market organisations, businesses with 50 to 1000 people, who have always been caught in the worst position. Too large to run on simple tools, too small to afford enterprise SaaS or the systems integrators needed to make it work. They’re currently managing as best they can: buying mid-tier applications, using people as the orchestration layer, and structuring their operational processes around the software's limitations rather than their customers' needs.

For these organisations, AI software architecture is not an incremental improvement. It’s a total redefinition of what is economically possible. Custom software that exactly reflects their business model, their unique process, their competitive differentiation, and their way of working is now within reach. Not someday. Now.

The technology is here now, but that’s not the hard part

The hard part is the thinking that has to precede it. Designing a genuinely optimal business process takes rigour, alignment, and the organisational courage to question how things have always been done. It requires someone who understands both the business problem and the technical implications of different architectural choices. That’s a skill set that sits uncomfortably between traditional consulting and traditional software development, and is currently rare.

The organisations that move first on this will not be the ones with the largest technology budgets. It’ll be the ones with the clearest thinking about what their business is actually trying to do, and the willingness to build software that reflects that, rather than adapting to software built for someone else.

 That is the opportunity. And it’s larger than most people currently appreciate. SaaS companies have been taking a bath in their valuations lately, and after developing our own software, we can see why.

We're not in Kansas anymore, Toto.