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.
Keyboard: ← → switch layers · Home End first/last
Switch between the full story and engineering evidence.
PulseForge Platform
Coaching Platform — In Development
After years in fitness coaching, I kept seeing the same pattern: coaches juggling fragmented tools, manual follow-ups, and no real visibility into client accountability. PulseForge is my attempt to model coaching workflows directly in software — not force coaches to adapt to generic CRMs.
Architecture and domain design are complete; implementation is in progress. This case study documents how I think about the system, not a shipped product.
Overview
PulseForge is the operating system for a coaching business — client management, program delivery, progress tracking, and automation. Not a workout tracker. Not a fitness social network.
Built for personal trainers, combat sports coaches, and small studios moving into digital products.
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, Check-in flow, and Coach lifecycle layers to see isolation, cadence, and the domain path.
Engineering depth
PulseForge is architecture-complete, implementation in progress. The artifacts below are planned contracts and schema — honest design decisions made before code ships, not production metrics.
Engineering artifacts
// Planned schema (design intent) — core coaching relationships
model Workspace {
id String @id @default(uuid())
coachId String @unique
name String
clients Client[]
programs Program[]
@@map("workspaces")
}
model Client {
id String @id @default(uuid())
workspaceId String // tenant scope — every query filters here
coachId String
programs ProgramAssignment[]
checkIns CheckIn[]
@@index([workspaceId])
}
model CheckIn {
id String @id @default(uuid())
clientId String
workspaceId String // redundant scope for defense in depth
cadence CheckInCadence // DAILY | WEEKLY
dueAt DateTime
status CheckInStatus
}Architecture evolution
v1 — generic fitness app
First sketch looked like a workout tracker: exercises, sets, social feed. It solved athlete logging, not coach operations.
Problem
Coaches do not fail because they lack exercise libraries. They fail because client data lives across spreadsheets, DMs, and payment tools — follow-ups are manual and retention is invisible until cancellation.
v2 — coach-centric domain
Re-centered on coach workspace → client roster → programs → check-ins → progress. The data model follows how a coaching business actually runs week to week.
Current (designed)
Multi-tenant NestJS API with tenant-scoped queries, queue-backed check-ins, and a Next.js client. Building toward a public repo when the coach/client core is testable.
Engineering mistakes
Design mistakes caught before ship — cheaper than production incidents.
Almost modeled check-ins as real-time events
- What broke
- First draft used WebSocket push for every client log entry. That fits a chat app, not weekly coaching cadence — and would have forced always-on infra from day one.
- What I changed
- Switched to scheduled BullMQ jobs (daily/weekly). Coaching rhythm is batch-oriented; the queue matches the domain.
Considered per-tenant databases early
- What broke
- Clean isolation story, but operational cost (migrations × N tenants) would have blocked solo development before product-market fit.
- What I changed
- Shared PostgreSQL with tenant_id on every row + default scoped filters in the data layer. Isolation tests planned as a first-class suite.
UI-first wireframes before schema
- What broke
- Screen mocks hid the real relationships — a client belongs to a coach workspace, not a global user pool.
- What I changed
- Schema-first pass: Coach → Client → Program → CheckIn → ProgressSnapshot. Screens follow the model, not the other way around.
Rejected alternatives
Judgment means saying no with a reason, not picking the trendy option.
| Decision | Alternatives | Why rejected | Tradeoff accepted |
|---|---|---|---|
| Shared multi-tenant database | Database-per-tenant, schema-per-tenant | Per-tenant DBs multiply migration and backup cost before revenue. Schema-per-tenant adds connection complexity without solving the real risk (missing tenant filter). | A tenant-scoping bug could leak data — mitigated with default filters and isolation tests. |
| Queue-backed check-ins | Real-time WebSocket push, cron-only scripts | Push is over-engineered for daily/weekly cadence. Cron alone lacks retry and observability. | Updates are slightly delayed vs instant — acceptable for coaching workflows. |
| Opinionated coaching model | Generic no-code program builder | Generic builders optimize for flexibility coaches never use. Domain fit beats configurability at this stage. | Edge-case workflows may need workarounds until the model proves itself. |
| JWT + tenant claim in token | Session cookies only, subdomain-per-tenant routing | Mobile-ready API needs stateless auth. Subdomain routing adds DNS/SSL ops early. | Tenant must be validated on every request — resolver middleware is mandatory. |
What I would do at 10× scale
PulseForge is designed for coaching businesses from solo coaches to small studios — not enterprise gym chains. Growth path below is intentional, not claimed production load.
Current design
- Multi-tenant monolith: NestJS modules (coaching, clients, programs, check-ins)
- Shared PostgreSQL with tenant-scoped Prisma middleware
- Redis + BullMQ for scheduled check-in and notification jobs
Bottlenecks at 10×
- Shared DB hot rows on check_in and progress tables for large rosters
- Single queue for all tenants — noisy neighbor on job backlog
- Tenant filter omission is the highest-severity bug class
How I'd evolve it
- Per-tenant rate limits on API and job enqueue
- Read replicas for analytics and progress dashboards
- Queue partitioning by tenant_id hash for large orgs
- Per-tenant database isolation as an escape hatch for enterprise coaches — not default
- Extract check-in worker service when job volume exceeds single worker pool
Capacity note: Architecture sized for growth beyond initial launch; future scaling path includes service decomposition and optional per-tenant isolation — not current capacity claims.
Technology Stack
| Layer | Technology | Rationale |
|---|---|---|
| Frontend | Next.js, TypeScript | Server components, type safety |
| API | Node.js/NestJS | Modular, scalable, tested |
| Database | PostgreSQL | Relational integrity, JSONB flexibility |
| Cache | Redis | Session, rate limiting, queue backing |
| Queue | BullMQ | Notifications, reports, cleanup |
| Auth | JWT + Refresh | Secure, 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 (planned — post-MVP)
- Platform configuration and cross-tenant support
- User management outside coach workspaces
- Audit log access and billing oversight
MVP authorization uses Coach and Client roles only, scoped per workspace. A platform-operator admin role is deferred until multi-tenant ops require it.
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
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
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.