The Sovereign Design Approach: Reclaiming What We Lost

I started my journey with computers over 40 years ago, in the 1980s. Back then, computing felt different. Software was clean, simple, and portable. You owned what you installed, you controlled your data, and tools did exactly what they said they would do. Nothing more, nothing less.

The Golden Age We've Forgotten

In the 80s and 90s, software served the user. Programs were designed to be efficient because resources were limited. Documentation was thorough because developers couldn't rely on cloud connectivity to patch problems later. And perhaps most importantly, your data lived on your machine, under your control.

There was a directness to the relationship between user and tool. When you bought WordPerfect or Lotus 1-2-3, you owned it. When you saved a file, you knew exactly where it went. When you closed an application, it actually closed. It wasn't phoning home or running background processes you never asked for.

The Slow Erosion

The early 2000s marked a turning point. What we now call "enshittification" began its slow, steady creep into our digital lives. The pattern became painfully familiar to those of us working in IT:

A brilliant new solution would emerge (elegant, focused, solving a real problem). The team behind it would grow, and we'd invest time learning the tool, building workflows around it, recommending it to colleagues. Then, inevitably, a larger corporation would acquire it. The product would bloat with "features" nobody asked for. Pricing models would shift. Terms of service would change. Sometimes the product would simply disappear, folded into some enterprise suite.

Then we'd start the cycle again.

The Fatigue Sets In

After the tenth or fifteenth time of having the rug pulled out from under you, something changes. You become hesitant. That exciting new tool everyone's talking about? You hold back. Not because it isn't good, but because you've learned not to trust that it will still be good, or even exist, in two years.

This hesitation isn't laziness or resistance to change. It's learned behavior from an industry that stopped respecting the user's investments of time, of trust, of the mental energy required to master a tool.

Meanwhile, something more insidious was happening. Slowly, steadily, we were losing control. Our files moved to "the cloud" (which is just someone else's computer). Our applications became "services" requiring internet connections and monthly subscriptions. Our data became fuel for algorithms we don't understand, serving purposes we never agreed to.

Privacy became a quaint notion. Agency became negotiable. Ownership became a maintenance license, revocable at any time.

The Sovereign Model: A Return to Principles

The sovereign design approach is about reclaiming the principles that made computing empowering in the first place.

User Control: Your data lives where you decide. Your tools run on your hardware. You're not a tenant in someone else's ecosystem. You are the sovereign of your own digital domain.

Simplicity: Software should do what it promises, efficiently and transparently. No hidden processes, no data collection you didn't authorize, no feature bloat that obscures core functionality.

Portability: Your work and memories shouldn't be locked into proprietary formats or dependent on a specific vendor's continued existence. Open standards and interoperability are fundamental.

Longevity: Tools need to be built to last, not engineered for planned obsolescence or forced upgrades. The software you learn today should still be useful tomorrow.

Trust: When you close an application, it closes. When you delete something, it's deleted. When you're offline, your tools still work. These aren't radical ideas. They're basic expectations we somehow learned to get by without, and at what cost?

Building for Users, Not Metrics

The sovereign approach requires a different mindset from developers. Instead of asking "How do we maximize engagement?" or "How do we capture more data?", we ask "How do we serve the user's actual needs?" A problem is half solved when it is properly defined.

This means resisting the temptation to add features that serve business models rather than users. It means designing for privacy by default, not as an afterthought. It means building tools that get out of the way and let people do their work. The best design is mostly invisible.

The Path Forward

We can't return to the 1980s, nor would we want to; modern computing power enables incredible things. But we can bring forward the principles that made computing of that era feel empowering rather than extractive.

The sovereign design approach isn't about rejecting progress or submiting to some political ideal. It's about ensuring that progress serves the people using the technology, not just the corporations providing it. It's about building systems where users have genuine agency, where privacy is respected, where ownership means something.

After 40 years of watching the pendulum swing toward corporate control and user exploitation, it's time to swing it back. The technology to build sovereign systems exists. The need certainly exists. What's required now is the will to build differently; and the courage from users to demand better.

The tools we build should amplify human capability, not extract value from human attention. They should respect our time, our privacy, and our agency. That's not a radical vision, it's simply computing done right.

And it's a future worth building.