Brb.

Making leave easier to manage

Brb is a full-stack leave management platform I designed and built for employees, managers and administrators. It handles the complete leave process, from requesting time off and tracking allowances to approving requests, checking team availability and managing employees.

I built the client in TypeScript and React with Tailwind and React Router, alongside an Express REST API backed by MySQL and TypeORM.

One application, three different roles

Brb adapts around the person using it. Employees can book and cancel leave, view previous requests and keep track of their remaining allowance. Managers can also review requests from their team and see upcoming leave in a shared calendar, while administrators have access to organisation-wide employee and leave management.

Rather than building separate interfaces for each role, I created shared routes, components and features that respond to the current user's permissions. This keeps common behaviour in one place while still giving each type of user the tools they need.

Keeping access control where it belongs

The React application uses protected routes to keep users within the areas relevant to their role, but this is only the first layer. Authentication and authorisation are also enforced by the API using JWTs and role-based middleware.

Permissions are checked against the requested data as well as the route itself. For example, an employee can access their own leave, a manager can access their direct reports, and an administrator can access records across the organisation. This means the backend remains responsible for deciding what a user is actually allowed to do.

Building the leave rules into the API

The API contains the business logic behind the booking process rather than leaving those decisions to the interface. It manages leave balances, approval states, overlapping requests, public holidays and the organisation's leave year.

The front end uses the same rules to give useful feedback while someone is making a request, but the server validates the request again before anything is saved. This allowed the interface to stay helpful without making it responsible for enforcing the rules.

Designing for different screens

I designed Brb in Figma before building the interface and created a small design system for colour, typography, interaction states and reusable components.

Responsive behaviour goes beyond simply shrinking the desktop layout. Navigation changes from a sidebar to a bottom navigation bar on smaller screens, while data tables become labelled cards so information remains usable without horizontal scrolling.

I also built shared loading, empty and error states so asynchronous parts of the application behave consistently rather than each screen handling them differently.

Accessibility as part of the implementation

I designed and tested the interface against WCAG 2.2 AA requirements. This includes keyboard navigation, visible focus states, contrast, minimum touch targets, responsive reflow and alternatives to colour-only status indicators.

Accessibility requirements are also reflected in the automated tests. The Cypress suite checks behaviour at a 320px viewport and 200% text zoom, along with keyboard focus, contrast and other accessibility criteria.

Testing beyond individual components

Testing covers the application at several levels. The React client uses Vitest and React Testing Library, while the API has its own Jest test suite covering services, controllers, routes, entities, authentication and permissions.

I also created 27 Cypress specifications covering complete workflows such as booking and cancelling leave, manager approvals, employee administration, protected routes and cross-role behaviour.

The repository also includes continuous integration for both sides of the application. Every push and pull request is type-checked, linted, formatting-checked and tested before it can be treated as passing.

Building the full stack

One of the parts I enjoyed most about Brb was having ownership of both the application and the API behind it. The client has a shared request layer for authentication, error handling and short-lived caching, while the backend separates routing, controllers, services and database access.

Being able to work across those layers meant I could change the system itself when a feature needed it, rather than forcing the interface to work around limitations in the API.