For the better part of the last decade, the tech industry treated “move it to the cloud” less like a strategy and more like a weather pattern. It just happened. Files went to hosted drives. Photos went to hosted libraries. Notes, calendars, code, documents, marketing tools, analytics, chat, dashboards, automations — eventually everything had a login, a monthly bill, and a settings page nobody wanted to open.
A lot of that was reasonable. SaaS made real problems easier. Small teams got tools they could never have built or maintained themselves. Updates arrived without a weekend maintenance window. Collaboration worked from anywhere. Someone else worried about uptime, backups, and all the deeply glamorous plumbing that makes software useful instead of decorative.
But convenience has a way of becoming invisible until the bill, the lock-in, or the data risk gets loud enough.
That is where a lot of builders are now. The question is not “is the cloud bad?” That is a boring argument, and worse, it is usually wrong. The better question is: which parts of your workflow deserve local control, open formats, and tools you can actually move?
SaaS sprawl is not just a budget problem
SaaS sprawl usually starts innocently. One team needs a design tool. Another needs a project tracker. Someone signs up for an AI meeting assistant. Someone else adds a social scheduler, a PDF tool, a dashboard builder, a knowledge base, a customer support platform, and three different “just for this quarter” experiments that survive longer than most houseplants.
Then a few years pass and nobody can say exactly how many tools the organization depends on, who owns them, which ones touch sensitive data, or why three of them appear to do the same job with different fonts.
Reports on SaaS waste vary, but the direction is hard to miss: a meaningful chunk of purchased software goes unused or underused, while overlapping tools create cost and security drag. Zylo’s SaaS-management research and similar industry reports have been pointing at this problem for years: the waste is not just money, it is operational fog. Every extra tool is another identity surface, renewal date, export problem, permission model, vendor policy, and quiet place for data to collect dust.
That does not mean every subscription is a mistake. It means the default should not be “add another hosted tool and think about it later.” Later always arrives, usually with an invoice attached.
AI made the control question sharper
AI did not create the SaaS sprawl problem. It did make the tradeoffs harder to ignore.
Nearly every major platform now has some kind of AI feature attached to it: summarization, drafting, search, meeting notes, document analysis, code help, customer support suggestions, and the usual parade of glowing buttons labeled with words like “assistant,” “copilot,” and “magic.” Some of those features are genuinely useful. Some are expensive autocomplete wearing a tiny crown.
The privacy picture is also more nuanced than the loudest arguments suggest. Enterprise AI offerings from Microsoft and Google, for example, publish privacy commitments saying managed customer prompts and content are not used to train their foundation models under those enterprise terms. That matters. Serious vendors have had to learn that “just trust us with all your internal documents” is not a security model; it is a hostage note with rounded corners.
The larger risk is the governance gap around everything else.
People use personal AI accounts. They install browser extensions. They paste sensitive text into tools nobody approved. They summarize contracts, code, HR notes, strategy docs, screenshots, and spreadsheets inside whatever interface is closest when the work gets annoying. That is not usually malice. It is convenience doing what convenience does: finding the shortest path around policy.
Keep Aware’s 2026 browser security reporting found that a large share of sensitive web-app inputs were going to personal or unverified accounts. Treat that as a warning light, not as a universal law carved into stone. The point is simple enough without turning one statistic into a religion: modern work happens in the browser, and the browser now carries more trust than most organizations are prepared to manage.
I wrote about that broader problem in Browser AI Agents Need Better Boundaries. The browser is not evil. It is overloaded. It holds sessions, admin panels, documents, SaaS dashboards, internal tools, extensions, and now AI assistants that can read, summarize, click, and sometimes act. That deserves better boundaries than “please be careful.”
Open source is not a purity test
This is where open source and self-hosting become interesting again.
Not because everyone should flee into a basement rack and communicate only through a reverse proxy. That way lies madness, or at least a very opinionated Discord server.
The practical case for open source is control. Can you export your data? Can you inspect how the tool works? Can you run it somewhere else? Can you keep using it if the vendor changes pricing, removes a feature, sells to someone worse, or decides your workflow is no longer part of the roadmap?
For some tools, the hosted answer is still clearly better. Email for a school district? Probably not the place to cosplay as a 1998 sysadmin unless you enjoy pain as a service. Payroll, compliance-heavy workflows, business-critical collaboration, security monitoring, and anything requiring formal support may be worth paying a serious vendor to run.
But other workloads are different. Personal photos. Private knowledge bases. Internal document search. Small automation tools. Local dashboards. Homelab services. Repeatable AI processing over sensitive files. Those are places where control, portability, and predictable cost may be worth the maintenance.
That is the useful version of the “House of FOSS” idea: not a manifesto, just a toolbox. Use open-source and self-hosted tools where ownership improves the outcome.
The tools have gotten better
The old knock on self-hosting was not imaginary. A lot of open-source alternatives used to feel like punishment with a README. You could run them, technically, if you had a spare weekend, a high tolerance for YAML, and a willingness to learn why permissions are society’s most durable source of comedy.
That world still exists. But it is no longer the whole story.
Tools like Immich have made self-hosted photo and video management feel much less like a science project. Postiz shows how social scheduling and automation can be built with more portable, API-friendly assumptions. Ollama’s OpenAI-compatible API makes it easier to plug local models into workflows that already know how to talk to OpenAI-style endpoints. Open WebUI gives people a self-hosted AI interface that can work with local and cloud models.
None of this means every household or small business should suddenly run a private cloud. It means the choice is more realistic than it used to be.
Docker, Caddy, Traefik, managed VPS providers, better documentation, and stronger open-source projects have lowered the entry cost. They have not removed the work. That distinction matters.
Ownership has a maintenance bill
If there is one place self-hosting advocates sometimes get too cute, it is pretending the monthly bill simply disappears.
It does not. It changes shape.
Instead of paying a SaaS vendor, you pay in backups, updates, monitoring, access control, recovery planning, and the occasional evening spent asking why a container that worked yesterday has developed the personality of a raccoon in a wall.
That is not a reason to avoid self-hosting. It is a reason to be honest about it.
If you self-host something important, you need backups you have tested, not vibes. You need update habits. You need authentication that is better than “I exposed this admin panel to the internet and hoped.” You need a plan for disk failure, account compromise, and the day you are too busy to babysit the thing you built.
I covered more of that in The Hidden Maintenance Cost of Self-Hosting. The short version: local control is only useful if you can keep the system healthy. Otherwise you did not escape SaaS. You just promoted yourself to unpaid platform engineer.
Local AI changes what is worth bringing home
AI is the interesting wrinkle because it used to be the reason people stayed in the cloud.
You could self-host storage, notes, and dashboards, but if you wanted “intelligence” — semantic search, summarization, document chat, tagging, natural-language workflows — you usually rented it from a large provider. That is still the right answer for plenty of tasks. Frontier models, large-scale collaboration, managed reliability, and high-end capability are not free just because a homelab exists.
But for private, repeatable, everyday work, local AI is becoming practical enough to matter.
That does not mean “never use cloud AI.” I already made the workload-placement argument in Local AI Is Becoming Practical Enough to Matter: local models are useful when privacy, latency, offline access, predictable cost, or control are the priority. Cloud models are useful when you need the best model available, managed infrastructure, collaboration, or scale.
The smart move is not purity. It is placement.
A private knowledge base full of internal notes might be a good fit for local embeddings and local chat. A pile of sensitive PDFs might be better processed on a machine you control. A personal photo library does not always need to become training exhaust for someone else’s roadmap. On the other hand, a team that needs enterprise uptime, audit logs, legal review, and support may be better off paying for a managed platform with clear terms.
The point is to decide deliberately instead of letting every workflow drift toward the nearest subscription form.
A simple decision filter
Here is the filter I would use.
Keep SaaS when:
- collaboration matters more than control;
- uptime and support are worth paying for;
- compliance, audit, and legal requirements favor a managed vendor;
- the hosted tool is clearly better than anything you can reasonably maintain;
- replacing it would turn one subscription problem into five infrastructure problems wearing a trench coat.
Consider open source, self-hosting, or local AI when:
- the data is sensitive or personally important;
- the workflow is repeatable and stable;
- exportability and portability matter;
- pricing has become unpredictable;
- vendor lock-in would hurt;
- local processing gives you privacy, latency, or cost advantages;
- you are willing to own the maintenance.
That last bullet is the one people like to skip. Do not skip it. Skipping it is how “digital sovereignty” becomes “why is my photo library gone?”
The goal is control, not nostalgia
This is not a call to rebuild the internet in a closet. The cloud won because it solved real problems. SaaS won because most people do not want to spend their finite time becoming part-time database administrators. Fair enough. I also enjoy when software works without asking me to develop a relationship with PostgreSQL at 11:42 p.m.
But the pendulum swung too far toward renting everything by default.
The next healthier phase is not cloud rejection. It is tool judgment. Put the right workloads in the right places. Pay for hosted software when the trade is honest. Bring things closer to home when control, privacy, portability, and long-term ownership matter more.
That is also how I think about AI tools after the demo wears off. The question is not whether the demo is impressive. The question is whether the tool survives real use, real data, real costs, real support needs, and real failure modes.
Choose control where it matters. Rent convenience where it actually earns its keep. Try not to confuse one for the other just because the signup flow was smooth.
Resources on local control and AI tools
- Local AI Is Becoming Practical Enough to Matter — a practical workload-placement view of local AI versus cloud AI.
- The Hidden Maintenance Cost of Self-Hosting — what ownership actually costs after the fun setup part.
- Cloud Repatriation Is About Workload Fit, Not Cloud Backlash — the same placement argument at enterprise scale.
- Browser AI Agents Need Better Boundaries — why browser-based work needs stronger controls.
- How I Evaluate AI Tools After the Demo — a rubric for deciding whether AI tools survive contact with real workflows.