"Self-hosted" means: the software runs on a server you rent, instead of at the vendor. You no longer pay a per-user subscription, but you've become the administrator.

That's the whole trade-off. Everything below is an elaboration of it, based on three systems we migrated this year.

01 / the mathWhat does it save on the invoice?

Less than you'd hope, and that's a good starting point.

A server with 4 GB of memory costs us €7.09 per month, including backups and a fixed IP address. That runs one solid system. A server with 8 GB costs €8.49 and fits several.

So: any subscription costing more than about €10 per month is, on paper, a candidate to migrate. In practice that's a poor threshold, because it ignores the hours. A more realistic rule of thumb:

Below €25 per month, you don't migrate for the money. Above €100, it gets interesting. In between, something else decides.

That "something else" is in the next section, and for us it was decisive in two of the three cases.

02 / the ceilingWhen isn't price the argument?

When you hit a limit instead of an amount.

Our automations ran on a €20-per-month plan with a cap of 2,500 executions. That's a fine package, until you grow. And then the next tier isn't a bit more expensive, it's much more expensive, because such packages scale in jumps.

Running it yourself removes that ceiling. Not because the server is infinite — it isn't — but because you're buying capacity instead of permission. You only notice that difference the moment you need it.

The same goes for ownership. With a subscription, you own an account at a vendor. Run it yourself, and you own the installation and the data. For our blog, that was the reason to migrate; the €7 was beside the point.

03 / the bill you don't seeWhat does maintenance cost?

An unpredictable amount, spread over unpredictable moments.

Two things that happened to us this year, both on systems that were "just running".

Our blog's mail failed to arrive half the time. Invitations for team members, password resets, verification codes — coin toss. The cause: the mail server randomly picked between two network addresses per message, and only one of them was registered with the mail provider. Meanwhile, the error message pointed to an entirely different component that had nothing to do with the problem.

And a routine job on the web server took the blog offline, because the system's management tool rewrites its own configuration and discards a manual addition in the process.

Neither is in a manual, and both cost an evening. That's the real price of running it yourself: not the hours you plan for, but the hours you didn't.

With a subscription, an outage is an annoyance. Running it yourself, an outage is your evening.

04 / don't do itWhat do you keep with a vendor?

Everything where the outside world needs to accept something from you.

We run our blog, community, automations, password vault and CRM ourselves. We do not run our business mail, telephony, payments and bookkeeping ourselves, and we're not going to.

The distinction is useful: run it yourself when it's software, buy it in when it's a service with an obligation to the outside world.

• Sending mail — technically simple, arriving is the problem. You don't build sender reputation with recipients on your own.
• Payments — regulated. Here, self-building isn't a saving but a licensing question.
• Telephony — cheap, and tied to number porting and availability.
• The language model — running a model yourself is possible, but here you're buying thinking power, not a program.

05 / the rule of thumbHow do you decide in five minutes?

Go through these four questions. Two "no"s is enough to stay where you are.

• Does the subscription cost more than €100 per month, or are you hitting a limit? If not, leave it be.
• Is there someone to manage the server if you're away for two weeks? If not, leave it be.
• What happens if this system is down for a day? If the answer is "then I sell nothing", you want a vendor with a guarantee involved.
• Is the data inside it your business, or just a tool? In the first case, ownership outweighs convenience.

For most systems, we end up migrating, because we already have the management skills in-house and because our own stack doubles as our showcase. Those are two reasons that probably don't apply to you. Four of the nine things on our list we deliberately keep with a vendor, and that's not inconsistency, it's the same calculation, just landing differently.

This text was produced with AI assistance and reviewed and approved by a human before publication.