For years, I believed that every new version of my blog existed because technology had evolved. Responsive design arrived. Static site generation became popular. Search engines changed. Browsers became faster. Looking back now, I don't think technology was the real reason behind those iterations.
Every version of my blog represents a different stage in how I thought about constraints.
That may sound strange because we usually speak about constraints as obstacles. We celebrate people who think outside the box, as though the box itself is the problem. My experience has been almost the opposite. Every worthwhile improvement in my blog came because I deliberately chose the box I wanted to work within.
Experience didn't teach me how to remove constraints. It taught me how to choose the right ones.
The First Lesson Wasn't About Technology
My earliest websites were built simply because I wanted a place to publish my work. At that stage, I knew little about the broader ecosystem of content management systems. Later, like many people, I moved to WordPress because it solved problems I didn't want to solve myself.
Then I lost the entire blog.
I forgot to renew my hosting. There was no backup. Everything disappeared.
This isn't a criticism of WordPress. The platform wasn't at fault. But it was my first reminder that creating something and owning it are not always the same thing. When your work depends on several moving parts, every one of them becomes part of your responsibility whether you think about it or not.
At the time, I simply moved on. Only years later did I realise that this experience quietly influenced many of the decisions that followed.
Building Around an Idea, Not Around a Tool
In 2012 I rebuilt my photography blog
Picturejockey
A photo blog that I started in 2005 and then redesigned it to be responsive in 2012.
, partly because I wanted to learn responsive design. Personal projects are wonderful teachers because nobody tells you when to stop. You can experiment, fail, rebuild, and keep refining until your curiosity is satisfied.
But there was another reason.
I had a very specific idea of how I wanted people to browse my photographs. I wanted them organised by the day they were taken, displayed through a calendar where each day containing a photograph became part of the navigation itself.
Could another platform have been made to do that? Probably. But that wasn't the question I was asking.
The question I cared about was much simpler.
Would the technology allow me to build the experience I had imagined, or would I slowly change my idea to fit the technology?
I realised I preferred the first option.
I didn't want to be limited by the constraints of a platform. If I had to accept limitations, I'd rather they were my own.
That distinction became increasingly important over the years.
The Dependencies I Chose to Leave Behind
Like many websites of that era, my blog gradually accumulated external services.
I used third-party commenting systems. One disappeared. I migrated to another. Comments lived somewhere else. Managing discussions meant logging into another service, hoping it would continue to exist and hoping I wouldn't have to migrate everything again in the future.
I added FreeFind to provide search because it was an easy solution. It worked well enough, but it still depended on someone else's service continuing to operate.
I explored using Google's search as well, but I wasn't satisfied with the results it produced for my site.
None of these decisions were unreasonable. They solved real problems. Millions of websites continue to benefit from services like these.
The question slowly changed.
Instead of asking, How do I add comments? or How do I add search?, I started asking, Which of these dependencies am I comfortable carrying for the next ten years?
Those are very different questions.
The Current Blog Is a Reflection of That Thinking
When I began building this version of my blog, I deliberately avoided using a traditional CMS.
Not because content management systems are bad.
Not because static websites are somehow superior.
They simply weren't the right constraints for what I wanted to build.
I wanted the website to reflect my personality rather than the structure of a template. I wanted complete control over how articles were organised. I wanted archives, categories, tags and search to work exactly the way I imagined, without introducing a database or relying on external services.
Ironically, those restrictions forced better solutions.
The homepage became a simple view of the latest articles with older writing moving naturally into the archive. Search was built using static data rather than a server-side database. Navigation emerged from carefully structured content instead of a content management system deciding how information should be organised.
None of those solutions existed because I rejected technology.
They existed because I accepted a different set of constraints and the project became much easier to manage.
The freedom you have tomorrow is defined by the constraints you choose today.
Looking back, I realise I wasn't simply rebuilding a website. Each version reflected a different understanding of what I was willing to trade for convenience, flexibility and control. Over time, one idea became increasingly clear.
Every version of my blog became more capable because I deliberately limited my options. By choosing my own constraints instead of inheriting them from platforms and services, I gained something far more valuable than flexibility. I gained control over how the site could evolve.
The things we refuse to constrain become the baggage we carry. Every choice left open adds weight. Every deliberate constraint leaves us lighter and freer.
Every dependency offers convenience in exchange for a constraint. The question isn't whether that exchange is good or bad. The question is whether it's the exchange your future self want to make.
Choosing the Constraints That Matter
One of the easiest mistakes in technology is believing that every decision has a universally correct answer.
Should everyone build a static website? Of course not.
For many people, WordPress is exactly the right choice. Hosted services save time. Plugins solve problems. External platforms allow creators to focus on writing instead of maintaining software.
Those are perfectly valid trade-offs.
Mine were simply different.
Over the years I realised that I was happier investing time in learning than accepting limitations I couldn't influence. Knowledge grows. Systems can be refined. Architecture can evolve. A service that disappears leaves you with far fewer options.
That doesn't make my approach universally better.
It makes it the right approach for what I wanted to build.
Looking Back
When I look at every version of my blog, I no longer see changing technologies or changing design trends.
I see a gradual shift in how I thought about ownership, control and long-term sustainability.
The interesting thing is that I never set out to build a static website. I set out to build something that reflected how I wanted to work.
The technology simply followed.
Perhaps that's the lesson I've carried with me into other areas of my career as well.
We rarely get to choose whether constraints exist.
We do, however, get to choose which ones we're willing to live with.
And after rebuilding my blog several times over the years, I've come to one conclusion that extends far beyond web development.
I would rather accept the limitations of my own knowledge than the hidden limitations of tools and services that I don't control. Knowledge can be expanded. A discontinued service cannot.
