The Return of Custom Software: Why the Post-SaaS Era Looks a Lot Like 2005

The math was simple and brutal: custom development meant a team of eight to twelve engineers working for twelve to eighteen months, followed by an indefinite maintenance tail.

Even a basic system would cost seven figures before it processed a single lead. Buying a SaaS subscription was faster, cheaper, lower risk, and came with continuous updates. The build-versus-buy debate was effectively settled. Buy won.

A decade later, that settlement is coming undone - not because SaaS has become bad, but because the economics of building software have changed so fundamentally that the old calculus no longer holds.

And if you pay close attention to what is happening in enterprise technology right now, the signals are everywhere.

The cracks in the SaaS consensus

Let me start with the demand side. Industry surveys consistently show that roughly six out of ten enterprise buyers regret at least one significant SaaS purchase made in the past eighteen months. That is not a fringe finding - it surfaces across multiple research sources, from Gartner to Capterra to independent analyst reports.

The reasons are familiar to anyone who has sat through an enterprise software renewal negotiation: the product does eighty percent of what the business needs but the remaining twenty percent requires painful workarounds, customization options are limited and expensive, the pricing model has shifted in ways that penalize growth, and switching costs make leaving feel impossible.

Meanwhile, the supply side is under unprecedented pressure.

The SaaS index has materially underperformed the broader market since mid-2025. Software companies that once commanded premium valuations are being repriced as investors question whether traditional growth assumptions still hold.

The narrative varies depending on who you ask - some point to AI eating into software budgets, others to seat-based pricing models breaking down as headcounts shrink, others still to a general maturation of the category. But the directional conclusion is consistent: the era of automatic SaaS growth is over.

None of this means SaaS is dying.

Global software spending continues to grow, projected to exceed $1.4 trillion in 2026. Enterprises are not going to rip out their ERP systems or abandon their CRMs. The systems of record that underpin critical business processes - finance, HR, supply chain, customer management - are deeply embedded and switching them carries enormous operational risk. That is not changing.

What is changing is the layer above the systems of record. The workflow tools, the point solutions, the departmental applications, the integration logic, the custom dashboards and reporting layers, the automation sequences. This is where the SaaS model is most vulnerable - and where custom development is making a comeback in a form that would have been unrecognizable five years ago.

What made SaaS win and why those advantages are eroding

To understand why the equation is shifting, it helps to recall why SaaS became dominant in the first place. There were essentially four reasons.

Cost of development was prohibitive. Building custom software required large teams of expensive specialists working for extended periods. A mid-complexity business application might cost $500K to $2M to build, plus ongoing maintenance at 15-20% of that annually. SaaS spreads these costs across thousands of customers, making the per-customer cost a fraction of custom development.

Time to value was measured in quarters, not days. Custom development projects took months before delivering anything usable. SaaS products could be deployed in weeks. For a business that needed a solution now, waiting six months for a custom build was not competitive.

Maintenance was someone else's problem. SaaS vendors handled infrastructure, security patches, feature updates, compliance. A custom-built application meant your team owned all of that forever. For most organizations, this operational burden was a dealbreaker.

The talent pool was narrow. Building good software required experienced developers who were expensive and hard to find. SaaS allowed companies to access world-class engineering without hiring world-class engineers.

Now look at how AI-assisted development is eroding each of these advantages.

Development cost is dropping dramatically.

Industry surveys from 2026 show that over 90% of software development companies now use AI tools across the development lifecycle, with a majority expecting AI to reduce project budgets by 10-25%. But those figures understate what is happening at the leading edge.

Teams using AI agents for end-to-end development - not just code completion but full-cycle feature delivery - are reporting productivity gains of 3x to 10x.

A project that would have required eight developers for six months can now be delivered by a small, senior team in weeks. The cost of a custom-built workflow application has dropped from the seven-figure range to something that competes directly with an annual enterprise SaaS license.

Time to value has compressed by an order of magnitude. When a senior engineer working with AI agents can produce a functional prototype in days rather than months, the speed advantage of deploying an off-the-shelf SaaS product largely disappears. For many use cases - particularly internal tools, workflow automation, and data integration layers - a purpose-built solution can be designed, built, and deployed faster than a SaaS product can be evaluated, procured, configured, and integrated.

Maintenance is becoming manageable. AI-assisted development does not just accelerate the initial build - it also changes the economics of ongoing maintenance. Code review agents catch issues earlier, automated testing covers more ground, and AI-assisted debugging reduces the time to resolve production problems. The maintenance burden has not disappeared, but it has shrunk enough that it no longer automatically tips the scale toward buying.

The talent equation has inverted.

This is perhaps the most counterintuitive shift. SaaS was supposed to democratize access to great software by removing the need to hire great engineers. Instead, AI is democratizing the ability to build great software by amplifying the productivity of the engineers you do have.

A single senior developer with the right AI tooling can now produce output that previously required a full team. You still need talent, but you need less of it - and the talent you need is more readily available when each person can do the work of several.

The new build-versus-buy framework

Let me be precise about what I am not arguing. I am not arguing that every enterprise should abandon SaaS and build everything from scratch. That would be as foolish as the inverse claim that every enterprise should always buy.

The point is that the decision boundary has moved - and for a meaningful category of business needs, building is now the rational choice where it was not before.

Here is how I think about the new framework.

1. Buy when the problem is commodity and the data is not your advantage.

Email, calendar, basic document management, accounting for standard workflows, standard HR processes - these are solved problems where the SaaS vendor's scale genuinely benefits you. The tooling is mature, the integrations are built, the compliance certifications are done. Building a custom email system would be insane, and AI has not changed that.

2. Build when the workflow is your competitive differentiator.

If the way your organization processes orders, manages client relationships, handles approvals, or orchestrates operations is genuinely unique and that uniqueness creates business value, then forcing it into a generic SaaS product means trading competitive advantage for convenience. With AI-assisted development making custom builds fast and affordable, that trade no longer makes sense.

3. Build when you need deep integration with proprietary data.

The strongest defensive moats in software - the ones that best protect companies from competitive erosion - are proprietary data, deep domain specialization, and network effects. In a SaaS model, those moats belong to the vendor. In a custom development model, they belong to you. A custom workflow system that learns from your specific data, integrates with your specific systems, and encodes your specific business rules creates a compounding advantage that no SaaS product can replicate.

4. Build when you are paying for an enterprise license but using a fraction of the features.

This is more common than most organizations admit. Large SaaS platforms are feature-rich by design - they have to serve thousands of different customers with different needs. The result is that many enterprises pay for enormous capability they never use, while struggling to make the platform do the one specific thing they actually need. When custom development costs drop below the annual license fee for an underutilized SaaS product, the math speaks for itself.

5. Adopt a hybrid approach when the system of record matters but the experience layer does not.

This may be the most practical pattern for most enterprises. Keep Salesforce as your CRM system of record, but build custom agent-powered workflows on top of it that interact with the data through APIs. Keep SAP as your ERP backbone, but build purpose-built interfaces and automation layers that serve your specific operational needs. The agentic architecture emerging across the industry explicitly supports this pattern: systems of record at the bottom, an orchestration and agent layer in the middle, and custom experience and workflow layers on top.

What this means for software houses and delivery organizations

If you run a software house - as I do - this shift is simultaneously a threat and an opportunity of the first order.

The threat is obvious: if clients can build simple applications themselves using AI tools, a portion of the work that software houses have traditionally done - the straightforward CRUD applications, the standard integrations, the template-based implementations - will evaporate.

The SaaStr commentary that someone built a functional kanban board with Claude Cowork in an afternoon, prompting a $300 million drop in Monday.com's market cap, illustrates the dynamic vividly. Simple software is becoming commoditized.

The opportunity is equally significant but less discussed. As the build-versus-buy equation shifts, enterprises will need partners who can deliver custom software at the speed and cost point that AI-assisted development makes possible.

But they will not need the kind of partner that puts fifteen developers in a room for twelve months. They will need partners who can deploy small, senior, AI-augmented teams that deliver outcomes in weeks.

This changes the delivery model fundamentally.

The engagement shifts from "here is a team, tell us what to build" to "here is the outcome you need, we will deliver it." The pricing shifts from time-and-materials to outcome-based or value-based. The team structure shifts from large cross-functional squads to small pods of senior people who orchestrate AI agents. The measure of success shifts from velocity and utilization to time-to-value and business impact.

For delivery leaders specifically, this means rethinking several things at once.

How do you scope an engagement when a three-person team can deliver in six weeks what used to take a ten-person team four months? How do you price it when the client's alternative is a $200K annual SaaS license? How do you staff it when the role profiles do not match your existing competency frameworks? How do you measure quality when the codebase was partially generated by AI?

These are not abstract questions. They are the operating reality for every software house that wants to remain relevant in 2027.

The real moats in the post-SaaS world

Let me close with a thought about defensibility, because this is where the implications get most interesting.

In the SaaS era, the moats that mattered belonged to vendors: proprietary data accumulated across thousands of customers, deep domain knowledge encoded in product logic, network effects from ecosystem integrations. Enterprise buyers were, in a sense, renting access to these moats. The value was real, but it was not theirs.

In a world where custom development is fast and affordable, the moats shift back to the enterprise itself. Your proprietary operational data, your unique domain knowledge, your specific integration landscape - these become the foundation of custom-built systems that grow more valuable over time precisely because they are yours.

An AI-powered workflow system trained on your data, integrated with your processes, and optimized for your specific use cases is not something a competitor can replicate by buying the same SaaS subscription you have.

This is not the return of 2005-era custom development, with its waterfall processes, bloated teams, and multi-year timelines. It is something new: fast, lean, AI-augmented custom development that builds on commodity infrastructure (cloud, APIs, open-source frameworks, foundation models) while creating bespoke value in the layers that matter.

The build-versus-buy equation has not merely shifted. It has been rewritten.

The age of automatically defaulting to "just buy a SaaS" is ending. What comes next is not a rejection of software-as-a-service, but a much more nuanced, strategic, and ultimately more powerful approach to the fundamental question every technology leader must answer: should we rent, or should we own?