Oravira.

The problem

People living with HIV face a higher burden of oral-health complications — opportunistic infections, periodontal disease, mucosal lesions — that are clinically detectable, treatable, and frequently missed. Two systemic gaps make this worse: dental clinics are not always set up to handle HIV-positive patients with the right protocols, and patients themselves rarely have a structured way to track oral symptoms between visits. The information loop between symptom and care is broken on both sides.

Oravira was built to be the patient-facing tool that closes that loop. Daily symptom check-ins, education on oral-health-in-HIV-care, treatment-adherence reminders, and a referral pathway into clinics that have opted into the network. The product had to feel medical-grade trustworthy, work on the same flaky network conditions as SmokeMukti, and respect the heightened privacy bar that HIV-related health data carries.

Constraints

• HIV-related data is privacy-critical. Even more than tobacco-cessation data, HIV-care data leaking would be devastating to users. The architecture had to default to local-first storage with minimal server-side identifiable retention.
• The SmokeMukti boilerplate had to fit. Reusing the foundation was a stated goal — the win was proving the care-pathway pattern generalised. The cost was disciplined enough customisation that oral-health specifics didn't bend the shared base.
• Clinical content has to be accurate and reviewed. Every piece of education, every symptom-check question, every referral nudge had to pass through clinical review before shipping.
• Both stores accept it on first submission. The Apple lessons from SmokeMukti — server-side API keys, login-as-feature, ATT compliance — had to be applied from day one, not learned again the hard way.

Architecture

Built on the SmokeMukti boilerplate

Oravira's codebase shares ancestry with the open-source react-native-smokemukti boilerplate. The navigation layer, theming, async storage, error reporting, and CI/CD pipeline are the same. Stack: Expo SDK 54, React Native, TypeScript, Redux Toolkit, React Navigation 6, iOS build via Expo EAS. The shared base meant Oravira's scaffolding took days, not weeks.

Clinical-content layer over the same care-pathway state model

The state model from SmokeMukti — user, goal, logs, achievements — re-applied cleanly. What changed underneath:

• Logs are oral-symptom check-ins (lesions, pain, bleeding, dryness) on a daily cadence, not craving + consumption events.
• Goals are adherence targets (clinic visits, hygiene routine, medication) rather than a quit-date plan.
• Achievements reward consistent self-tracking and clinic adherence — not abstinence milestones.
• Education library is a curated stack of clinically-reviewed articles on oral-health complications in HIV care, written for patient literacy levels rather than clinical staff.

This is what generalised the SmokeMukti pattern: same shape, different content. The boilerplate is the platform, the clinical content is the variant.

Privacy-first data model

Oravira treats local storage as the source of truth. Logs, goals, and education progress live in AsyncStorage on-device. Server-side, we store only the minimum needed for clinic referral hand-offs and consent-based research signals. The AI chat surface — when used — runs through the same server-side endpoint pattern as SmokeMukti, so no provider key ever lives in the binary.

Apple compliance from day one

Lessons from SmokeMukti's rejection cycle baked in:

• AI chat behind a server endpoint, never client-embedded keys (App Review 2.1(a) compliance from day one).
• Login is a feature available where it adds value (sync, AI chat, research opt-in) — not a wall in front of cessation logging or education access (5.1.1(v) compliance from day one).
• App Tracking Transparency wired up correctly with no tracking by default.

What I built

• The full Oravira app on top of the SmokeMukti boilerplate — navigation, theming, the oral-symptom check-in flow, the goal / log / achievement system retargeted to oral health, the education library, the AI chat surface (server-mediated).
• The EAS build pipeline for iOS and Android, App Store and Play Store submission flows, provisioning + signing infra, and store-side metadata that holds up to clinical review.
• The privacy hardening — local-first storage, minimal server retention, consent-gated research opt-in, App Tracking Transparency.
• The clinical content integration — building the editor pipeline for the oral-health education library so clinical reviewers could update content without engineering involvement.
• The generalisation work — extracting the care-pathway primitives from SmokeMukti so future health-tech products in this family don't have to rebuild the foundation again.

Trade-offs

• Inheriting vs. forking the boilerplate. We inherited it as a base rather than forking and diverging. The cost was occasional friction when oral-health needs (e.g. structured symptom-severity inputs) didn't fit the cessation-shaped scaffolding. The win was that improvements made for Oravira (App Store compliance fixes, EAS hardening, ATT wiring) flowed back to SmokeMukti and the shared base.
• One AI chat surface vs. specialised triage. An ideal Oravira would have a triage assistant that escalates symptoms with red-flag patterns (e.g. severe oral lesions) directly into a clinic-referral pipeline. We shipped a more conservative chat surface first and kept clinical escalation as a human-mediated step. We'll iterate based on the next research arm's findings.
• Same UI language as SmokeMukti vs. distinct visual identity. Oravira intentionally shares enough visual DNA with SmokeMukti that users recognise the family — the same checklist ergonomics, the same achievement language. The cost is some loss of category-specific identity. The win is engineering velocity and a recognisable trust pattern across both apps.

Outcome

Oravira is live on both the App Store and Play Store. First submissions cleared App Review on the first try thanks to the SmokeMukti lessons baked into the starting point. The product is positioned for clinic partnerships and a research arm validating the oral-health-in-HIV-care intervention.

The deeper outcome is that SmokeMukti + Oravira together prove the care-pathway pattern generalises across clinical domains. The same architecture — local-first state, server-mediated AI, achievement-led adherence, education library, clinical reviewer pipeline — works for cessation work and for adherence work alike. That's the platform we now have to deploy against the next clinical problem space.