Nobody decides to become a software company

When your digital tech stack becomes an engineering operation

Here is a planning meeting that happens in a lot of digital teams. Five people on the team. Two of them are effectively booked for the quarter on keeping integrations working, and if you asked the wider organization to name those integrations, nobody could.

No one chose that. It arrived incrementally. Most organizations do not decide to run a software engineering function, they become one through about four purchases, each of which was reasonable on the day it was signed.

The four purchase orders

One. A content management system chosen for editorial control. Sensible.

Two. A separate search product, because site search was the top complaint in the last survey. Also sensible.

Three. A personalization or analytics layer, because someone senior asked what we know about our visitors. Hard to argue with.

Four. An AI answer layer, because the board asked what we are doing about AI. Reasonable given the pressure.

Every one of those was defensible in isolation. Together, they are a distributed system, and your team now owns the integration surface between four vendors who ship on four different schedules. That surface is the product nobody bought and everybody maintains.

The costs that never appear on an invoice

Capacity. In the teams we work with, somewhere between 20% and 30% of technical capacity ends up going to maintenance, upgrades, and integration repair rather than to improving the experience. That is not waste caused by bad engineering. It is the running cost of the architecture.

Speed. The clearest symptom is how long a small change takes. When a simple A/B test needs three to six months of sandbox testing because nobody can predict what it touches, the platform has stopped being a platform. It is a dependency you manage.

Skills you never planned to hire for. Integration work, upgrade coordination, and release management are real disciplines. If they were not in the plan, they are being absorbed by people hired to do something else, usually your most senior person.

Timing you do not control. Four vendors, four roadmaps. One of them will deprecate something you depend on, and it will not be a quarter you chose.

Best of breed is not the same as best outcome

To be fair to best-of-breed: sometimes it is the right answer. Where a capability is genuinely differentiating for you, and where you have the engineering depth to own it, assembling the best parts wins.

The honest question is narrower than which product is strongest in its category. It is which combination your team can actually operate at the pace the organization now expects. A slightly less capable component that your team can change on a Tuesday often beats a market leader that needs a release cycle.

The matrix nobody costs properly

Before the next purchase, take the capabilities you depend on and write three columns against each one. Content management, search, personalization, accessibility, security and traffic filtering, AI answers, analytics.

• Who owns it
• What it costs a year, licence plus the people time it consumes
• Who fixes it at 4pm on a Friday

The third column is the one that changes minds. It is also the one that never makes it into a business case.

What to do next

Run the matrix on what you already have before you evaluate anything new. Then compare two numbers: the share of your team's time spent operating the stack, versus the share spent improving what visitors experience. If the first number is bigger, the next purchase will not fix it. Consolidation might.

Nobody sets out to become a software company. It is worth checking, once a year, whether you have been handed the job anyway.