Overview
Cycla is a fitness app built around one idea: your body isn't the same every day, and your training shouldn't be either. It adapts workouts based on cycle phase, hormonal conditions, daily energy, and symptom check-ins - not with a generic content filter, but through a semantic architecture that makes every screen condition-aware.
I'm building Cycla as a solo founder, handling product strategy, UX design, development, and content. It's also where I'm applying the same thinking I use in design systems - variables, conditions, modular architecture - to a completely different domain.
The challenge
Most fitness apps treat cycle syncing as a content layer: "you're in luteal, here's a yoga video." But hormonal health is far more nuanced. A user with PCOS has different needs than someone with endometriosis, and both differ from someone in perimenopause. Even within the same condition, individual patterns vary wildly - some people are strongest the week before their period, not weakest.
The challenge was to design a system that respects this complexity without overwhelming the user. Not just adapting which workout to show, but how the entire experience - intensity, messaging, rest recommendations, exercise selection - responds to each person's physiological reality.
Condition Mode as architecture
The core differentiator of Cycla is what I call Condition Mode. Rather than treating hormonal conditions as edge cases or add-on features, I designed them as first-class variables in the system architecture - the same way a design system treats brand themes or responsive breakpoints.
Each condition (PCOS, endometriosis, Hashimoto's, perimenopause, and others) defines a ConditionConfig - a typed object that carries modifiers for intensity, exercise selection, recovery pacing, nutrition prompts, and alert thresholds. These configs compose and merge for users with multiple conditions, with clear priority rules when modifiers conflict.
This means the app doesn't have "a PCOS mode" - it has a condition-aware architecture where PCOS is one of many possible configurations. Adding a new condition is extending a type, not rebuilding flows. The design system thinker in me finds this deeply satisfying.
The adaptation engine
The recommendation engine works in four layers, each one able to override the previous:
Layer 1 - Phase-based foundation
New users start with evidence-based defaults per cycle phase. Follicular leans toward higher intensity, luteal toward lighter sessions. This is the baseline, not the ceiling.
Layer 2 - Condition modifiers
Eight conditions each adjust the baseline. Endometriosis adds flare-up awareness and pain-responsive exercise swaps. PCOS prioritizes vigorous intensity and strength work. Menopause focuses on bone-loading exercises and extended rest periods.
Layer 3 - Daily check-in overrides
Every session starts with a quick check-in: energy, motivation, sleep quality, and symptom reporting. If you're in luteal but report high energy, the app listens to you, not the textbook. This is where the system breaks from generic cycle syncing.
Layer 4 - Adaptive intelligence
A Claude-powered reasoning layer sees the full picture: current check-in, phase, conditions, workout history, and symptom patterns. It returns a personalized intensity modifier and can override any phase-based suggestion. After 2–3 cycles, the app detects personal energy patterns using linear regression, blending up to 80% personal data with 20% static baseline.
Design decisions
Onboarding as trust-building
Asking someone to disclose hormonal conditions on screen three of an app is a sensitive moment. I designed the onboarding flow as three steps - introduction, condition selection, confirmation - with clear language about why we're asking and how the data shapes their experience. Every persona must complete setup, including users with no conditions.
Messaging that adapts, not just workouts
Condition Mode doesn't just change the workout. It changes the copy. A rest day suggestion for someone with endometriosis reads differently than for someone in early follicular. The app's tone shifts based on energy levels - encouraging when motivation is low, celebrating when someone pushes through a tough phase.
Designing for "I don't know"
Many users with PCOS don't have regular cycles and can't answer "when was your last period." I added explicit "I don't know" paths throughout setup, so the app gracefully degrades to condition-based recommendations without requiring cycle data it can't trust.
Testing with personas
I created six detailed personas - each representing a different condition, fitness level, and life context - and ran week-long simulated walkthroughs to stress-test the engine. The results were humbling:
- 42% overall accuracy in the first round - the engine was silently failing for several condition types
- 38 issues identified across 6 personas, organized into 5 implementation sprints
- 0% accuracy for menopause and iron deficiency personas - revealing critical gaps in the modifier system
- Regular cycle users scored highest at 75%, confirming the foundation worked but conditions needed deep fixes
This process - treating persona walkthroughs as system audits - directly mirrors how I benchmark components in design systems. Log everything, score it, size the problem, then prioritize fixes by impact.
Current status
Cycla is currently in testing with a four-week sprint plan targeting a TestFlight beta with 20–50 users. The sprint structure follows a clear dependency chain: hotfix critical engine failures, complete the core engine contract, fix onboarding for all personas, then layer in condition intelligence and polish.
The goal is App Store launch by mid-2026, with the freemium model built around Condition Mode as the premium differentiator - because that's where the real value lives.
Learnings
Design system thinking transfers
The mental models from design systems - variables, conditions, composable architecture, adoption strategy - mapped directly onto building a product. Condition Mode is essentially a theme layer. The adaptation engine is a token resolution pipeline. Thinking in systems made the complexity manageable.
Being your own user is an unfair advantage
I train with this app. I live the problem every day. That empathy isn't something you can synthesize from user interviews alone - it's a design material that shapes every micro-decision, from check-in flow timing to how rest days are framed.
Persona testing reveals what prototypes can't
Running six personas through week-long simulations caught issues that no amount of screen-by-screen review would have surfaced. The 42% accuracy score was a reality check that redirected the entire sprint backlog.
Wearing all hats forces prioritization
As a solo founder doing design, development, and strategy, every decision has a direct cost. This forced a discipline I hadn't experienced in agency or enterprise work: ruthless scoping, shipping the smallest useful increment, and accepting that some things are intentionally incomplete.