Back to Case Studies
Case Study

PulseForge Platform

A coaching and performance platform drawn from real domain experience. Architecture complete; implementation in progress — included to show domain-driven design, not a finished product.

In Development. The architecture is complete and implementation is in progress. This write-up documents the design, not a finished product.

·Arman Hazrati
Full-StackSaaSFitnessTypeScriptNext.jsPostgreSQLDomain Expertise
Explore the architecture
ClientCoach & Client AppsNext.js · ReactAPIREST APINestJSAccessTenant Scope + RBACper-request isolationDomainCoachingClientsProgramsCheck-insAsyncScheduled Jobsqueue-backedDataPostgreSQLmulti-tenantRedis
Multi-tenant by design: isolation enforced in the query layer, not the DB boundary.

PulseForge Platform

Intelligent Coaching & Performance Infrastructure

A production-grade coaching platform built from first-hand domain experience and engineered with enterprise standards.


Overview

PulseForge is a full-stack coaching and performance management platform designed for:

  • Personal trainers scaling their practice
  • Combat sports and kickboxing coaches
  • Hybrid online/offline coaching businesses
  • Small studios expanding into digital products

This is not a workout tracking app or a fitness social network. PulseForge is the operating system for a coaching business—handling client management, program delivery, progress tracking, analytics, and automation.

Problem Statement

Traditional coaching businesses face compounding operational friction:

Fragmented Tools

Coaches juggle spreadsheets, messaging apps, payment processors, and scheduling tools. Client data lives in 6+ places with no integration.

Manual Progress Tracking

Every check-in requires manual data entry. Coaches spend hours reviewing notes instead of coaching.

Poor Client Retention

Without visibility into engagement patterns, coaches only discover problems when clients cancel.

No Scalability Path

One-on-one coaching doesn't scale. Most coaches plateau at 15-20 clients regardless of demand.

Zero Automation

Every reminder, check-in, and follow-up is manual. Coaches burn out on operations, not coaching.

PulseForge solves these by providing a unified platform where data flows automatically and coaches focus on what matters—their clients.

System Architecture

High-Level Design

The interactive map above shows the platform as one multi-tenant system: client apps hit a NestJS API, every request is tenant-scoped and authorized, domain modules handle coaching, clients, programs, and check-ins, and a queue runs scheduled work. Switch to the Multi-tenancy and Check-in flow layers to see how isolation is enforced and how cadence-based work moves through the queue.

Technology Stack

LayerTechnologyRationale
FrontendNext.js, TypeScriptServer components, type safety
APINode.js/NestJSModular, scalable, tested
DatabasePostgreSQLRelational integrity, JSONB flexibility
CacheRedisSession, rate limiting, real-time
QueueBullMQNotifications, reports, cleanup
AuthJWT + RefreshSecure, stateless, mobile-ready

Role-Based Access Control

Coach Role

  • Create and manage training programs
  • View all assigned clients
  • Track client progress and compliance
  • Send messages and feedback
  • Access performance analytics
  • Configure automation rules

Client Role

  • Access assigned programs
  • Log workouts and metrics
  • Submit feedback (RPE, notes)
  • View progress history
  • Message coach
  • Receive automated notifications

Admin Role

  • Platform configuration
  • User management
  • Audit log access
  • Analytics and reporting
  • Billing oversight

Core Features

1. Program Builder

Coaches create periodized training programs with:

  • Exercise Library — Searchable database with movement patterns, muscle groups, equipment filters
  • Session Templates — Reusable workout structures
  • Progression Logic — Auto-progression rules based on performance
  • Injury Modifications — Alternative exercises flagged per client
  • Periodization — Mesocycle and deload planning

2. Client Progress Tracking

Automatic and manual data collection:

  • Workout completion status
  • RPE (Rate of Perceived Exertion) per session
  • Body metrics (weight, measurements)
  • Performance metrics (strength, endurance markers)
  • Compliance scoring
  • Trend analysis

3. Analytics Dashboard

Coaches see at-a-glance:

  • Client adherence rates
  • Average workout completion
  • Progress velocity
  • Risk flags (declining engagement, overtraining signals)
  • Revenue metrics (if payments integrated)

4. Communication System

  • Secure in-app messaging
  • Session notes and feedback
  • Coach annotations on workouts
  • Rich media support (form videos)

5. Automation Engine

Configurable triggers:

  • Missed Session — Reminder after X hours
  • Inactivity Alert — Flag after X days without logging
  • Progress Check-in — Weekly summary to client
  • Goal Milestones — Celebration notifications
  • Program Completion — Follow-up prompts

Data Model

Core Entities

User

  • Authentication identity
  • Role assignment (coach, client, admin)
  • Profile information
  • Preferences and settings

CoachProfile

  • Business information
  • Specializations
  • Client capacity
  • Automation preferences

ClientProfile

  • Assigned coach
  • Goals and constraints
  • Injury history
  • Body metrics timeline

Program

  • Coach-created training plan
  • Start/end dates
  • Periodization structure
  • Assigned clients

Session

  • Individual workout
  • Exercise list with sets/reps
  • Scheduled date
  • Completion status

WorkoutLog

  • Client's recorded performance
  • RPE and feedback
  • Timestamps
  • Deviation from prescribed

Message

  • Coach-client communication
  • Thread structure
  • Read receipts
  • Attachments

Security & Privacy

Data Protection

  • Encryption at rest — Sensitive fields encrypted in database
  • Encryption in transit — TLS everywhere
  • Data isolation — Strict coach-client boundaries
  • Audit logging — All data access tracked

Authentication

  • JWT with short expiry
  • Refresh token rotation
  • Session invalidation on password change
  • Rate limiting on auth endpoints

Privacy Considerations

  • GDPR-compatible data export
  • Right to deletion support
  • Minimal data collection principle
  • No third-party tracking

Performance Optimization

Client-Side

  • Server components for initial load
  • Optimistic UI updates
  • Image optimization
  • Service worker caching

Server-Side

  • Connection pooling
  • Query optimization with indexes
  • Redis caching for frequent reads
  • Background job offloading

Database

  • Strategic indexes on filter columns
  • Materialized views for analytics
  • Partitioning for historical data
  • Soft deletes for recoverability

Deployment Architecture

Infrastructure

  • Docker containers
  • Horizontal scaling ready
  • Environment-based configuration
  • Health check endpoints
  • Prometheus metrics

CI/CD Ready

  • Automated testing pipeline
  • Staging environment
  • Database migrations versioned
  • Feature flags for rollout

Why This Platform Exists

PulseForge is built from direct experience in the fitness industry.

I understand:

  • How coaches actually work day-to-day
  • Where their time gets wasted
  • What makes clients succeed or fail
  • The gap between fitness apps and real coaching

This isn't a generic SaaS template adapted to fitness. Every feature addresses a real operational problem coaches face.

Business Model Viability

PulseForge is designed as a commercial product:

  • SaaS Subscription — Per-seat pricing for coaches
  • Freemium Tier — Limited clients, basic features
  • Pro Features — Advanced analytics, automation, white-label
  • API Access — Integration with scheduling, payments

Tradeoffs

Because this is a deliberate design (architecture complete, build in progress), the tradeoffs are choices made on paper with eyes open:

  • Shared multi-tenant database over per-tenant isolation — simpler to operate and cheaper at small scale; accepts that strict data isolation must then be enforced carefully in the query layer rather than by the database boundary.
  • Queue-backed check-ins over real-time push — coaching cadence is daily/weekly, not millisecond; a scheduled job runner fits the domain and avoids the cost of always-on real-time infrastructure.
  • Opinionated coaching model over a generic builder — fits how coaches actually work and keeps the UX focused; costs some flexibility for edge-case workflows.

The hardest part of a coaching platform isn't the code — it's modeling how coaches and clients actually behave. The architecture follows the domain, not the other way around.

Decision Log

The architectural choices made on paper, with the alternatives weighed and the cost of each accepted up front.

DecisionWhy it was chosenAlternative consideredTradeoff accepted
Shared multi-tenant databaseSimple to operate and cheap at early scalePer-tenant database isolationData isolation must be enforced carefully in the query layer, not by the DB boundary
Queue-backed check-insCoaching cadence is daily/weekly, not millisecondAlways-on real-time pushSlight delay on updates in exchange for far less infrastructure
Opinionated coaching modelMatches how coaches actually work; focused UXGeneric, configurable program builderLess flexibility for edge-case workflows
Schema-first designSurfaces real relationships (coach → client → program → check-in) earlyUI-first, schema followsMore upfront modeling before any screens exist

Failure Modes

The risks I'm designing against before the build, where the consequences are highest:

  • Cross-tenant data leakage. A missing tenant filter exposes one coach's clients to another. Mitigation: tenant scoping enforced in a single data-access layer plus tests that assert isolation.
  • Check-in job backlog. A scheduled run falls behind or fails silently. Mitigation: idempotent, observable jobs with retries and dead-letter handling.
  • Data model rigidity. An opinionated schema resists workflows it didn't anticipate. Mitigation: model the core relationships tightly, keep extensible fields for the edges.
  • Multi-tenant noisy neighbor. One large coaching org degrades others on shared infrastructure. Mitigation: per-tenant rate limits, with per-tenant isolation as a planned escape hatch at scale.
  • Operational blind spots pre-launch. Building against a paper design risks unknowns at first real load. Mitigation: instrument the core paths from the first implementation milestone.

Lessons Learned

  • Domain experience is leverage. Knowing where a coach's time is wasted shaped the data model more than any framework choice did.
  • Designing the schema before the screens surfaced the real relationships (coach → client → program → check-in) early, before they were expensive to change.

Future Improvements

  • Build out the implementation against the completed architecture, starting with the coach/client core.
  • Add automated progress analytics once enough real check-in data exists to make them meaningful.
  • Evaluate per-tenant data isolation if the platform reaches a scale where it's warranted.

What This Demonstrates

Domain-Driven Design

Features built from real industry knowledge, not generic patterns.

Full-Stack Capability

Frontend, backend, database, infrastructure—end to end.

Product Thinking

Not just code, but a viable business solution.

Security Awareness

User data protection as foundational, not afterthought.

Scalability Planning

Architecture that grows with the business.


Technical Specifications

Frontend: Next.js 15, TypeScript, Tailwind CSS, Framer Motion
Backend: Node.js, NestJS, Prisma, PostgreSQL
Infrastructure: Docker, Redis, BullMQ
Auth: JWT, bcrypt, RBAC
Testing: Jest, Playwright, Vitest

Status: Architecture Complete, Implementation In Progress
Role: Full-Stack Architect & Developer


Built from first-hand domain experience and engineered for production deployment.