← RANJITH RAJSHEKAR · PORTFOLIO NEXT: VANTAGEBET →
02CONSUMER MOBILE PRODUCT / WELLNESS·2026 to PRESENT

Sahaja.
A yoga practice that plans itself.

A self-guided yoga practice companion for people who want consistency without planning every session, designed and built solo, end to end, from first flow to a live backend.

ROLE
Independent Product Designer & Builder
PLATFORM
React Native · iOS & Android
STATUS
MVP on a live backend, native-device testing
SCALE
34 React Native screens shipped
LOADING PROTOTYPE OPEN FULL SIZE →
01 · CONTEXT

People don't quit yoga. They quit planning yoga.

Most yoga apps assume the user arrives knowing what to practise. In reality, the decision, which sequence, how long, how hard, is this safe for my back, is exactly where home practice collapses. Class-goers have a teacher who removes that decision; solo practitioners face it every single day.

Sahaja is built for that person: someone who wants a consistent home practice but doesn't want to be their own teacher, planner and safety-checker. The app carries the plan; the user just shows up.

This is also personal domain knowledge, not a borrowed brief, my own yoga practice informs how sessions are paced, how guidance is worded, and how habit loops are structured. Teaching flow, pacing and safety rules come from the mat, not from competitor screenshots.

02 · PRODUCT CHALLENGE

Remove every decision between intention and mat.

USER FRICTION
  • Choosing a session every day is a chore that kills streaks
  • Generic video classes ignore energy level, injuries and time available
  • No feedback loop, practising alone, you never know if you're progressing
BUILD CONSTRAINT
  • 1 person designs, builds and QAs everything, scope must earn its place
  • Guidance must work hands-free: audio-first, glanceable visuals
  • Safety content (contraindications, modifications) has to be structural, not a disclaimer
SUCCESS =

A user opens the app, and within 2 taps is practising a session that fits their day, then comes back tomorrow because the app remembered what today felt like.

03 · PROCESS

Design the loop first, the screens second.

The core design object in Sahaja isn't a screen, it's a daily loop. Everything in the IA hangs off it: check in, practise, reflect, see progress. Screens were only added when they served a step of the loop; that discipline is how the app stays at 34 screens instead of 80.

1
Check in
energy, time, body
2
Practise
guided player, hands-free
3
Reflect
1-line journal, mood
4
Progress
journeys, not streak guilt
RESEARCH

Interviews and first-hand teaching observation shaped the core insight: dropout happens at the planning step, not the practising step. Safety needs (injuries, pregnancy, blood pressure) surfaced early and became a structural onboarding step, the safety profile, rather than a settings afterthought.

IA

5 tabs: Today (the loop's home), Practice (library), Learn (pose atlas, breath school, philosophy, safety hub, glossary), Journey (progress), You (profile). "Today" is deliberately first and default, the app opens on a decision already made.

KEY DECISIONS

Journeys over streaks, progress is framed as a path you're walking, not a chain you can break. A 1-line reflection after each session instead of a full journal, because tired people don't type paragraphs. And guidance is audio-first with large glanceable pose figures, because a phone on the floor is read from a downward dog, not from arm's length.

SCOPE HELD BACK

A live-teacher marketplace and teacher tools were fully designed in the prototype (discovery, booking, payouts, moderation) but consciously kept out of the MVP build, validating the solo practice loop comes first.

04 · DESIGN SYSTEM

Calm by construction.

The visual language borrows from print more than from fitness apps: a warm paper background, a deep sea-green as 1 brand colour, serif display type for moments of pause, and a consistent monoline figure system for every pose illustration, 1 visual voice across all 34 screens.

SEA GREEN · PAPER · INK · SAND
Cormorant Garamond
+ a grotesk for UI text
SERIF FOR PAUSE, SANS FOR ACTION
MONOLINE POSE FIGURES · 1 SYSTEM, EVERY ASANA

Native considerations are baked in rather than bolted on: a full dark theme, an accessibility screen (text size, reduced motion, voice guidance controls), 44px+ touch targets throughout, and a tab bar that hides during practice so the player owns the whole screen.

05 · KEY FLOWS

Try them in the live prototype above.

Every flow below is clickable in the embedded prototype, the same design that became the React Native build.

Onboarding & safety profile

SPLASH → GOALS → SETUP → SAFETY → READY

Problem: generic apps ask for goals; nobody asks what your body can't do. Decision: a dedicated safety step (injuries, conditions) that filters every future session. Outcome: recommendations users can trust without reading pose warnings.

Daily check-in → guided practice

TODAY → SESSION → PLAYER → COMPLETE

Problem: the daily "what should I practise" decision. Decision: Today opens with 1 recommended session based on your check-in, practise in 2 taps, swap only if you want. Outcome: the planning step disappears; the player runs pose-by-pose with timing, cues and hands-free pacing.

Reflection & journeys

COMPLETE → REFLECT → JOURNEY → HISTORY

Problem: streak counters punish real life. Decision: progress lives in journeys, themed paths that advance whenever you practise, plus a 1-line reflection that builds a private log. Outcome: missing a day costs nothing; returning always advances something.

Learn: atlas, breath school, safety hub

LEARN → ATLAS → POSE DETAIL

Problem: pose knowledge scattered across YouTube. Decision: a reference layer, pose atlas, breath school, philosophy, glossary and a safety hub, separated from the practice loop so it never interrupts it. Outcome: depth for the curious without adding 1 step to the daily loop.

06 · BUILD & DELIVERY

Designed in Figma. Shipped in React Native. Same person.

Sahaja is my clearest evidence that the design doesn't stop at handoff, because there is no handoff. 34 React Native screens are shipped against a live backend, running in native-device testing on real phones. Design-to-code moves through an AI-assisted workflow: Figma MCP and Claude Code for iteration, GitHub for version control, with QA passes on device before anything is called done.

34 screens
shipped in React Native, iOS & Android
Live backend
real accounts, sessions and progress data
On-device QA
native-device testing, not just simulators
Solo, end to end
research → design → build → QA → release
PROTOTYPE · POSTURE GUIDANCE

I'm prototyping camera-based posture guidance using Google MediaPipe pose tracking: on-device body landmarks, visual feedback against the target pose, and voice-guided cues, so the app can gently correct alignment the way a teacher would. This is an active prototype, not yet part of the shipped MVP; it graduates when it's accurate enough to be safe.

07 · CURRENT STATUS

In beta, honestly.

Sahaja is an MVP in validation, no vanity metrics to report yet, and none invented. The current cycle is native-device testing of the practice loop: does the check-in → practise → reflect rhythm actually hold up over weeks of real use?

LEARNEDDesigning the loop before the screens kept a solo build at MVP scale, the marketplace stayed in the drawer because the loop didn't need it.
LEARNEDBuilding my own designs changed how I design, every component now gets specified with its states and edge cases, because I'm the one who has to code them.
NEXTClose the beta loop with real practitioners, then decide whether posture guidance is ready to graduate from prototype to product.
NEXT · 03
VantageBet

An independent mobile iGaming concept spanning casino discovery, sports betting, wallet, account, and responsible-play journeys.

NEXT

Have a product problem worth solving?

Let's make the next decision clearer.