Most software companies build exclusively for others. We do both: alongside client work, we develop and operate a product of our own — Roster365, software for scheduling, time tracking and billing at security service providers.
This isn’t a side project but a deliberate choice. Running a product yourself for years teaches you things a closed-out project never will.
Why security services
The industry has a scheduling problem that off-the-shelf software handles poorly. A provider staffs dozens of sites for different clients, each with its own shift patterns and hourly rates. People call in sick at short notice, qualifications have to match the site, and at month’s end there’s an invoice that looks nothing like the payroll run covering the very same hours.
In many companies all of this runs on spreadsheets that grew over time. That works — until someone else has to take the spreadsheet over, or until a shift premium is calculated wrongly and nobody can reconstruct why.
What Roster365 covers
- Scheduling through weekly and monthly overviews, with shift templates and staff availability
- Time tracking that feeds billing and payroll rather than sitting in its own silo
- Shift premium calculation for night, Sunday and public-holiday hours as a dedicated module, so the rules stay traceable and changeable
- Billing including XRechnung and ZUGFeRD — since e-invoicing became mandatory in Germany, no longer a nice-to-have but a prerequisite for public-sector clients
- Payroll and accounting export into the systems used by tax advisors
- Absences and availability, so planning doesn’t work against reality
What we learned building it
Multi-tenancy is an architectural decision, not a configuration setting. Every customer gets their own database, reachable under their own address. That costs effort in migrations and operations — in exchange, a single tenant can be backed up, moved or restored without anyone else noticing. We could never have retrofitted it.
Domain logic does not belong in the UI. All business logic lives in clearly separated command and query handlers. That sounds like overhead until the same premium rule has to apply identically in scheduling, in billing and in the payroll export.
Invoice formats age faster than everything else. That’s why XRechnung and ZUGFeRD are a standalone service rather than a feature buried inside billing. When the requirements changed, it was an isolated change instead of open-heart surgery.
Operations write the most honest requirements document. Every support request shows where the software was imagined rather than observed. That feedback is missing when a project ends at handover.
What this means for your project
We know the client’s side from our own experience: migrations against live data, customers with urgent problems, the choice between the clean solution and the next release. That experience flows back into every client project — in architectural decisions as much as in judging what will come back to bite you later.
If you run a security service, take a look at the product directly: www.roster365.net. There’s a free trial.
And if you’re facing a software decision of your own — custom development, or replacing a sprawling spreadsheet setup — we’re happy to talk it through with no strings attached.