Health & Wellness Marketplace Admin Panel

Project overview

A health and wellness marketplace needed one dependable place to run daily operations. Customers booked sessions with yoga teachers, nutritionists, and fitness professionals, but staff managed provider approvals, refunds, promotions, and reports across spreadsheets and disconnected tools. I led development of a responsive admin panel that brought those workflows into a single application without forcing non-technical operators to understand the underlying services.

The project covered product discovery, information architecture, full-stack implementation, cloud integration, and release monitoring. It also established reusable table, chart, form, and permission components that later features could adopt without rebuilding common behavior.

Problem statement

Operational volume had outgrown the manual process. Provider verification took several days because identity documents moved through email. Support agents could not see a booking and its payment history together. Broad administrator accounts created unnecessary access to financial data, while limited audit trails made sensitive changes difficult to investigate.

The system needed to:

• give each team a focused workspace;
• support large, searchable datasets without slow pages;
• make destructive actions deliberate and traceable;
• surface business KPIs without a separate reporting product;
• protect personal, professional, and payment information.

Solution and architecture

I built a React single-page interface with TailwindCSS and a Node.js/Express API. MongoDB stored operational data, with compound indexes for booking status, provider verification state, and transaction dates. Redis cached dashboard aggregates and short-lived lookup data. Documents were uploaded directly to private AWS S3 paths through signed URLs, keeping large files away from the API server.

Role-based access control was enforced on both the route and service layers. Permissions such as booking.refund and provider.approve were assigned to roles rather than hard-coded into pages:

export const requirePermission = (permission) => (req, res, next) => {
  if (!req.user.permissions.includes(permission)) {
    return res.status(403).json({ message: "Insufficient permission" });
  }
  return next();
};

Every high-risk mutation recorded the actor, previous value, new value, request identifier, and timestamp in an append-only audit collection. Confirmation dialogs clearly explained refund, suspension, and deletion effects. CloudWatch metrics and structured logs made failed integrations and slow aggregation queries visible after release.

What shipped

• A KPI dashboard for bookings, revenue, active users, and provider performance.
• Verification queues with secure document previews and approval checklists.
• Unified booking, transaction, refund, and customer-support histories.
• Promotion rules with expiry dates, limits, targeting, and usage reporting.
• CSV exports generated as background jobs instead of blocking web requests.
• Responsive tables, saved filters, pagination, and accessible keyboard states.

Outcomes

The new workflows reduced repetitive operations work by an estimated 60%. Provider onboarding became 45% faster, mainly because reviewers no longer searched through email threads and could see missing requirements immediately. Cached metrics and indexed queries kept typical API responses below 220 ms, while the principal dashboard maintained a 90+ Lighthouse performance score.

Audit logs and narrower roles also shortened incident reviews and reduced the number of staff accounts with payment permissions. The component system made later reporting modules quicker to deliver and visually consistent.

Key engineering decisions

The dashboard deliberately remained a modular monolith during this phase. The operational domains were clearly separated in code, but deploying them together kept transactions, local development, and incident ownership understandable for the team size. Background exports and notifications were moved to workers because their scaling and failure behavior differed from interactive requests; the rest did not need premature service boundaries.

Analytics cards read from precomputed daily summaries with a visible “last updated” value. Operators could still open the underlying live table when exact current state mattered. This tradeoff kept the landing dashboard predictable without presenting cached metrics as real time. Risky actions used reason fields and previewed affected records before confirmation. Those product details mattered as much as API authorization: they reduced accidental changes while leaving an evidence trail support and compliance teams could interpret.

Related engineering work

The query and aggregation approach builds on the techniques in MongoDB performance tuning for modern apps. For the security decisions behind permission checks, validation, and logging, see cybersecurity for developers. The customer-facing commerce work is covered in the related e-commerce platform case study.