Flexin

Problem and motivation

Workout tracking is often private and data-heavy, while social fitness products can feel disconnected from the training itself. Flexin explores a narrower interaction: one photo or short video Check-In per session, paired with the workout context that made it meaningful.

The product combines social accountability with practical training tools. Active Check-Ins appear in a friend feed, profiles preserve selected milestones, and training features provide a place to plan and review exercise, nutrition, and health information.

Goals and constraints

• Keep posting fast enough to fit naturally at the end of a workout.
• Support photos and short videos without making feed performance unpredictable.
• Respect audience controls and avoid exposing private account information.
• Coordinate Flutter UI, Firebase services, notifications, purchases, health data, and native iOS behavior.
• Design failure states that explain what happened instead of leaving dead or ambiguous controls.

System architecture

The Flutter client owns the cross-platform product experience. Firebase provides authenticated data, media storage, and server-side workflows, while platform-specific iOS integrations handle capabilities that require native operating-system support.

Implementation

• Built authenticated account and profile flows with Firebase Authentication.
• Modeled social feeds, profiles, privacy controls, training records, and supporting product state in Cloud Firestore.
• Used Firebase Storage for user-generated photo and video media.
• Developed Check-In creation, media editing, friend discovery, engagement, reporting, and moderation workflows.
• Connected training features with exercise, nutrition, and health-oriented data surfaces.
• Integrated notifications, analytics, crash reporting, advertising, and subscription infrastructure around the core product.

Major challenges and solutions

Coordinating several sources of truth. Social state, media, health data, notification state, and platform capabilities do not all update at the same speed. I separated service responsibilities, preserved useful cached state during reloads, and made loading or failure states explicit.

Keeping private settings private. Public profile features need selected public fields without mirroring a user’s complete preference data. Public-facing models project only the data each surface needs.

Maintaining native iOS behavior. Health, notifications, purchases, and newer iOS interface behavior require careful boundaries between Flutter and native code. I kept these integrations behind focused services and runtime checks so unsupported paths retain dependable fallbacks.

Testing and validation

Development uses focused Flutter unit and widget tests, Firebase Functions tests, static analysis, native build checks, and targeted device/TestFlight validation where platform services cannot be represented accurately by a simple simulator-only test.

Regression work emphasizes the real ownership path for each feature—for example, separating a workout reminder from a social notification or verifying the public profile data actually stored in Firestore.

Current status

Flexin is an active, private development project. Core social Check-Ins, feeds, profiles, training features, health-oriented workflows, privacy controls, moderation, and supporting iOS infrastructure are implemented and continue to be refined.

No public-launch, usage, revenue, or performance claims are made here. A public product link will be added only when one is available.

Lessons learned

• Mobile polish depends as much on state ownership and failure behavior as it does on visual design.
• Cross-platform code still needs deliberate platform boundaries for native capabilities.
• Privacy is easier to protect when public data is modeled explicitly instead of filtered at the last moment.
• Focused tests around a real user path provide more confidence than broad checks that miss integration boundaries.