Why we built Backbone around feature modules

Not every organisation using Backbone needs every part of it. A design studio might want projects, time tracking, and expenses, but have no use for a sales pipeline. A staffing agency might live in resource planning and barely touch expenses. Rather than force everyone through the same navigation, Backbone is organised around six feature modules that an organisation turns on individually: Projects, Time Tracking, Resource Planning, Sales, Expenses, and Leave.

How gating works

Access to a module is the combination of two things: whether the organisation has enabled it, and whether the signed-in user's role allows it. Both have to be true. An admin can see a module that's off for everyone else while they decide whether to turn it on; a consultant on an organisation with Sales enabled still won't see the pipeline if their role doesn't include it.

Why not just hide unused menu items in the UI

Because that's cosmetic — the underlying pages and data would still be reachable if you had the URL, and the API would still answer requests it shouldn't have to think about serving. Real gating happens on both ends: the backend enforces it against every request, and the frontend uses the same flags to decide what to render at all, not just what to link to.

What this means for you

If a module isn't useful yet, it costs nothing to leave off — no extra navigation, no unused tables cluttering a dashboard. Turning one on later is a setting, not a migration. See Feature modules in the docs for the full breakdown.