There’s a question I’ve been turning over in my head for a while now. It’s not a technical question, even though it affects almost every technical decision I make. At what point does convenience stop being a benefit and start being a liability?

I’ve been building software for well over twenty years now. Most of that time, I’ve spent in and around the WordPress ecosystem. I was one of the first developers hired onto the WooCommerce team, back when we were still figuring out if eCommerce on WordPress was even a good idea. I’ve seen the ecosystem grow from a handful of plugins and a relatively tight community, to an industry that powers a significant chunk of the internet.

Over those years, I’ve watched a pattern repeat itself. A problem emerges. Someone builds a SaaS product to solve it. The SaaS product is good: easy to set up, handles the complexity for you and you can be up and running within the hour. People adopt it. Then, slowly and imperceptibly, that SaaS product becomes infrastructure. It becomes the default. And at that point, the convenience that drew you in has quietly become a dependency you didn’t sign up for.

The default answer

The default answer to almost every software problem today is to outsource it. Need analytics? Sign up for a service. Need to manage your email list? There’s a platform for that. Need a CRM? There are dozens. Need to monitor your application? There’s a dashboard waiting for you.

Individually, each of these decisions makes perfect sense. The service is better than what you’d build yourself. It’s maintained by a team that focuses on it full-time. It has features you wouldn’t think to build. And, critically, it lets you focus on the thing you’re actually trying to do. Building your product, serving your customers, growing your business.

I’m not here to argue that all of this is bad. I use SaaS products myself. Some of them are excellent. The argument I want to make is more specific than that.

What you’re actually trading for convenience

When you adopt a SaaS tool for a core part of your business, you’re making a trade. You get convenience, reliability and saved time. In return, you give up control, data portability and independence. For a lot of tools, that’s a perfectly reasonable trade-off. I don’t need to self-host my email server (although some people would argue I should).

But the trade becomes a lot less reasonable when it involves your core business data. Your customer relationships. Your communication history. The analytics that tell you how your product is actually being used. The information that, if you sat down and really thought about it, represents the most valuable asset your business has.

Having that data sitting on someone else’s server, accessible through someone else’s dashboard, subject to someone else’s terms of service and pricing changes. That should give you pause. Not because the provider is necessarily malicious, but because you’ve introduced a dependency into the most critical part of your operation.

And dependencies have a way of becoming visible at the worst possible time. When the provider changes their pricing model. When they get acquired and the new owners have different priorities. When they sunset a feature you relied on. When they experience an outage during your busiest period.

The compounding effect

What concerns me most is not any single dependency, but the compound effect. I know developers and small software companies that have outsourced their analytics, their email, their customer data, their content distribution and their payment infrastructure to separate third-party services. Each decision made sense at the time. Each tool was the best option available.

Zooming out, everything you’re looking at is a business where almost every critical function depends on a third party’s continued goodwill, stable pricing and uninterrupted service. The business itself might be yours, including the code, product and ideas. But the infrastructure it runs on? That’s a patchwork of monthly subscriptions, each one representing a relationship where you are not in control.

That’s the hidden cost of convenience. The cost isn’t visible on the invoice. It’s in the architecture of your business itself.

The alternative is not suffering

I want to be clear about something: I’m not arguing for self-hosting everything. I’m not suggesting that every developer should spend their weekends maintaining a mail server. That’s a different kind of trap. One where you’re so busy managing infrastructure that you never ship anything.

The argument I’m making is about intentionality. It’s about recognising the difference between a tool that handles something you genuinely don’t care about and a tool that sits between you and the most important data your business produces. Those are fundamentally different decisions and they deserve different levels of scrutiny.

When it comes to your core data, the information that represents your customer relationships, your business intelligence, your competitive advantage, the question should not be “what’s the most convenient option?” The question should be “where does this data live, who has access to it and what happens if this relationship changes?”

If you can’t answer those questions clearly, you’ve optimised for the wrong thing.

What I believe

I’ve arrived at a fairly simple position on this, after over twenty years of watching these dynamics play out.

I believe that the most important data your business produces should live in infrastructure you control. Not because self-hosting is inherently superior. Not because SaaS is inherently evil. Simply because your customer relationships are not a commodity to be managed through someone else’s interface.

Convenience is a wonderful feature. It is also a terrible foundation.

I think a lot of us in the software industry have been so busy building that we haven’t stopped to question the defaults. We adopted the convenient option because it was there, it worked and everyone else was doing it. And now we find ourselves in a position where the most valuable parts of our businesses are distributed across dozens of third-party systems that we don’t control and, if we’re honest, don’t fully understand.

That doesn’t make us foolish. It makes us human. The defaults are powerful precisely because they’re easy. But defaults are not decisions. And I think it’s time to start making some deliberate ones.