Why I am Migrating: Privacy, Control, Trust, and Reducing Platform Dependence
My old workflow was held together with expensive duct tape and false promises — layers of SaaS programs that weren’t optimized for my needs, came with fees on top of fees, introduced security vulnerabilities and privacy concerns, and created significant regulatory exposure under laws like California’s digital subscription requirements and EU GDPR.
How I Got Here
Instead of privacy-respecting video conferencing, I was using Zoom. One glance through their privacy policy and you would never want to have a video call again. The irony is that switching to better tools does not automatically solve the friction problem. I spent an hour recently trying to get a tech developer — a tech developer — onto a simple call. He used Safari despite my instructions, forgot to turn his mic on, and had all his passwords stored in Safari so he couldn’t even access LinkedIn to find my login instructions. This kind of friction is real and it does not disappear just because you chose a better platform. With just a small amount of research though, I realized I could record locally and save to my own computer — no third-party cloud storage of sensitive conversations, real data sovereignty. This matters especially for the unconventional entrepreneurs I work with, who are already paranoid on a good day and are forced to compromise on basic security just to get funding.
European privacy law requirements made the math brutally clear: compliance managers, extravagant legal fees, and extra SaaS programs piled on top of each other — and none of it would actually solve the problem. To be honest, I am not sure there is a way to handle these concerns effectively within the existing architectures and business structures.
One thing the existing processes do is prevent small creative people from feeling comfortable starting their own businesses. I can’t tell you how much time I have spent modeling costs and trying to find ways to make things possible, especially in areas of high regulatory oversight. That is the last thing we should be encouraging. Leaving centralized, extractive, monopolistic, high-friction services and products in place and then adding burdensome regulations on top is far from a first-principles engineering approach.
If you hired a bunch of entrepreneurs to redesign business flows from the ground up, would we even consider these ridiculous options? If we take the money part out just for a minute and allow the criteria the engineers applied for the redesign to be value, efficiency, data sovereignty, security, and appropriate regulatory concerns — what would they design? How would they design it? During these liminal times, have you noticed that the most extractive, high-friction products and services are the ones that have the highest stock prices? How exactly does that work? Ignore billions of years of evolution of what makes a system sustainable and systemically valuable, then make it maximally inefficient and incoherent. Then declare these investments to be conservative and good for your retirement planning. In some future version of ourselves, we would be laughing at how obviously strange and inverted this whole mess was.
While many people obsess about whether AI will destroy SaaS, I was asking a different question entirely: how do I build a stack that actually meets my needs with reasonable costs? And rather than wondering whether to buy Salesforce stock, I was thinking about how to integrate that functionality into a privacy-respecting, sovereign stack — layered with central and edge AI tools to improve my research and operations.
I have some stories that feel funny in hindsight. At the time, I was not laughing. It took me months to get off Microsoft 365, and I am still dealing with issues with calendar syncing and finding a way — without having to hire IT developers — to stop the invasive Microsoft takeover of my Apple laptop even after I cancelled the services and no longer use them. It took me weeks to move documents over from the software I originally wanted to use for my service, realizing that it is easy to sign up and impossible to leave. When I finally did leave, even though I had paid for a year in advance, the service ended when I did not renew. I thought getting off WordPress would be easy since, at least, it was open source. Well, no. There is nothing easy about WordPress when you are not a developer. They are open source in name only — the ecosystem around it had become anything but. Applying my living systems lens pointed me in some better directions. Headless is not a technology option. It is a way of thinking about how to design workflow that is secure, adaptive, and efficient. Yes, I finally cancelled Zoom — but I am still writing instructions for people to more easily connect during the meetings.
I did not just wake up one day and decide to change my stack. It happened slowly, and then not so slowly. What really pushed it over the edge were a few things: expensive renewals coming up, WordPress problems forcing a costly redesign, and thinking through the MVP for launch — realizing the privacy issues and regulatory concerns required a complete rethink. So I did what any research analyst does. I studied and learned. I went into a deep dive on open-source software and could easily see the parallels to my living systems principles. It was far more than virtue signaling to redesign with my nonlinear, living systems approach. There was no patching this broken system for my complex systems investing services. They required a living systems design architecture.
What I didn’t expect was that the tools I needed had been quietly under construction for years — built by a community that had faced these same constraints and designed their way out. That is where this series goes next.
This is the first in a short series for my digital garden. In the next essay, I will discuss my living systems lens and how that helped me select the technology for my new stack.
Enjoy this? Get the Coherence Lab Letter delivered to your inbox → subscribe link