PulseRep is a gym management dashboard and member fitness app that I designed and built in Next.js 16 as a frontend reference build. It gives members, trainers and gym admins separate workspaces, covering workouts, streaks and achievements, coaching, memberships and revenue analytics, all running on a mock data layer so a real backend can be attached later. It uses React 19, Tailwind CSS v4, Motion and Recharts.
The problem
A gym product has at least three kinds of user, and they want different things from the same data. A member wants to know what to train today and whether they are getting stronger. A trainer wants their assigned members and plans in one view. Whoever runs the gym cares about memberships, staff and revenue. Put all three in front of one admin-style table and none of them is served well.
I wanted to design the frontend for a gym management dashboard that covered all three, and do it without pretending a backend existed. The aim was a build a team could take and connect to their own API, and a test of whether one design system could carry three very different roles. For members I leaned into game mechanics, streaks, XP and achievements, because a progress screen that rewards showing up gives people a reason to open it again.
My role
I designed and built PulseRep: the three workspaces, the theme tokens and component primitives, the motion, the mock data, the public pages and the SEO setup. It is a frontend demo. There are no real gyms, trainers or members behind it, and the site says so in its own header.
Architecture and tech stack
Three workspaces behind one role switch
Member, Trainer and Admin each get their own navigation and screens, and a switch in the top bar moves between them, with the choice kept in localStorage. Anyone reviewing the build can see all three roles in a minute without three logins. I used the same idea for the operator personas in MedSalve, my pharmacy management frontend.
A mock data layer in place of an API
Every screen reads from a mock data layer instead of calling a server. That keeps the demo free to host and fast to explore, and it draws a clear line for whoever wires it up later: replace the data layer and the screens stay as they are.
Theme tokens and a shared primitive set
Lime, cyan and magenta accents live as custom theme tokens in Tailwind CSS v4, with dark and light variants. Card, Badge, Button, Avatar, Tabs, Tooltip and Dialog are written once and used in every workspace, so a trainer's plan list and an admin's revenue panel are visibly part of the same product.
Motion and Recharts for feedback
Progress only motivates if it feels like it moved. Motion drives route transitions, staggered lists, animated counters and progress rings, and Recharts draws the workout and revenue charts with animation on load. The bigger effects, flame flickers on a streak and confetti for a milestone, are kept for streaks and milestones.
Key features
- Member workspace: dashboard, workouts, attendance, achievements, journey and membership.
- Trainer console: assigned members, a plans library and messaging.
- Admin suite: member and trainer management, memberships and revenue analytics.
- Gamified progress: streaks, XP levels and achievements, with confetti for milestone moments.
- Role switching from the top bar, remembered in localStorage.
- Dark and light themes built on custom tokens.
- Public pages: a landing page, About the Developer, Privacy and Terms on a shared shell, and a site footer with legal links and 8 social channels.
Challenges and how I solved them
Realistic numbers that are clearly fake
- Problem
- A dashboard full of believable figures, a 28-day streak, revenue charts, member counts, is exactly what makes a demo convincing. It is also what could make someone think a real gym is using it.
- Solution
- The header carries a "v1 demo · mock data" label, and the footer states that it is a frontend-only demo and that no data leaves the browser. The dashboard routes are marked noindex, so the mock screens never show up in search results looking like a live service.
SEO for an app that lives behind a role
- Problem
- Most of PulseRep is app screens that should not be indexed, but the public pages still need to be found and to look right when shared.
- Solution
- Each public route has its own metadata through a title template, Open Graph images are generated per route with next/og, and Person, Organization and WebSite JSON-LD, canonical URLs, a sitemap and a robots route complete the setup.
Motion that does not wear people out
- Problem
- A dashboard someone opens every day gets tiring fast if everything on it moves.
- Solution
- Everyday motion stays small and quick: hover-lift cards, staggered lists, counters that settle. Heavier effects are tied to events, so confetti still means something when it appears.
Results
PulseRep is live at pulserep.abdullahawais.com. From the landing page a visitor can enter as a member, a trainer or an admin and switch between them at any point. It shares its stack, Next.js 16, Motion and Recharts, with Aubade, my LMS frontend, which took the same tools in a much quieter, editorial direction.
What's next
The natural next step is a real backend: authentication, roles enforced on the server rather than in localStorage, and persistent workout and attendance data. The role model would follow the one I built with a database behind it in my MERN team management system.
