Cycla

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 a single daily check-in, hormonal conditions, and optional cycle context - not with a generic content filter, but through a semantic architecture that makes every screen respond to how you actually feel today.

The product has one organizing principle: the check-in is the product, and everything else is context. In about twenty seconds you report energy, symptoms, sleep, and mood. That generates an energy score that drives session type, intensity, volume, and exercise selection. Cycle phase, when you choose to track it, is one input among several, never the thing dictating your training.

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.

To ground this in lived experience rather than clinical averages, I spent months reading condition communities on Reddit, where people openly discuss the day-to-day reality of PCOS, endometriosis, PMDD, perimenopause, and more. Those public discussions surfaced patterns no research paper captured: how a flare-up actually derails a training week, the frustration with apps that assume a regular cycle, the language people use to describe their own energy. This qualitative research shaped both the condition modifiers and the tone of the product.

I organized everything into a single Notion knowledge base, a research "brain" that gathers the studies, community findings, and condition logic in one place. It became the source of truth behind every ConditionConfig, so each modifier can be traced back to either published research or a documented lived-experience pattern, not a guess.

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 of the 18 supported conditions (PCOS, endometriosis, adenomyosis, PMDD, perimenopause, menopause, Hashimoto's, insulin resistance, postpartum recovery, hypothalamic amenorrhea, iron deficiency, and others) defines a ConditionConfig - a typed object that carries modifiers for intensity, exercise selection, recovery pacing, nutrition prompts, and alert thresholds. Each pipeline is built from published research. 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 eighteen 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 engine is built check-in first. The daily report is the driver, and every other layer exists to sharpen it, not to override how you actually feel:

Layer 1 - The daily check-in

Every session starts with a roughly twenty-second check-in: energy, symptoms, sleep quality, and mood. This produces an energy score from 1 to 10 that determines session type, intensity, volume, and exercise selection. This is the foundation the rest of the system reads from.

Layer 2 - Safety filters and condition modifiers

The check-in passes through safety filters, then condition-specific logic. Each of the 18 conditions adjusts the session. 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 - Optional cycle context

Cycle entry is completely optional, and the app works fully for irregular cycles, absent cycles, or people on hormonal contraception. When cycle data exists, phase becomes one more input that colors the recommendation. It is never the thing deciding your training. Your check-in is.

Layer 4 - Adaptive intelligence

A Claude-powered reasoning layer sees the full picture: current check-in, conditions, optional phase, workout history, and symptom patterns. It returns a personalized intensity modifier and can refine any baseline suggestion. Over weeks, the app detects personal energy patterns using linear regression, blending up to 80% personal data with 20% static baseline, so it learns how your energy, symptoms, and conditions interact for you specifically.

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 - built directly from the real accounts I read in condition communities, so the pain points and daily patterns were rooted in how people actually describe their experience. I then ran week-long simulated walkthroughs to stress-test the engine. The results were humbling:

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 in early access with public signup open at getcycla.app, targeting a Spring 2026 launch. 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.

Wearable integration is next on the roadmap. Apple Watch, Oura Ring, Garmin, and Whoop will feed HRV, sleep quality, body temperature, and recovery data straight into the daily check-in, so the score that drives each session gets even more grounded in real signals.

The model is freemium, built around condition-aware adaptation 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.