Escaping WordPress: Why I Started Writing My Own Applications

For many years, my website was powered by WordPress. Like millions of other people, I appreciated how quickly it allowed me to publish content without having to build everything from scratch.

However, over time my website evolved beyond a simple blog.

I found myself wanting applications that WordPress wasn't really designed to provide. Some projects needed custom databases, others required specialised interfaces or unique workflows that didn't fit naturally into the WordPress ecosystem. While plug-ins could sometimes fill the gap, they often introduced complexity and compromises that felt increasingly uncomfortable.

Eventually I decided that, for these applications at least, it would be simpler to build them myself.

At first there was no grand architectural vision.

Each application was a completely independent PHP project. Every one had its own directory structure, its own configuration, its own navigation and its own way of doing things. That wasn't a deliberate design decision; it was simply the fastest way to get each new application working.

And it worked.

Every completed project taught me something new about PHP, HTML, CSS and JavaScript. As my confidence grew, so did my ambition. I stopped looking for plugins and started writing the functionality myself.

Looking back, those early applications were exactly what they needed to be. They solved the problems I had at the time.

The interesting thing is that none of them were particularly difficult to build.

The real challenge only appeared later.

As the number of applications grew, so did the amount of duplicated code. Every application had a header. Every application had a footer. Every application had navigation, configuration files, helper functions and countless small pieces of infrastructure that were almost identical from one project to the next.

Making a simple visual change suddenly meant opening half a dozen different projects and applying the same edit over and over again. Every improvement became repetitive. Every bug fix had to be repeated multiple times.

The problem was no longer writing software.

The problem had become maintaining it.

At that point I wasn't thinking about frameworks. In fact, I wasn't thinking about architecture at all. I was simply becoming aware that I was solving the same problems repeatedly, and that there had to be a better way.

That realisation would eventually lead me to build what became the Auspice Darer Framework—but that wasn't the goal when I started. The framework wasn't designed first and then used to build applications. Instead, it emerged naturally from the lessons learned while building those applications.

Looking back now, I think that's an important distinction.

The best architecture often isn't invented in advance. It's discovered by paying attention to the problems that keep coming back.