Per-seat pricing is one of the few lines on a software invoice you can delete without asking anyone’s permission. Drop a seat, and the charge drops the same billing cycle. That is the entire appeal of moving business tooling onto a server you rent for pocket money, and it explains why this argument resurfaces every couple of years. The source article behind this piece argues that it finally holds up across most categories. I largely agree, and I want to be precise about where I would still push back, because the part that gets waved through is never the software itself. It is the hours.
Where the argument has actually changed
Open source business tools spent a long stretch losing on presentation rather than capability. The source names the old tell without flinching: interfaces that looked a decade stale, and documentation written for readers who already knew the answer. Its claim is that the distance shrank over recent release cycles, helped along by larger contributor bases, saner defaults shipped out of the box, and docs a non-specialist can follow to the end.
Accept that premise and the decision changes shape entirely. You stop weighing a finished product against a rough approximation of one, and start weighing a recurring charge against a single block of setup labour. Those are different kinds of bet. Four categories get named in the source as places where the distance closed:
- Analytics, described as mature and privacy respecting, with no per-event meter attached.
- Helpdesk, covering ticket flow and shared inboxes for a small support rota.
- Project management, meaning kanban boards (a card and column view of work in progress) plus issue tracking.
- Design and diagramming, including live collaboration that carries no subscription.
What has not changed is that somebody owns the machine. The source states this plainly and it deserves repeating before the interesting part: updates eventually break something, backups become your responsibility, and ignoring either one converts a quiet Saturday into an unpaid support shift. Anyone selling this as a free lunch is selling you a weekend.
Ranking the four by how fast they pay back
Payback speed and size of saving are not the same measurement, and they get conflated constantly. This next ranking is my editorial call rather than a source claim: I would order these by how little can go wrong, not by how large the number on the invoice looks.
Helpdesk earns the top slot on that basis. The source calls it the simplest category to run yourself, because the requirements barely move year to year: a database, a mail connection, and an interface that does not fight the person using it. Ticket queues, SLA timers (clocks measuring how long a customer waited against a promise you made), and saved replies all arrive working rather than needing assembly. Commercial competitors bill per agent, so the gap widens each time the rota grows from one person toward five.
Boards and issue tracking land second. Coverage here is broad according to the source, spanning lists, calendars, automations, and hooks into the tools teams already run. The objection that hosted products won on mobile apps and live sync is described as largely settled, though the source concedes the mobile experience remains less refined than the market leaders. Its sharper point, and mine as well, is that adoption decides this category rather than the feature grid. Nobody saves money on a board the team quietly abandons.
Analytics carries the biggest number and lands third only because of that variability. Usage-based billing behaves reasonably until traffic climbs, at which point the source says the tool becomes one of the heaviest items on the monthly statement, with nobody warned because the dashboard framed growth as a pricing feature. Self-run alternatives are credited with event tracking, funnel analysis, and session replay (a recording of how one visitor moved through a page) at a fixed monthly figure the source places under twenty dollars on a modest virtual machine.
Design and diagramming sits last in my ranking for one reason: the source gives it a single line of evidence. Treat it as the least documented of the four and verify the specific tool yourself before you commit a team to it.
- Helpdesk: stable requirements, per-agent billing sidestepped, fastest clean result.
- Project management: broad coverage, real adoption risk with non-technical teammates.
- Analytics: largest and most variable saving, moderate setup, data stays on your hardware.
- Design and diagramming: thinnest supporting evidence, so confirm before migrating.
The hours column nobody puts in the spreadsheet
Comparisons between a subscription total and a server bill almost always stop at dollars. Hours are the column left out, and hours are what determine whether this decision ages well. For analytics the source quotes a setup measured in a few hours, with ongoing upkeep amounting to applying updates and keeping an eye on logs. Official Docker images (prepackaged container files that start a service with one command) and single-line installers are cited as standard across these projects now.
Budget honestly, and budget for four separate things rather than one:
- First install per tool, counted in hours rather than minutes.
- An update pass after each upstream release, plus repair time when one lands badly.
- Backup verification, which is genuinely separate work from configuring backups.
- Onboarding cost when someone non-technical meets software built by technical people.
Give up something, too. Polished hosted dashboards and integration marketplaces go away, per the source. Deep hooks into niche customer relationship tools are called out specifically, and a support workflow leaning hard on Slack or Salesforce connections will feel the absence. Against that, the source notes exports get easier once you hold the database yourself, and your roadmap stops passing through a vendor’s analytics.
Questions that decide it for your team
Work through these before any migration, not during one. Each has a wrong answer that should stop the project.
- Who handles updates and restores by name? No name means paying the project maintainers or a third party for managed hosting, which the source lists as a legitimate route rather than a failure.
- Which integrations are load bearing, and which do you fund out of habit and never open?
- What is the hour count for installation plus a year of upkeep, and does the money saved actually cover it?
- Does holding the data yourself change your obligations, for instance with users in the EU?
- Can you write the migration steps down now, before anything depends on the tool?
That last question is the one people skip. Owning the database makes leaving easier in principle, but only if the exit route exists on paper before you need it.
Trade-offs
Analytics swaps interface polish and a marketplace for a predictable charge that ignores traffic spikes. For a team checking those numbers daily, and especially one handling EU visitor data, that swap reads well. For a team that opens the analytics tab twice a quarter, it does not.
Helpdesk gives up the deep commercial integrations and keeps the fundamentals the source describes as excellent now. Small rotas fielding manageable ticket volume lose almost nothing. Support teams built around a heavily wired CRM lose real capability.
Boards carry the adoption risk rather than a functional one. Teams comfortable learning a few shortcuts do fine. Teams that need project software to feel like a consumer app are better served staying hosted, and that is a judgement about people rather than a verdict on the software.
Design and diagramming remains unproven in the material I have. I would not migrate a design workflow on the strength of a single sentence.
Cost deserves its own honest line. When the dollar saving is modest and the data is not sensitive, paying a vendor is a defensible choice. The source makes the same concession: owning the server pays off even against small savings when the data genuinely matters, which implies the reverse holds too.
Where I would start, and what I would not do first
Start with one category. The source recommends analytics, and the reasoning holds up: per-event billing hurts most there, and the setup is forgiving enough that breaking it costs you graphs rather than customer records. Breaking a helpdesk mid-migration costs you conversations with paying customers, which is a much worse afternoon.
Run that single tool properly for a quarter before touching anything else. By the end of it, the source suggests, you will know whether the trade-offs suit your team, and you will have banked real money without gambling the company on a weekend project. My addition: write down the hours you actually spent during that quarter. That figure, not the invoice comparison you started with, is what tells you whether category two is worth beginning.