Technology Changes. Business Problems Don’t.

I wasn’t planning on starting another software project last weekend. In fact, I was doing my best not to. I’ve already got Zindl moving along, my DevExpress presentations and blogs, client work to deliver, mobile apps to test and the usual collection of things that somehow end up on my list. So naturally, while trying not to start anything new, I registered another domain.

The whole thing started while I was moving my 1949 Morris Minor into storage. I had motorcycles to shuffle around, sheds to organise, garage space to reclaim and the usual collection of tools, parts and “I’ll need that one day” items spread across more places than is sensible. Somewhere in the middle of all that I found myself standing there thinking, “I know I’ve got one of those somewhere, but where did I put it?”

That was the moment ShedBase was born.

The idea is simple enough. If you have multiple sheds, storage units, workshops, garages, containers or toolboxes, ShedBase helps you remember what you own and where it lives. Not in a complicated warehouse-management-system kind of way, but in the very human, very practical “where did I put the torque wrench?” kind of way.

What made me smile was not the idea itself. It was the realisation that I had solved almost the same problem before, a very long time ago.

Back in 1989 I wrote my first commercial application. It was not written in C#, Delphi or anything remotely modern. It certainly was not assisted by AI. It was written in Compiled QuickBasic for British Telecom, where my dad worked. The technology belongs in a museum now. DOS screens, floppy disks, manual deployments and all the fun that came with writing software before the Internet became part of everyday life.

The problem, though, has not aged at all.

That first application existed to track equipment. It answered the same basic question: where is it? Which location is it in? Who has it? When was it last seen? It was not glamorous software, but it solved a real problem for real people.

Thirty-seven years later, I’m standing in front of a shed asking the same question.

That is the bit I find fascinating. Over my career I have worked on workshop systems, warehouse systems, mobile apps, asset tracking, customer portals, APIs, reporting tools, service systems, stock systems and business dashboards. On paper they all sound different, and technically they often are. Different industries, different databases, different devices, different frameworks.

Underneath, though, the problems repeat themselves.

People want to know where things are. They want to stop entering the same data twice. They want to know who did what, when it happened, what it cost, what still needs doing and where the next bottleneck is. The user interface changes, the platform changes and the deployment model changes, but the pain points are surprisingly familiar.

I think developers sometimes forget this because we live so close to the technology. We talk about frameworks, languages, cloud platforms, AI models, database choices and architecture patterns because that is our craft. Those things matter, but they are rarely where the customer conversation starts.

No customer has ever rung me and said, “Paul, I really need a .NET MAUI application.” They do not usually care whether something is written in Blazor, MAUI, Delphi, C# or anything else. What they say is much simpler. “We are wasting too much time looking for things.” “We are entering the same information twice.” “Nobody knows who has that piece of equipment.” “There has to be a better way.”

That is the real requirement.

The technology is how we solve it.

AI has made this more obvious to me, not less. I use AI every day now, and it has changed how quickly I can move from idea to working software. It helps with code, structure, testing, documentation and even challenging assumptions when used properly. What it does not do by itself is decide which problems are worth solving.

That still comes from experience.

It comes from listening to customers for decades. It comes from recognising patterns. It comes from seeing that the problem someone describes today is often a modern version of something another customer struggled with twenty years ago. The tools are better now, but the judgement still matters.

That is why I still enjoy building software after all these years. It is not because I want to chase every new framework or rewrite everything every time the industry gets excited. It is because every now and then a problem appears that is simple, practical and annoying enough to be worth solving.

ShedBase may become a commercial product. It may just solve a problem I have created for myself by owning too many sheds, too many tools and a Morris that apparently needs its own postcode. Either way, it has already reminded me of something important.

I have never really been in the business of writing software.

I have been in the business of solving problems.

The languages have changed. The machines have changed. The deployment models have changed. AI is now helping us build faster than ever before. But somewhere, right now, someone is standing in front of a shed, workshop, warehouse or storage unit saying the same thing someone else was saying in 1989.

“I know I’ve got one of those somewhere.”

Some problems never go out of fashion.

Those are usually the ones worth solving.