Every few years someone declares that self-hosting is back, and every few years they are wrong. The pattern has been consistent for a decade: enthusiasts run their own services, everyone else pays a subscription, and the enthusiasts eventually give up because maintaining a server is a hobby that bills you in weekends.
I think something actually changed this time, and it isn't the reason people usually give.
It's not about privacy or cost
Those are the arguments you hear, and they're both weak.
Privacy is a real motivation for a small number of people and a stated motivation for a much larger number who will trade it away for any amount of convenience. Watch behavior rather than surveys and the conclusion isn't flattering.
Cost is worse as an argument. Once you price in your own time, self-hosting rarely wins against a subscription, and anyone who tells you otherwise is valuing their weekends at zero. I've run my own infrastructure for years and I wouldn't defend it on cost.
What changed is that the build cost of the software itself collapsed, and that's a different thing entirely.
The economics of a niche tool inverted
The reason you rent software is that building it's expensive and your needs aren't special enough to justify the expense. Both halves of that sentence were true for a long time.
The first half has stopped being true for a large category of applications. Internal tools, admin panels, trackers, small CRMs, dashboards, workflow apps: the kind of software that is mostly forms, a database, permissions, and a job queue. A mature framework already handles nearly all of it. What is left, the part that used to take a quarter, now takes a weekend for someone who knows what they want.
I did this myself. I replaced a commercial CRM with one I wrote, not because the commercial one was bad but because my work is relationships rather than deals, and every product in that category is built around a pipeline moving toward a close. I was doing manual translation work every week to fit my process into a model that didn't match it. That translation cost never appears in a pricing comparison and it compounds forever.
The build took a weekend of real work and a longer tail of data migration, which is where the time actually goes and where I would tell anyone considering this to budget most of their effort.
The advantage is subtraction
Here is the part I didn't anticipate. The value wasn't in what I added. It was in what I could leave out.
My CRM has no forecasting, no territory management, no lead scoring, no quota tracking, no permission hierarchy. I am one person. Removing those did not just save build time, it made the tool faster to use every single day, permanently.
A commercial product can't give you that. It has to serve the forty-person sales team as well as you, and every feature it carries for them is complexity you pay for in navigation, in settings you must ignore, in a slower interface. The subscription is the small cost. The generality is the large one.
This is the real economics of the shift. Not cheaper software. Software shaped exactly like your problem, which was previously available only to organizations large enough to fund a team.
What has not gotten easier
Operating it. This is where the self-hosting revival narrative usually oversells.
Writing the application is now the easy part. Backups that you have actually tested by restoring, TLS certificates that renew without you, security updates applied before the exploit is public, monitoring that tells you it's down before your users do: none of that got dramatically cheaper. It's the same unglamorous work it has always been, and it is the reason most self-hosting projects die around month eight.
Two things make it tractable. Container-based deployment with a single compose file has made "get it running again on a different machine" a real, tested procedure instead of a hopeful one. And the honest move for most people is a managed database with automatic backups, which removes the failure mode that actually destroys projects. Self-hosting your application while renting your persistence layer is not ideological purity, but it's the configuration that survives.
Who this is actually for
Not everyone, and I want to be clear about that because the enthusiasm here tends to outrun the case.
If you're a team of forty with a standard process, buy the software. Your process is the process the vendor solved, they solved it better than you will, and your engineers have more valuable things to do.
If you're an individual operator or a very small team whose work doesn't fit the shape the market assumes, the calculation has genuinely moved. It moved because the build cost fell by an order of magnitude while the cost of misfit stayed exactly the same.
The test I would use: what's your actual complaint about the tool you rent? If it's price, don't build, negotiate. If it is a missing feature, do not build, wait. If it's that you spend time every week reshaping your work to fit the tool's assumptions, that cost is permanent, and building is the only thing that removes it.
About Nick Sawinyh
Nick Sawinyh is a product and engineering leader with over a decade of experience taking technically complex products to market across DeFi, AI tooling, and government technology. He builds and maintains several open-source tools and writes at sawinyh.com.