project-43789e62

byrushikesh tayade

Build a mobile app: PulseSense AI — Business Requirements Document (BRD) Prepared By: Rushi (Creative Web Solution) Version: 1.0 Date: June 19, 2026 Companion Document: PulseSense_AI_PRD.md (feature/screen/technical detail) 1. Document Purpose This BRD defines the business case, scope, stakeholders, and success criteria for PulseSense AI. Where the PRD answers "what do we build and how does it work," this document answers "why are we building it, who is it for commercially, what does success look like, and what are the business risks." It is the reference for go/no-go, budgeting, and phased investment decisions. 2. Business Background Wearable adoption (Health Connect-compatible devices, Wear OS, Fitbit, Garmin) has outpaced the software layer that interprets that data for the average user. Category leaders (WHOOP, Oura) monetize via proprietary hardware + subscription; Apple Health and Google Fit are passive data stores with minimal coaching. There is a market gap for a hardware-agnostic, AI-coached wellness subscription that works with whatever device the user already owns — a model better suited to price-sensitive, device-fragmented markets like India, while still being globally viable. 3. Business Objectives # Objective Business Rationale BO-1 Launch a hardware-agnostic wellness app within [target launch window] Capture users who own a wearable but lack a coaching layer BO-2 Establish a 4-tier subscription model (Free/Pro/Premium/Family) plus Corporate plan Diversify revenue beyond a single price point BO-3 Reach sustainable unit economics (LTV > 3x CAC) within 2–3 quarters of launch Validate the business before scaling paid acquisition BO-4 Build a defensible data + AI moat via personalized baselines and burnout prediction Increase switching cost and justify premium pricing BO-5 Open a B2B revenue line via Corporate Wellness Larger contract values, lower CAC per user than D2C 4. Scope 4.1 In Scope (Phase 1–2, per PRD roadmap) Consumer Android app: onboarding, Health Connect sync, Dashboard, Stress/Recovery/Body Battery/HRV/Sleep engines, AI Health Coach, Workout tracking, Mood, Habits, Gamification, Notifications, Reports Free, Pro, and Premium subscription tiers via Google Play Billing Core security/privacy compliance (consent-based Health Connect access, encryption, biometric login) 4.2 In Scope (Phase 3–4, conditional on Phase 1–2 traction) Wear OS companion app Community/social/viral sharing features Family Plan and Family Dashboard AI Credit packs, one-time report sales, affiliate revenue Corporate Wellness Plan + Admin Web Dashboard (treated as a distinct B2B initiative — see §9) 4.3 Out of Scope (this phase) iOS application Direct (non-Health Connect) Garmin/Fitbit proprietary API partnerships — pending partner approval Medical-grade diagnostic claims or regulatory clearance (app is positioned as wellness insight, not a diagnostic medical device) Insurance-integration or clinical-provider data sharing 5. Stakeholders Stakeholder Interest Product Owner / Founder Overall vision, monetization strategy, go-to-market Development (Rushi / Creative Web Solution) Build, architecture, delivery timeline End Users (Free/Pro/Premium/Family) Reliable insights, fair pricing, data privacy Corporate Wellness Buyers (Phase 4) Team-level analytics, HR reporting, ROI on employee wellness spend Affiliate/Device Partners (Phase 4) Referral traffic, commission revenue App Store (Google Play) Policy compliance (health claims, billing, data safety) 6. Business Requirements ID Requirement Priority BR-1 The system shall offer a free tier sufficient to demonstrate core value (stress/sleep tracking) to drive top-of-funnel adoption Must BR-2 The system shall gate advanced features (unlimited history, Body Battery, advanced AI coaching) behind paid tiers Must BR-3 The system shall support recurring subscription billing via Google Play Billing with upgrade/downgrade/cancellation flows Must BR-4 The system shall track and report business KPIs (MRR, ARR, churn, LTV, CAC) via an admin dashboard Should (Phase 4) BR-5 The system shall support a referral mechanism that grants temporary Pro access to incentivize organic growth Should BR-6 The system shall support metered AI usage (daily caps for Free, unlimited for Pro+, purchasable credit packs) to control AI API cost exposure while monetizing heavy users Must BR-7 The system shall comply with data privacy requirements for health data (explicit consent per data type, encryption in transit/at rest) Must BR-8 The system shall support a B2B Corporate Wellness offering with per-seat billing, independent of the consumer subscription model Could (Phase 4) BR-9 The system shall enable affiliate revenue tracking (device/product recommendations with click and conversion attribution) Could (Phase 4) BR-10 The business shall be able to run free-tier monetization via ads (AdMob/AppLovin) without degrading the paid-tier experience (ads excluded for Pro+) Should (Priority key: Must = launch-blocking, Should = near-term post-launch, Could = opportunistic/Phase 4) 7. Revenue Model Summary Stream Description Phase Subscriptions Pro $7.99/mo, Premium $14.99/mo, Family $24.99/mo 1–3 AI Credits Pay-as-you-go packs for heavy AI users on Free/Pro 4 One-time Reports Single-purchase deep reports ($4.99–$9.99) 4 Ads Free-tier only, rewarded ads unlock temporary perks 2 Affiliate Commission on recommended devices/products 4 Corporate Per-seat B2B contracts 4 Key cost driver to monitor: AI API spend (Gemini/OpenAI) scales with engagement — BR-6's metering is the primary lever to keep gross margin healthy as usage grows. 8. Success Criteria Criterion Target Tied to Objective Health Connect sync completion in onboarding >70% BO-1 Free → Paid conversion >4% BO-2, BO-3 D30 retention >25% BO-1, BO-4 LTV : CAC ratio >3:1 BO-3 Time to first Corporate pilot signed Within 2 quarters of Phase 4 start BO-5 9. Relationship to Corporate Wellness / B2B Track Corporate Wellness and the Admin Web Dashboard represent a second business model (B2B SaaS, per-seat billing, HR buyer persona) layered on top of the consumer product. Recommendation: treat this as its own mini business case once the consumer app (BR-1 through BR-3, BR-6, BR-7) has proven retention and conversion — avoid building B2B infrastructure before the core consumer engine is validated. 10. Assumptions & Constraints Assumption: Users already own a Health Connect–compatible wearable or phone sensor; the app does not bundle hardware. Assumption: Gemini/OpenAI API pricing remains commercially viable at the proposed credit-pack price points; this should be re-validated against current API pricing before final pricing lock. Constraint: Single developer/freelance delivery model (Creative Web Solution) — phased roadmap (see PRD §7) is the primary mechanism for managing scope against delivery capacity. Constraint: Android-only at launch; iOS is explicitly out of scope and would require a separate business case. Constraint: No medical/diagnostic claims — all health framing must stay in "wellness insight" language to avoid regulatory/Play Store policy risk. 11. Business Risks Risk Impact Mitigation AI API cost outpaces subscription revenue at scale Margin erosion Hard metering (BR-6), credit packs to monetize heavy usage directly Health-claim language triggers Play Store policy rejection Launch delay Legal/compliance review of all "score," "prediction," and "alert" copy before submission Low Free→Paid conversion due to feature-rich free tier Revenue shortfall A/B test free-tier feature gating post-launch; do not over-deliver value for free Wearable data inconsistency across device brands (via Health Connect) Inaccurate scores, trust erosion Phase 1 QA explicitly across multiple device data sources, not just one reference device Single-developer delivery bottleneck across this large scope Timeline slippage Strict adherence to phased roadmap; resist scope creep into Phase 3/4 features pre-launch 12. Sign-Off Role Name Date Approval Product Owner ☐ Approved Development Lead Rushi ☐ Approved End of BRD. Use alongside PulseSense_AI_PRD.md — this document governs scope/priority decisions; the PRD governs implementation detail.