Why I founded StackTrack

Too often, innovation adds another layer instead of removing one, and that keeps raising the bar for what teams need just to operate effectively.

Complexity is additive

Too often, innovation adds another layer instead of removing one, and that keeps raising the bar for what teams need just to operate effectively.

What i saw in the enterprise

I saw that clearly during my career in enterprise environments. I worked on major cloud transformation efforts and helped build digital platform teams behind serverless and Kubernetes-based ecommerce platforms across many organisations, but two stand out because they sat inside businesses not usually seen as technology companies: a grocery retailer and a luxury fashion retailer. Both were ambitious platform programmes, backed by leadership willing to invest in doing things properly. But they also made something obvious to me: the level of developer experience and platform maturity large organisations can build is often out of reach for smaller teams.

What stayed with me from those environments was not just what we achieved, but how difficult it was to achieve it. Great developer experience does not appear by accident. It takes investment, engineering discipline, and time. That kept leading me back to the same question: how do smaller businesses cope when they do not have the same budget, headcount, or margin for error?

What stayed with me from those environments was not just what we achieved, but how difficult it was to achieve it. Great developer experience does not appear by accident. It takes investment, engineering discipline, and time. That kept leading me back to the same question: how do smaller businesses cope when they do not have the same budget, headcount, or margin for error?

Why smaller teams face a different reality

That question matters because cloud platforms can be powerful, but they can also be unforgiving. Many of the decisions that make sense in larger organisations are simply not practical for smaller teams. Costs can escalate quickly, technical debt builds quietly, and once complexity takes hold, it becomes expensive to unwind.

Observability is a good example. The most convenient options can become expensive quickly, while lower-cost alternatives often demand time and expertise that smaller teams simply do not have.

I have problems with platform orthodoxy

There is also a tension in the DevOps and platform engineering world that I have never been able to ignore. Internal developer platforms have become a major focus, but in some places platform teams have become too prescriptive about how software should be built, shipped, and operated. That approach never sat comfortably with me.

Good platforms should be invisible

Coming from a software engineering background, I have always empathised with developers dealing with clunky processes, awkward handovers, and platforms that demanded too much attention. My goal was never to make the platform the centre of their world. It was to build it around their needs, so they could stay focused on building products.

Some of the early automation was clunky, but the ambition was clear: reduce friction, shorten the path to productivity, and make the platform feel almost invisible. When it worked, new developers could get started quickly and contribute without spending days fighting setup, deployment workflows, or operational processes.

That is still how I think good platform engineering should be experienced.

Why I do not chase complexity for its own sake

I have never been especially interested in building dashboards for the sake of it. They can be useful, but they can also consume effort that would be better spent solving underlying operational problems. I would rather invest in systems that are calm, clear, and easy to work with than in extra layers of visibility that compensate for unnecessary complexity.

In many ways, my career has sat across several worlds: software engineering, product thinking, DevOps, and systems engineering. That mix has shaped how I see the role of a platform team. The question I keep coming back to is simple: is your platform helping the engineering experience disappear into the background, or is it still everywhere — loud, flaky, and constantly demanding attention?

That question sits at the heart of how I think about StackTrack.

The philosophy behind StackTrack

I started StackTrack to make enterprise-grade platform thinking more accessible, without bringing enterprise-grade bloat along with it. I did not want to build a cookie-cutter platform or force customers into someone else’s idea of best practice. I want to build the platform you actually need, around real business needs, real delivery constraints, and real teams.

That distinction matters. Too many DevOps consultants assume the answer is always more tooling, more layers, and more moving parts. I believe the opposite is true. The less technology you have, the better. Beyond zero, every piece of technology is a compromise between capability, complexity, cost, and control.

I am a fan of serverless, and I am equally happy building with Kubernetes and Docker. These are not competing belief systems. They are tools, and the right choice depends on the needs of the business, the team, and the product.

That is the philosophy behind StackTrack: practical, tailored platforms that help engineers focus, reduce friction, and fit the business they serve.

That is the work I care about.