Case study · 2024 – Present
SmokeMukti.
ICMR-funded tobacco cessation app — personalized AI chat coach inside a care-pathway designed with public-health researchers.
1st
place at AIDEC
ICMR
research-funded
iOS + Android
live on stores
0
client-side API keys
The problem
Tobacco kills more people in India than any other behavioural cause. Cessation interventions exist — clinics, helplines, NRT — but adherence drops off a cliff in the first two weeks because the support loop is too thin. A user gets a pep-talk on Monday, a craving hits at 2am Tuesday, and there's no one on the other end. Meanwhile, generic cessation apps don't calibrate to the Indian smoker: triggers, social pressure, language, and product availability are different here, and a Western app designed for cigarettes doesn't map to the realities of bidi, gutka, or chewing tobacco.
SmokeMukti was built to fill that 2am gap with a research-backed care pathway: personalised goal setting, progress tracking, motivation prompts, and a 24/7 AI chat coach trained against a clinically approved system prompt. The product was funded by the Indian Council of Medical Research (ICMR) as a Short-Term Studentship project under Dr. Anil V. Ankola and the team at KLE V.K. Institute of Dental Sciences. It had to be good enough to ship to the App Store, defensible enough to publish in a research paper, and respectful enough that a cessation patient in Belagavi would actually trust it.
Constraints
- Apple App Review compliance is non-negotiable. The first submission was rejected on 5.1.1(v) (login required for non-account features) and 2.1(a) (AI chat connection error from client-embedded API key). Both failures had to be designed out, not patched.
- Patient data lives under medical-grade trust. ICMR-funded research carries a publication path; any data we collected for the psychometric study had to be consentful, de-identifiable, and auditable.
- Clinical voice matters. The AI coach can't hallucinate medical advice. The system prompt was iterated with the clinical team and constrained to a small surface area: motivation, education on craving cycles, and escalation to a human helpline when the conversation crossed into relapse-risk territory.
- Offline-tolerant on Indian network conditions. The user might check in from a 2G village or a 5G office. Progress tracking, goal logging, and motivation streaks had to work without a live connection and reconcile on reconnect.
Architecture
React Native + Expo on a hand-rolled boilerplate
SmokeMukti runs on React Native (Expo) with TypeScript and Redux Toolkit for state, layered on a boilerplate I had open-sourced earlier (react-native-smokemukti). The boilerplate gave us pre-wired navigation, theming, async storage, and CI — every architectural choice that doesn't differentiate a cessation app got committed to once and reused.
Server-side AI chat — no API key in the binary
The first version embedded the AI provider key in the app, the standard React Native mistake. Apple rejected it (correctly) on 2.1(a). The fix was to move every AI call behind a server endpoint:
- The app POSTs to
POST /ai-chaton our existing API atEXPO_PUBLIC_API_URL. - The server (Supabase Edge Function / Vercel-hosted backend) holds the Gemini key in environment, applies the clinical system prompt, calls Gemini, and returns
{ reply }. - Per-user request limits (3 / day on free tier) are enforced server-side. The mobile app never knows the provider, the key, or the limit logic.
That single move killed the App Review rejection and made the cost surface predictable.
Care-pathway state model
Behaviour-change apps live or die on their state model. SmokeMukti tracks four primary entities: the user, their quit goal (target date, taper plan, rationale), logs (cravings, cigarettes / equivalents consumed, mood, trigger), and achievements (streaks, money saved, health milestones). All four are stored locally in Redux + AsyncStorage, synced to the server in the background, and never block the UI on a network round-trip. A relapse doesn't lose data — it logs to the local store and reconciles when the user is online again.
Apple 5.1.1(v) — login as a feature, not a wall
The original UX gated everything behind login. The compliant version flips that: cessation tracking, the education library, and progress views work without an account. Login is offered when a user wants the AI coach, account-tied features (cross-device sync), or to participate in the research study. The in-app copy describes login as a feature, not a tax.
Research instrumentation
For the ICMR STS arm, we instrumented a consenting opt-in cohort with anonymised event logging. The psychometric study (Development, Psychometric Analysis and User Experience for a Novel Tobacco Cessation Application Among Tobacco Users in Belagavi, India: A Cross-Sectional Study) used those events to validate the care pathway. The research findings drive the next iteration of the system prompt — closing the loop between the lab and the chat coach.
What I built
- The full React Native app — care-pathway state model, goal-setting wizard, daily check-in, craving log, achievement system, education library, AI chat surface.
- The server-side AI chat endpoint with the clinically-reviewed system prompt, request accounting, rate limiting, and the migration off client-embedded keys.
- The Apple App Review remediation — 2.1(a) AI chat fix, 5.1.1(v) login-as-feature rewrite, App Tracking Transparency wiring.
- The Vercel-hosted landing page with achievements, certifications, gallery, and store download CTAs — the credibility surface that ICMR and Apple both look at.
- The open-source boilerplate the app rests on — committed once, reused for Oravira and beyond.
Trade-offs
- Gemini vs. Claude / GPT. Gemini was the chosen model for the chat coach because of cost per token at our usage scale and predictable safety filters for a clinical context. Claude or GPT would be stronger at nuanced motivational language; Gemini was good enough and the cost difference mattered for an unfunded freemium tier.
- Supabase Edge Functions vs. a custom backend. The Edge Function path got us off client-embedded keys in a weekend. A custom NestJS backend would have given us tighter observability and more flexible rate limiting. We took the speed and accepted the trade.
- Wide care-pathway vs. narrow craving-buster. A simpler product would have been a single "crave button" that fires off a coach message. The full care pathway (goals, logs, achievements, education) is a heavier surface — but the research outcomes wouldn't have been publishable without that breadth.
Outcome
SmokeMukti is live on both the App Store and Play Store with smokemukti.vercel.app as the credibility surface. The project earned 1st place at AIDEC and a 3rd-place award, plus a Short-Term Studentship grant from ICMR. The psychometric study under Dr. Anil V. Ankola validated the care-pathway design with consenting users in Belagavi.
SmokeMukti is also the platform Oravira is built on top of — the same boilerplate, the same care-pathway state model, the same server-side AI chat — re-targeted at the oral-health × HIV intersection. Architecting once and re-applying to a second clinical domain validated the approach better than any single deployment could.
Stack
Want help shipping something like this? Book a call, or grab the snippets this case study draws from.