Buy, Build, or Self-Host: The Question Nobody's Asking
The buy versus build question is missing a third option: self-host. And before you even get to that choice, there's a step most people skip entirely.
This came up in a meeting yesterday. Someone asked how AI changes the buy or build decision. Good question. But the more I think about it, the more I think the real question is buy, build, or self-host, and most teams aren't asking it.
The case for looking at open source first
Before deciding to buy or build, it's worth asking a different question: does a good open source version of this already exist?
Not every open source tool is great. Some are abandoned. Some are technically sound but painful to use. But some are genuinely excellent, and those tend to be obvious once you start looking. They have active communities, regular releases, years of production use behind them, and real documentation.
The tools I rely on most at Fossys are good examples: n8n for workflow automation, ERPNext for accounting, Kubernetes to hold everything together. These aren't science experiments. They're used by enterprise companies. They're just also free to self-host.
According to the 2025 State of Open Source Report by Perforce OpenLogic, 96% of organizations are maintaining or expanding their open source use, citing cost reduction and vendor independence as primary drivers. The shift is already happening. Most teams just aren't extending that thinking to their own software decisions.
AI changed the self-hosting math
Running your own server used to require a specific kind of person. You needed someone comfortable with Linux, networking, backups, the whole stack. That was a real barrier for most small teams.
That barrier is meaningfully lower now. AI tools have made it much more approachable to set up and maintain secure infrastructure. If you can describe what you're trying to do, you can usually get step-by-step help to get there. What used to take a dedicated DevOps engineer for a week now takes a couple of hours for someone with moderate technical comfort.
That changes the calculus. Self-hosting an open source tool is no longer just a cost-cutting move for scrappy startups. It's a reasonable option for any team that wants to own its data and control its infrastructure.
Ownership matters more than cost
Cost is usually what gets people interested in open source. The savings can be significant. But I'd argue the more important benefit is ownership.
When you self-host, you own your data. You're not subject to a vendor deciding to change their pricing, sunset a feature, or get acquired. A common pattern in the SaaS world is a tool raising prices significantly after it becomes embedded in your workflow. At that point, switching is painful and staying is expensive. That's the position they have you in.
Self-hosting changes that dynamic. You're running software you understand, on infrastructure you control, with data that stays where you put it.
There are real tradeoffs
I'm not arguing that every team should self-host everything. That would be its own kind of sprawl.
You own the maintenance. You own the uptime. If something breaks at 11pm, that's your problem to fix. That matters, and it should factor into the decision. For some tools, in some organizations, paying for a managed SaaS product is the right call, because the time savings are worth the cost and the lock-in risk is low.
But that's a different conversation than most teams are having. Most teams aren't getting to the tradeoff conversation because they never looked for an open source option in the first place.
A simple addition to the checklist
Next time the buy versus build question comes up, add a third column. Before deciding anything, spend thirty minutes searching for an open source tool that does what you need. Look at recent commits. Check if issues are being responded to. Read through the community forums.
If what you find is solid, spin up a test instance. See how it feels. You might end up buying anyway. You might end up building. But you'll make a better decision if self-hosting was actually on the table.
And on a slightly bigger scale: if more organizations took that extra step before defaulting to another subscription, it would be better for their budgets, better for the open source communities that maintain these tools, and better for everyone dealing with the downstream costs of SaaS sprawl.
That's not idealism. It's just a different default.
What's the last SaaS subscription you cancelled because you found a better open source option?