“Own the Stack So You Deliver True Added-Value for Your Clients”

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.