Is setting up an open-source ticketing system for an 8-person team worth it, or more trouble than it's worth?

Calculate your developer's hourly rate. Even if that teammate spends just 4 hours a month setting it up, configuring it, and troubleshooting, the internal cost already equals an annual cloud license. On top of that, if they ever leave the company, who takes over that server? Definitely go with a cloud solution.

Don't get caught up in open-source fanaticism. Developers love running everything on their own servers because it's a fun toy for them. But when customer emails land in spam or the server crashes, you're the one paying the price. If your company's core business isn't server management, an open-source ticketing tool is an unnecessary headache.

We set up an open-source tool at our 10-person agency. In the first year, support traffic completely died three times due to server crashes, broken inbox sync, and a botched software update. It was embarrassing in front of clients. We eventually switched to a managed cloud tool, pay 200 EUR a month, and have had total peace of mind for the past two years.

what if we dont installl an open-source system ourselves, but get it as a one-click managed install from a hosting provider—does the maintenance burden still fall on us?

Youre totally right to ditch the shared inbox, managing email with 8 people is pure chaos. But cloud tools have entry-level tiers, plans around 12-15 EUR per user will do the job just fine. Budget 100-120 EUR a month for 8 people and save yourself the headache.

data privacy fines in germany are brutal. if you don't configure an open source system properly and client communications leak you'll be in a world of hurt. cloud platforms already come with all that compliance out of the box.

To sum it up, the consensus here is clear: even though open-source software is free, operational labor and maintenance end up costing more than managed cloud platforms. Unless your core business is running servers, going with a SaaS tool makes the most sense.

There are three things to check when doing this. Implementing a change request process doesn't slow things down, it speeds them up.

Processes without records never improve, because you don't know what to fix. Correct me if I'm wrong.

I disagree with you on this point. If scope grows, either time or budget must grow. There is no third option.

Absolutely. If I were to add anything: When making decisions, write down the worst-case scenario too, not just the best.

That's all, sorry if I went on too long.

Thanks for posting.

i went through the same thing.

We experienced almost the exact same thing last year. If scope grows, either time or budget must grow. There is no third option.

In legacy systems, the most expensive thing is unknown dependencies. If you post the result here, it will help others too.

Noted, thanks. The biggest time-waster for us was not knowing who had the final say.

Trying to do this alone is the most expensive way.

To get into the details: If it's your first time, start small; scaling comes later.

Everything goes well for the first three months; problems arise in the fourth. This is my opinion, I'm not claiming it's absolute truth.

I have an objection here. Payment schedules should be tied to project phases, not calendar dates.

This is my opinion I'm not claiming it's absolute truth.

The answer above hits the nail on the head. Everyone rushing into ticketing system open source gets stuck at the same point.

Every "we'll look at it later" in a meeting means unbilled work. This is my opinion I'm not claiming it's absolute truth.

We experienced almost the exact same thing last year. The harder it is to reverse a decision, the slower you should make it.

Proven by experience.