LuxeRoster

LuxeRoster is my own startup: a rostering and leave management platform for Australian retail businesses. It's live at luxeroster.com — there's a public demo account on the login page, so everything described here can be tried directly.

Being upfront about the stage it's at: this is a working product in testing with retail users, not an established business with paying customers. What follows is what's actually built and why I built it that way.

Why Retail, Why Australia

Generic scheduling tools treat a roster as a calendar problem. Australian retail rostering is also a compliance problem: the award system dictates minimum shift lengths, break rules, and penalty rates, and a roster that looks fine on a calendar can be quietly illegal or quietly expensive. Small retailers mostly handle this in spreadsheets and hope.

That compliance angle is the product's reason to exist. The scheduling features — availability, coverage, swaps — exist in plenty of tools; building them around award rules for Australian retail is the bet.

What's Built

Multi-tenancy from day one. Each registered business gets isolated data and its own staff, rosters, and settings. This was the hardest early architectural decision — retrofitting tenancy later is miserable, so I paid the complexity cost upfront. You can verify this yourself: register two businesses on the demo site and confirm they can't see each other.

Roster building with availability tracking. Staff record when they can and can't work; managers build weekly rosters against that availability with drag-and-drop scheduling and reusable shift templates. Each day in the weekly view carries a live coverage status — understaffed days are flagged with a "gaps" warning, covered days confirmed at a glance — and the dashboard tracks scheduled hours and labour cost for the day in real time. That coverage visibility turned out to be the feature testers respond to most.

Leave management. Staff request leave, managers approve or decline, and approved leave blocks out availability so it can't be rostered over. Unremarkable to describe, fiddly to get right: most of the edge cases live in the interaction between leave, availability, and already-published rosters.

Shift swapping. Staff can offer shifts to each other with manager sign-off, so last-minute changes don't have to route through whoever owns the spreadsheet.

Technical Shape

The stack is deliberately boring: TypeScript across the board, React/Next.js on the front, Node and Express behind it, PostgreSQL underneath. Rostering data is heavily relational — staff, availability windows, shifts, leave, businesses — and Postgres handles both the integrity constraints and the reporting queries without drama.

The genuinely hard engineering wasn't algorithmic, it was state: a roster is edited by a manager while staff submit availability changes and leave requests against it. Most of my time went into making sure the different write paths can't produce a roster that contradicts an approved leave request or a withdrawn availability window.

Where It Stands

LuxeRoster is in testing with retail environments, and the feedback from those sessions decides what gets built next. The most useful part of this stage has been watching real managers work with it — features I assumed were core get ignored, and things I almost didn't build (coverage visualisation) carry the demo.

I've also done the unglamorous founder work around it: brand identity, a Facebook business presence, demo materials, and positioning ("built for retail, not adapted for it"). Whether that positioning survives contact with the market is exactly what the current testing phase is for.

Lessons Learned

Multi-tenancy is cheaper on day one than day one hundred. Every table, query, and API route was tenant-scoped from the start. It slowed the first fortnight and has paid for itself continuously since.

Compliance is a moat and a burden. Award rules are what make the product defensible, and they're also the part that can't be approximated — getting them wrong is worse than not having them. That asymmetry shapes the roadmap more than any feature request.

Solo products need public demos. Putting demo credentials on the login page was the single best growth-of-feedback decision I made. Nobody books a call to see a screenshot; plenty of people will poke at a live roster for ten minutes and tell you what's confusing.