DEV Community: Corin Gutteridge

“The Death of Business Software (As We Know It)”

Corin Gutteridge — Wed, 04 Mar 2026 19:30:32 +0000

Change is blowing on the wind. As the Economist noted (Feb 14th), shares of publicly listed business software companies are down 20%. Both they, and the private-equity firms which funded them had been making good coin from software that was sold like a subscription, with fat fees coming in annually. But it’s not as if companies were getting good value from this model. Quite frankly, they’ve been getting ripped-off. They’ve largely suspected it, too. But what choice did they have? They needed software, and there weren’t many viable options. But now the signs of change are becoming more evident, suppressing the earning power of legacy business software behemoths.
The deeper problem is that the economics of enterprise software were designed for a different technological era. When computing was scarce and development slow, it made sense to amortize the cost of building large systems across thousands of customers. But computing is no longer scarce. Development tools are no longer slow. The cost of tailoring systems to the particular needs of a company has fallen dramatically, while the cost of bending an organization around rigid software has remained stubbornly high. In other words, the logic that justified mass-produced enterprise software is quietly collapsing. If anything, the economics now favour the opposite approach: systems assembled quickly and cheaply around the real processes of a business rather than forcing the business to conform to a prefabricated template.
This shift is still in its early stages, but its direction is unmistakable. Modern development frameworks, open-source infrastructure, no-code platforms, and increasingly capable AI tools are lowering the cost of building and adapting software at a breathtaking pace. What once required years of planning and armies of consultants can increasingly be prototyped in weeks. Instead of paying rent to a distant vendor for the privilege of using their product, companies can begin to own the logic of their own operations again. That logic—the workflows, rules and data that actually define a business—is where the real value resides. The software itself is merely a means of expressing it.
None of this means the giant software firms will vanish overnight. SAP, Oracle, Salesforce and their peers still command vast installed bases and deep customer relationships. But their dominance rests on a model that is beginning to look less like an inevitability and more like a historical accident. For decades companies accepted the constraints of enterprise software because they had little alternative. Now alternatives are emerging, and once customers realize that the old model was never the only option, the gravitational pull of those legacy systems will weaken.
The death of business software, then, will not come as a dramatic collapse but as a slow erosion. The giants will still exist, but their role will shrink—from indispensable platforms to merely one set of tools among many. The real shift will be psychological. Companies will stop asking which software to buy and start asking how best to build systems that reflect how they actually work. When that happens, the centre of gravity in enterprise technology will move decisively away from the vendors and back toward the businesses themselves.
And that, for the trillion-dollar business-software industry, is a far more dangerous development than a temporary dip in share prices.

"Own the Stack" (Part 3) - Build Better Software, and Have Happier Clients

Corin Gutteridge — Wed, 18 Feb 2026 22:26:28 +0000

Part 3 — From Projects to Systems: Building a Stack You Actually Own

Let’s put the pieces together:
A stack you actually own has five layers:
• Experience layer – UI, dashboards, APIs
• Application layer – workflows, use cases, orchestration
• Domain layer – business concepts, rules, policies
• Platform layer – the accelerator that assembles systems
• Infrastructure layer – data, hosting, integrations

Most teams focus on:
• UI choices
• Framework choices
• Cloud choices

Very few invest in:
• A real domain model
• A real platform layer

And that’s why most teams:
• Ship slower over time, not faster
• Accumulate accidental complexity
• Get stuck in rewrite cycles
• Stay dependent on tools instead of owning their architecture

What changes when you own the domain + platform

When your domain is explicit and clean:
• Your system has a stable core
• Change becomes safer
• Business logic stops leaking everywhere

When your platform is yours:
• Delivery becomes repeatable
• Architecture becomes intentional
• Speed becomes structural, not heroic
• “Custom” stops meaning “fragile”

Together, they let you:

Stop building projects. Start building systems.

The real meaning of “owning the stack”
It’s not about:
• Writing everything yourself
• Avoiding frameworks
• Rebuilding databases or clouds

It is about:
• Owning the business model in software (domain)
• Owning how systems are assembled and evolved (platform)
• Keeping infrastructure replaceable
• And keeping UI flexible

That’s the difference between:
• Using a stack
• And owning one.

‘#customsoftware #customerp #businesssoftware #developers #opensource #nocode #softwareplatform

"Own the Stack" (Part 2) - The Right Platform is Key

Corin Gutteridge — Wed, 18 Feb 2026 00:58:15 +0000

Part 2 — The Platform Layer Is the Key to Owning the Stack

In Part 1, we talked about why the domain is the heart of any serious system.

But here’s the problem:
Even teams with clean domain models still:
• Ship slowly
• Rewrite the same scaffolding
• Treat every project like a one-off
• Burn time on plumbing instead of outcomes

It’s why custom builds get a bad name. But that’s not a domain problem. It’s a problem of inadequate tools.

It’s a platform problem.

Without a proper platform, you’re forced to dig down and make fresh code, and coding is always too time-consuming. You’re forced down to a level of detail you shouldn’t have to be dealing with. You need a platform layer that is in a high-level enough language to be easily responsive.

What the platform layer actually is

The platform layer sits between:
• Your domain + application logic
• And your infrastructure + frameworks

It provides:
• Reusable patterns and primitives
• Generators and scaffolding
• Workflow engines, UI composition, integration glue
• The rules of assembly for systems

In short:
The platform layer defines how software gets built, not just what it does.

Why this layer determines whether you “own” the stack
If you don’t control the platform layer:
• Your architecture is shaped by vendor constraints
• Your delivery speed is capped by tool friction
• Your system’s structure is someone else’s opinion

If you do control it:
• You assemble systems instead of starting from zero
• You reuse patterns instead of rewriting foundations
• You evolve architecture without burning everything down
• You turn “custom software” into a repeatable process

That’s real ownership.

The economics shift

Without a platform layer:
• Every project is bespoke
• Estimates are fuzzy
• Timelines slip
• Margins suffer

With a platform layer:
• You productize your delivery
• Scope becomes more predictable
• Speed increases without cutting corners
• You build leverage into engineering itself

The platform layer is what turns software from craft into systems production.

What part of your current stack do you end up rebuilding on every project—and what would it look like if that were part of your platform instead?

'#customsoftware #erp #customerp #businesssoftware #softwarestack #architecture #softwareengineering #devtools #productivity

Next in Part 3: How domain + platform together create something much bigger than “a project”: a delivery system you can scale.

“Own the Stack" (Part 1) - The Domain Layer is Where You Deliver True Added-Value for Your Clients

Corin Gutteridge — Mon, 16 Feb 2026 21:57:53 +0000

Part 1 — "Owning the Stack" Starts with the Domain

(This post ended up being a bit long, so I’m splitting it up into 3 parts)

Too much so-called “customization” is actually jut fiddling around the edges with some UI. Too often it turns out the project is actually doomed, and you’re just rearranging deck chairs on the Titanic. To truly customize – and deliver value for your clients – you need to get deeper into the stack, where real value lies, and go even deeper to get proper control.

It’s useful to think of a Software Stack, akin to the OSI Network Stack. It can be modeled a number of different ways (since there isn’t one set standard, like OSI), but I would suggest we look at it like this:
5. Experience layer – tailored UI, dashboards, APIs
4. Application layer – workflows, processes, orchestration
3. Domain layer – the business model and rules
2. Platform layer – the accelerator that turns models into systems
1. Infrastructure layer – data, hosting, integrations

If you build software for clients or internal teams, you’ve probably seen this pattern:
• The UI changes every year
• The tech stack changes every few years
• The business rules somehow live forever

Most systems are built as if the domain is an afterthought.
The domain layer is the part that actually matters. It’s what will really make the difference for the client, and it’s where you can provide the most added-value.

The domain layer is:
• The business concepts
• The rules and constraints
• The policies and invariants
• The meaning of the data

The domain layer is where you are at the whiteboard with the client, defining the context of their business, and working in the terms they actually care about.

This is the one part of the system that:
• Survives rewrites
• Outlives frameworks
• Defines whether the software is correct or not

If your domain is:
• Scattered across controllers
• Hard-coded into UI flows
• Implicit in database schemas
• Or locked into a vendor’s data model

…then you don’t really own the system. You’re just maintaining a shape that happens to work right now.

Owning the domain means:
• You can change UI without changing meaning
• You can change infrastructure without rewriting business logic
• You can add workflows without breaking core rules
• You can explain the system in business terms, not just code paths

In other words: the domain is your client’s real IP. If you don’t own this layer, you’re not building a system. You’re just customizing one.
Everything else is just delivery mechanics.

The first step to owning the stack - Before you think about tools, platforms, or frameworks: make the domain explicit, coherent, and independent.

The domain layer is the one part of your system that should outlive frameworks, UI rewrites, and infrastructure changes. It’s where the meaning of the business lives. If it’s explicit, clean, and independent, your system can evolve without losing its soul. If it isn’t, you’re usually one “big refactor” away from accidental rewrites and broken rules.

So I’m curious: where does your business logic actually live today — cleanly in a domain layer, or scattered across controllers, UI flows, and database schemas?

Next in Part 2: To bring true value to the client in the Domain Layer, you need control of the key development piece - the Platform Layer—and that’s where real leverage lives.