One Console, Three Platforms
Jahez, HungerStation and Keeta share a single shell. The sidebar, routes and default landing page are built from each organisation’s access, so users only see the platforms they run.
Case StudyLive
RABEHFleet Operations Dashboard
Fig. 01
Desktop · Laptop · Tablet · Phone
- 01Role
- Frontend Engineer
- + Architecture
- 02Duration
- Sep – Oct 2026
- Rewrite of the legacy app
- 03Team
- 3 People
- Small product team
- 04Status
- Live
- In production
Project Purpose
Why it exists
Rabeh is an internal operations dashboard for companies that run delivery fleets on several last-mile platforms at once. Dispatchers used to jump between separate back offices for Jahez, HungerStation and Keeta to see who is working, who is idle and who owes cash. Rabeh puts all three behind one login, one sidebar and one consistent set of reports — with Excel export, Arabic/English (RTL) support and per-organisation access control.
This case study covers the front-end rewrite: a typed, feature-sliced React codebase that replaced a large legacy app, with every report page code-split and a shared set of table, filter and chart components.
Collaborators
The team
Ahmed Mamdouh
Contributor
Muhammad Allam
Contributor
Tools & Technologies
What it's built with
- 01React 19
- 02TypeScript
- 03Vite
- 04Tailwind CSS
- 05Ant Design
- 06TanStack Query
- 07React Router
- 08Socket.IO
- 09Git
Features
What it does best
04
Core Features
Live Fleet Dashboards
Attendance, rider status and order acceptance at a glance. Donut charts are clickable — tap a status to open the exact list of riders behind the number.
Report Tables With Excel Export
Server-paginated tables with composable filters (rider, date range, city, cash balance) and a one-click export that reuses the active filters.
Arabic & English, RTL-Aware
Full translation files for both languages. Direction, sidebar side and chart legends flip with the language, and the choice is remembered.
More Features
Beyond the essentials
Role & Feature-Based Access
Admins, per-platform specialities, permission codes and organisation feature flags are checked by one guard, used by both the router and the menu.
Driver Records & Money Tools
Edit driver details inline and manage car rent, sponsorship fees, commissions, debt, fuel, daily targets and alternative drivers from modals.
Code-Split By Page
Every report page is its own lazy chunk, so the first load only ships the shell and the page you open.
App Screens
Inside the product
Dashboard
Dashboard
Fleet Overview
The HungerStation landing page: active-driver percentage, total / accepted / declined orders, attendance and rider-status donuts, and the ten riders holding the most cash. Each donut slice drills down into the riders behind it.
- Recharts
- TanStack Query
- Drill-down modal
Reports
Reports
Daily Performance Report
A paginated report of shifts, planned versus actual hours, acceptance rate and delivery counts per city and day. Filters sit above the table and the Excel export honours whatever is applied.
- Server pagination
- Filter form
- Excel export
Rankings
Rankings
Top Riders
Two leaderboards side by side — by working hours and by completed deliveries — sharing one filter bar. Working hours are shown as h:m cells so decimal hours never get misread.
- Dual tables
- Date range filter
- Shared filters
Localisation
Localisation
Right-to-Left Layout
Switching to Arabic mirrors the whole app: the sidebar moves to the right, the header controls swap sides and chart legends re-flow — from the same components, without a separate RTL stylesheet.
- i18next
- RTL
- Logical CSS
Access
Access
Sign-In
A minimal login that decides everything after it: the response sets the user’s role, platforms, permissions and feature flags, and the router builds the menu from them.
- JWT
- React Hook Form
- Zod
Problems & How We Solved Them
Hard problems, solved
The problem
Three platforms, three different permission models
The solution
Instead of scattering role checks through pages, every route carries an access rule (platform, permission code, feature flag) and a single guard evaluates it for both the router and the sidebar. The default landing page is also derived from what the user can open, so nobody lands on a page they cannot see.
The problem
Inconsistent API response shapes across endpoints
The solution
List endpoints answer with arrays, `results`, `data`, `riders` or named keys, and some return HTTP 200 with an internal 500 status code. A small normaliser turns every list into the same `{ records, total }` shape, and a shared report factory builds the fetch + Excel pair for each page.
The problem
Keeping a large app fast and consistent
The solution
Pages are lazy-loaded one by one, server state lives in TanStack Query with centralised query keys (so the header reload button knows what to refresh), and tables, filters, stat cards and donut charts are shared components rather than per-page copies.
Outcomes
The results, by the numbers
0
Delivery platforms unified
0
Report pages
0
Languages with RTL
0
Commits in the rewrite