Structured priority for a 4-week delivery. Must Haves form the foundation and core tracking loop. Should Haves add retention. Could Haves deliver operational tooling. Won't Haves are explicitly deferred to v2.
MUST HAVE -- Phase 1-2, Weeks 1-2
Phone auth + OTP verification via BDApps + multi-profile accounts
BDApps otp/request + otp/verify flow. Relation types: self, wife, sister, mother, daughter, girlfriend
Bilingual UI (English + Bengali)
i18n from day one with i18next + react-i18next
Period tracking
Start/end, flow intensity (light/medium/heavy), retroactive editing
Cycle dashboard
Cycle day hero, phase label (follicular/ovulatory/luteal/menstrual), countdown
Monthly calendar
Color-coded: period pink, fertile teal, ovulation accent
Symptom logging
30+ symptoms, icon-based tap selection, 4 categories (physical, mood, discharge, lifestyle)
Three-tier prediction engine
Simple avg (Tier 1) -> ARIMA (Tier 2) -> LSTM stub (Tier 3)
Onboarding flow
Trust screens, goal selection (period/TTC/peri), cycle history entry
Field-level encryption
AES-256-GCM via prisma-field-encryption for health data
Profile switcher with data isolation
checkProfileOwnership middleware on every profile-scoped endpoint
Feature gating middleware (free/pro access control)
Backend middleware checks subscription tier before granting access to gated features
Redis-backed session store with JWT blacklist
Tracks active sessions per user, enables remote session termination
BDApps CAAS charging for Pro subscription
caas/directDebit for Pro charging, caas/queryBalance for status checks
Auto-disable Pro on charging lapse + grace period
Daily cron checks CAAS status, disables Pro after configurable grace period with user warning
SHOULD HAVE -- Phase 3, Week 3
Email notifications
Period alerts, fertile window, logging reminders via Resend + React Email
Content platform
Bilingual blog articles, phase-specific recommendations, cultural context
Notification preferences per-profile
Toggle each notification type on/off per health profile
COULD HAVE -- Phase 4, Weeks 3-4
Admin dashboard
User metrics, activity charts, daily new users, MAU trends
User management
List, suspend, reactivate, delete, reset password
Content CMS
Tiptap rich text editor, bilingual articles, category management
Population health analytics
Aggregated, privacy-protected cycle insights
Prediction accuracy reports
Predicted vs. actual dates, accuracy percentages per tier
Data export (CSV/Excel)
Analytics and research data export for operations team
Role-based access control
Super Admin and Content Admin roles with requireRole middleware
Admin feature gating toggle UI
Configure which features are free vs pro from admin portal
Admin session management (view/terminate sessions)
View active sessions for any user, terminate individual or all sessions
Admin subscription management (BDApps status, manual override, billing history)
View subscription status, set grace period, manual pro grant/revoke
WON'T HAVE -- v1
Pregnancy mode
Week-by-week tracker, ultrasound storage -- deferred to v2
Medicine tracker, sleep monitor, exercise tracking
Extended health modules require stable core first
Anonymous community forum
High moderation overhead -- requires infrastructure not in v1 scope
AI health chatbot
Enormous medical liability without expert advisory board
Native mobile apps
Web-first validates PMF; PWA covers 80% of native UX
Doctor consultations / marketplace
Phase 2 monetization features
2
Feature Prioritisation -- RICE Scores
RICE = (Reach x Impact x Confidence) / Effort. Scored against the 4-week delivery window. Higher scores ship earlier.
| Feature |
Reach |
Impact |
Confidence |
Effort (days) |
RICE |
Phase |
| Prediction engine (Tier 1) |
100% |
3 (massive) |
90% |
1 |
270 |
Phase 2 |
| Auth + OTP (BDApps) + onboarding |
100% |
3 (massive) |
90% |
2.5 |
108 |
Phase 1 |
| Bilingual UI (EN+BN) |
100% |
2.5 (high) |
85% |
2 |
106 |
Phase 1 |
| Period tracking + calendar |
100% |
3 (massive) |
95% |
3 |
95 |
Phase 2 |
| Multi-profile accounts |
100% |
3 (massive) |
90% |
3 |
90 |
Phase 1 |
| Symptom logging |
80% |
2 (high) |
85% |
2.5 |
54 |
Phase 2 |
| BDApps OTP verification |
100% |
3 (massive) |
90% |
1 |
270 |
Phase 1 |
| BDApps CAAS charging |
100% |
3 (massive) |
90% |
1.5 |
180 |
Phase 1 |
| Content platform |
70% |
2 (high) |
80% |
2.5 |
45 |
Phase 3 |
| Prediction (ARIMA Tier 2) |
30% |
2 (high) |
60% |
2 |
18 |
Phase 2 |
| Admin panel |
10% |
2 (high) |
90% |
8 |
2 |
Phase 4 |
| Prediction (LSTM Tier 3) |
10% |
2.5 (high) |
40% |
5 |
2 |
Phase 2 (stub) |
| Feature gating |
100% |
2.5 (high) |
85% |
2 |
106 |
Phase 1 |
| Session management |
20% |
2 (high) |
90% |
1.5 |
24 |
Phase 4 |
Modern, stable, and well-matched to the domain. Stability over bleeding edge for a health platform. Prisma 6 pinned for encryption compatibility. Vite 6 LTS over Vite 8.
Frontend
React 19 + TypeScript
Ecosystem dominance. React 19 stable with use() hook and Actions. SPA on Vercel CDN.
Styling
Tailwind CSS v4
CSS-first config, OKLCH colors, 5x faster builds. @theme directive for design tokens.
Build Tool
Vite 6 LTS
Stable line for 2026. v8 (Rolldown) too new for production health app. Security patches on 6.4.x.
State Management
TanStack Query + Zustand
TQ for server state with profile-scoped query keys. Zustand (1KB) for active profile, locale, UI.
Backend
Express 5 + TypeScript
Promise-based error handling, path-to-regexp v8 (ReDoS-safe). Persistent process on Railway.
ORM + Database
Prisma 6.13 + PostgreSQL 16
Pinned for prisma-field-encryption compatibility. pgcrypto + RLS for profile isolation.
Auth
JWT + BDApps OTP
Phone number sign-up verified via BDApps otp/request + otp/verify. Access tokens (15min) + refresh tokens (7d) in HttpOnly Secure cookies. Role claims for admin RBAC.
i18n
i18next + react-i18next
Bengali locale fully supported. JSON namespaces, interpolation, date-fns bn locale.
Encryption
prisma-field-encryption
Transparent AES-256-GCM for sensitive health fields. /// @encrypted in Prisma schema.
Email
Resend + React Email
Clean DX, 3,000/month free tier. React Email for type-safe templates.
Charts
Recharts 3.x
React-first SVG components. Cycle trends, admin analytics, symptom correlation.
Calendar / Dates
date-fns
Tree-shakeable, immutable. Bengali locale (bn) for date formatting. Cycle math backbone.
CMS Editor
Tiptap 3.x
Rich text editor for bilingual content articles. Collaborative editing support for admin CMS.
Session Store
Redis + ioredis
JWT blacklist for remote session termination, BullMQ backing store.
Carrier Billing
BDApps CAAS API
caas/directDebit for Pro charging, caas/queryBalance for subscription status. Dominant payment method in Bangladesh.
Hosting
Vercel + Supabase
Frontend + serverless API on Vercel. PostgreSQL + RLS on Supabase. Upstash Redis for sessions. Zero-cost experimental tier with clear upgrade path.
Job Queue
Vercel Cron + Upstash QStash
Replaces BullMQ workers. Vercel Cron for scheduled reminders + CAAS checks. QStash for reliable async jobs. Both serverless-native, no persistent process needed.
4
Three-Tier Prediction Engine
The prediction engine automatically upgrades itself as users log more data. No user action needed — the system detects when enough data is available and switches to a smarter algorithm. The biggest accuracy jump happens between Tier 1 and Tier 2.
1
Simple Average
AVAILABLE FROM DAY 1
Calculates the average length of the user's last 3–6 cycles. For brand-new users, it uses the cycle length entered during onboarding as a starting point.
Predicts: Next period start, ovulation day, fertile window
Accuracy: ~70–75% for regular cycles
Data needed: 0 cycles (uses onboarding input)
2
Statistical Model (ARIMA)
UNLOCKS AT 6 LOGGED CYCLES
A time-series algorithm that detects patterns and trends in cycle history — such as cycles gradually getting shorter or longer. Adapts to each user's unique rhythm.
Predicts: All Tier 1 outputs + trend-adjusted dates
Accuracy: ~80–87% (biggest jump from Tier 1)
Data needed: 6+ logged cycles (~6 months)
3
AI / Neural Network (LSTM)
UNLOCKS AT 12 LOGGED CYCLES
A deep learning model that considers multiple factors — cycle history, logged symptoms, lifestyle data, and age — to make highly personalized predictions. Learns from population-level patterns.
Predicts: All Tier 2 outputs + symptom-adjusted forecasts
Accuracy: ~85–91% (incremental gain over Tier 2)
Data needed: 12+ logged cycles (~12 months)
How Auto-Escalation Works
USER SIGNS UP
Tier 1
Simple Average
0 cycles
6 CYCLES LOGGED
Tier 2
Statistical (ARIMA)
6+ cycles
12 CYCLES LOGGED
Tier 3
AI / Neural Network
12+ cycles
The upgrade happens automatically — users see a confidence percentage that improves over time.
No manual action required. The more data logged, the smarter the predictions become.
What the Engine Predicts
🔸
Next Period
Start & end date
💚
Fertile Window
5-day high-chance range
⚪
Ovulation Day
Peak fertility date
📈
Confidence %
How sure the engine is
⚠️
Estimation Note for Client
Tier 1 is included in the base estimate. Tier 2 (ARIMA) adds ~10 development hours. Tier 3 (Neural Network) adds ~20 hours for the initial stub, with full model training requiring additional effort once production data accumulates (~12 months post-launch). Tier 3 can be deferred without impacting launch.
20 working days across 4 phases. Each week produces a coherent, verifiable capability. Phase dependencies flow strictly forward -- no circular dependencies.
| Day | Focus | Deliverables | Owner |
|---|
Day 1 Monday |
Monorepo setup + Prisma schema |
pnpm workspace + Turborepo: web, api, shared packages Prisma schema: users, profiles, period_logs, symptom_logs, predictions prisma-field-encryption configured + integration test Supabase project provisioned (PostgreSQL + RLS enabled), Upstash Redis connected Vercel project linked, preview + production environments configured Shared Zod schemas + TypeScript types scaffolded |
Back-end |
Day 2 Tuesday |
Auth API + BDApps OTP + security middleware |
Express 5 server with helmet, cors, rate-limit, cookie-parser Phone-number signup + BDApps otp/request → otp/verify flow JWT auth: login, password reset Access + refresh tokens in HttpOnly Secure cookies verifyJWT + checkProfileOwnership middleware chain Feature gating middleware (free/pro access control) Redis-backed session store with JWT blacklist (ioredis) BDApps CAAS wrapper: caas/directDebit + caas/queryBalance |
Back-end |
Day 3 Wednesday |
i18n infrastructure + privacy pages |
i18next initialized with EN/BN namespaces, Noto Sans Bengali loaded React shell: App providers, router, layout with language switcher Privacy policy + Terms of Service in both languages Vercel deploy pipeline + Railway API deploy configured |
Front-end |
Day 4 Thursday |
Multi-profile CRUD + profile switcher |
Profile CRUD API: create, read, update, delete with ownership checks Relation types: self, wife, sister, mother, daughter, girlfriend Profile switcher UI component (always accessible in header) TanStack Query hooks with profile-scoped query keys Tier 1 prediction: initial calculation on profile creation |
Both |
Day 5 Friday |
Onboarding wizard + dashboard shell |
Trust/privacy screens with bilingual content Goal selection: track period, try to conceive, perimenopause Cycle history entry: last period, cycle length, period duration First prediction generated on onboarding complete Dashboard shell + account deletion flow |
Front-end |
| Day | Focus | Deliverables | Owner |
|---|
Day 6 Monday |
Shared contracts + Prisma additions |
Zod schemas for cycle, symptom, prediction DTOs Phase calculation utilities (follicular, ovulatory, luteal, menstrual) Constants: symptom categories, flow levels, phase definitions |
Both |
Day 7 Tuesday |
Prediction engine (all 3 tiers) |
Strategy Pattern: IPredictionEngine interface Tier 1: rolling average (already working from Day 4) Tier 2: ARIMA wrapper using `arima` npm package Tier 3: LSTM stub (delegates to Tier 2 until trained) Factory: getPredictionEngine(dataPoints) auto-escalation |
Back-end |
Day 8 Wednesday |
Cycle API + BullMQ recalc |
Period start/end logging API with flow intensity Retroactive period editing with validation BullMQ: prediction recalculation job on every period log Predictions update immediately on new data |
Back-end |
Day 9 Thursday |
Symptom logging |
Symptom CRUD API with category/key validation Icon-based tap selection UI (30+ symptoms, 4 categories) Physical: cramps, headache, breast tenderness, bloating, back pain, fatigue, nausea, acne Mood: calm, sad, happy, anxious, mood swings, irritable, energetic, depressed Discharge + lifestyle categories, same-day edit support |
Both |
Day 10 Friday |
Dashboard + Calendar UI |
Cycle day hero (largest UI element), phase label, countdown Fertile window display, TTC tips, prediction confidence Period logger: 2-3 tap flow intensity + date picker Monthly calendar: color-coded grid (pink=period, teal=fertile, accent=ovulation) Day detail panel: tap any date to view/edit logged data Month navigation, predicted vs logged distinction |
Front-end |
| Day | Focus | Deliverables | Owner |
|---|
Day 11 Monday |
Notification infrastructure |
Prisma schema additions: notification_preferences, notification_logs BullMQ queues: send-email, daily-reminder Notification preferences API (per-profile toggles) Notification settings UI page |
Both |
Day 12 Tuesday |
Email delivery |
Resend + React Email templates: period alert, fertile window, logging reminder Cron job processors: daily check for upcoming predictions Multi-profile routing: correct profile gets correct notification |
Back-end |
Day 13 Wednesday |
Content platform |
Article service: bilingual content with phase-based filtering Content browsing pages: article list, article detail, category filter Dashboard content feed: phase-specific recommendations Bilingual seed data: 10-15 articles on menstrual health and Bangladeshi cultural context |
Both |
Day 14 Thursday |
CAAS subscription lifecycle |
Pro upgrade flow: caas/directDebit triggered on plan selection caas/queryBalance daily cron: check subscription status per user Grace period logic: configurable N-day window before Pro disable Grace expiry email warning: "Your subscription expires in X days" Feature gating enforcement: Pro features locked on lapse |
Back-end |
Day 15 Friday |
Subscription UI + Week 3 QA |
Upgrade to Pro page: plan comparison, CAAS charge trigger Subscription status badge in user settings Grace period warning banner in app End-to-end QA: OTP flow, charging, grace period, feature gating |
Both |
| Day | Focus | Deliverables | Owner |
|---|
Day 16 Monday |
Admin RBAC + layout |
Role constants, requireRole middleware, RequireRole guard Admin layout shell: sidebar navigation, role-gated lazy-loading Dashboard metrics API: total users, active users, profiles created |
Both |
Day 17 Tuesday |
Dashboard UI + user management |
KPI cards: total users, MAU, profiles, tracking activity Trend charts: daily new users, monthly active users (Recharts) User management: list, view details, suspend, reactivate, delete, reset password |
Front-end |
Day 18 Wednesday |
Health analytics + prediction reports |
Population-level insights: avg cycle length, irregular cycle %, common symptoms Prediction accuracy: predicted vs actual dates, per-tier accuracy Privacy-protected aggregate queries (no individual health data exposed) |
Back-end |
Day 19 Thursday |
Content CMS + gating/session/subscription admin |
Tiptap rich text editor for bilingual article CRUD Category management + cycle phase tagging Notification management: control reminder types, broadcast Admin feature gating toggle UI (configure free vs pro features) Admin session management (view active sessions, terminate per user) Admin subscription management (BDApps status, grace period, manual override, billing history) |
Front-end |
Day 20 Friday |
Reports + data export + ship |
Feature usage report, alert engagement, multi-profile analytics, data completeness CSV/Excel data export for all reports Cross-browser QA + responsive check (375px, 768px, 1280px) Production deploy: Vercel (frontend) + Railway (API + worker) |
Both |
Sequential dependencies between phases and key blockers. Build foundation before features -- multi-profile auth and i18n affect every subsequent component.
Prisma schema + encryption
-> blocks ->
Auth API + all endpoints
Day 1 must complete first
Auth + JWT middleware
-> blocks ->
Multi-profile CRUD
Profile creation requires authenticated user
i18n infrastructure
-> blocks ->
All UI components
Bengali strings must exist before any UI is built
Multi-profile + ownership middleware
-> blocks ->
Period tracking, symptoms, predictions
All health data scoped to profiles
Onboarding writes cycle data
-> blocks ->
First prediction calculation
Needs avg_cycle_length in profiles table
Prediction engine API
-> blocks ->
Dashboard + calendar UI
Dashboard is empty without prediction data
Period log triggers recalculation
-> blocks ->
Calendar color-coding
Calendar reads from period_logs + predictions
BullMQ worker process
-> blocks ->
SMS + email notifications
Phase 3 requires job queue from Phase 2
Core tracking (Phase 2)
-> blocks ->
Content platform
Phase-specific content recommendations need cycle state
All user-facing features (Phases 1-3)
-> blocks ->
Admin analytics + reports
Admin monitors features that must exist first
4 phases, each producing a coherent, verifiable capability. Phase dependencies flow strictly forward: 1 -> 2 -> 3 -> 4.
Monorepo setup (pnpm + Turborepo)
Prisma schema + field encryption
JWT auth (signup, login, verify, reset)
Multi-profile CRUD + ownership middleware
Bilingual i18n (EN + BN from day one)
Onboarding wizard + first prediction
Profile switcher + account deletion
Privacy policy + ToS (bilingual)
Feature gating middleware (free/pro)
Redis session store with JWT blacklist
Goal: User creates account, manages profiles in English/Bengali
Period tracking (start/end, flow, retroactive editing)
Three-tier prediction engine (Strategy Pattern)
Cycle dashboard (day hero, phase, countdown)
Monthly calendar (color-coded, month nav)
Symptom logging (30+ symptoms, icon-based)
Fertile window + ovulation display
BullMQ prediction recalculation
Prediction confidence shown to user
Goal: User logs period and sees accurate prediction
Email notifications (Resend + React Email)
Period, fertile, logging reminder alerts
Notification preferences per-profile
Content platform (bilingual articles)
Phase-specific content recommendations
CAAS Pro upgrade flow + subscription lifecycle
Grace period cron + expiry warnings
Subscription UI (upgrade page, status badge)
Goal: User stays engaged through email alerts, content, and can upgrade to Pro via BDApps CAAS
RBAC: Super Admin + Content Admin roles
Admin dashboard (KPIs, trend charts)
User management (list, suspend, delete)
Population health analytics
Prediction accuracy reports
Content CMS (Tiptap editor, bilingual)
Operational reports + data export
CSV/Excel export for all analytics
Goal: Ops team can monitor and manage the platform
7 risks ranked by likelihood and impact. Front-loaded mitigation -- most prevention happens in Phase 1.
High
Multi-profile auth bypass
A user manipulates profileId in API requests to access another user's health data. With multi-profile architecture, every endpoint is a potential attack surface.
-> Mitigate: checkProfileOwnership middleware is the first check on every profile-scoped route, before any business logic. Write 403-assert tests in CI. PartnerAccess model uses explicit field-level permissions (never blanket read access).
High
Admin panel scope explosion
26 admin sections in the original requirements could consume 60-70% of total development hours if treated as one line item.
-> Mitigate: Scoped to 14 launch-critical sections in Phase 4. Each section estimated separately. Feature-dependent sections (community management) deferred until the features they monitor exist.
High
BDApps OTP + CAAS API reliability
BDApps APIs can be intermittent. OTP delivery failures block sign-up. CAAS charging failures risk incorrect Pro access revocation. Both are on the critical path.
-> Mitigate: Implement retry logic with exponential backoff on all BDApps calls. OTP: resend option after 60s timeout. CAAS: grace period absorbs transient failures -- only revoke Pro after N consecutive daily check failures. Prototype both APIs in Week 1 Day 2 before building the full pipeline.
Medium
Prisma encryption compatibility
prisma-field-encryption supports up to v6.13. Using v6.19 is unverified. Upgrading to Prisma 7 would break encryption silently.
-> Mitigate: Pin to ^6.13.0 initially. Write an integration test that encrypts, stores, retrieves, and decrypts a sensitive field. Run it in CI. Never upgrade Prisma without the test passing. Document the pin constraint in package.json.
Medium
Bengali text layout
Bengali script is 20-40% longer than English. All layouts must accommodate without breaking. Noto Sans Bengali font required. Input method testing (Avro/Probhat) needed.
-> Mitigate: Load Bengali fonts from day one. Test every page in Bengali mode during development. Get client sign-off on Bengali numeral format early. All UI components must be designed with text expansion in mind.
Medium
BDApps API reliability
Carrier billing APIs in Bangladesh can have intermittent failures. BDApps charging status checks and subscription operations may fail transiently, risking incorrect pro access revocation.
-> Mitigate: Implement retry logic with exponential backoff on all BDApps API calls. Grace period prevents immediate access loss on transient failures. Daily cron tolerates missed checks -- only revokes after configurable N consecutive failures.
Low
Prediction cold-start
First-time users with no period history get predictions based on onboarding cycle length entry. Inaccurate for users with irregular cycles. Regular cycles top out near 85-87% accuracy regardless of algorithm.
-> Mitigate: Show "This is an estimate -- accuracy improves after 3+ logged cycles" on the dashboard. Use onboarding value as initial data point. Auto-escalate prediction tier as data accumulates (Tier 1 -> 2 -> 3). Show confidence levels to users.
9
Definition of Done -- v1 Launch
The v1 is shippable when every item below is verified. Do not consider any phase complete until its criteria are met.
Core Functionality
✓
New user can sign up with phone number and verify via BDApps OTP
✓
User can create multiple health profiles with relation types
✓
Profile switcher allows seamless switching between profiles
✓
Onboarding completes: trust screens, goal, cycle history, personal data
✓
Period logging works: start/end with flow intensity in 2-3 taps
✓
Predictions recalculate immediately after any period log
✓
Calendar shows correct colors for period, fertile, ovulation, and low days
✓
Symptom logging works via icon-based tap selection (30+ symptoms)
✓
Email notifications deliver to correct profile
✓
Content articles display in both languages with phase tags
✓
BDApps OTP flow works end-to-end: request → verify → account created
✓
Pro upgrade via CAAS charges correctly and gates features immediately
✓
Admin dashboard loads with KPIs and trend charts
✓
Admin can manage users and content via CMS
✓
Feature gating blocks free users from pro features and allows access for pro users
✓
Admin can terminate user sessions remotely
✓
BDApps charging status checked daily, pro access disabled after grace period
Quality & Security
✓
Field encryption verified: sensitive data encrypted at rest (AES-256-GCM)
✓
Profile isolation tested: user A cannot see user B's health data
✓
checkProfileOwnership middleware on every profile-scoped endpoint
✓
Bengali UI fully functional: all strings translated, layouts not broken
✓
Responsive at 375px (mobile), 768px (tablet), 1280px (desktop)
✓
No console errors in Chrome, Safari, and Firefox
✓
Admin RBAC enforced: Super Admin and Content Admin role separation
✓
Production deployed: Vercel (frontend) + Railway (API + worker)
✓
All loading, error, and empty states implemented
✓
Prediction algorithm unit tested with edge cases
✓
BDApps CAAS charging verified in production (real transaction test)
✓
Zero third-party analytics touching health event data
10
Developer-Hour Estimates
Per-phase hour breakdown based on 20 implementation plans across 4 phases. Hours assume experienced full-stack developers familiar with the stack.
| Phase |
Description |
Plans |
Estimated Hours |
Key Work |
| Phase 1 |
Foundation, Auth, Multi-Profile |
5 plans |
~50h |
Monorepo, Prisma + encryption, BDApps OTP auth, CAAS wrapper, i18n, multi-profile CRUD, onboarding, gating middleware + session store |
| Phase 2 |
Core Cycle Tracking + Predictions |
6 plans |
~62h |
Shared contracts, 3-tier prediction, cycle API, symptoms, dashboard, calendar |
| Phase 3 |
Engagement Layer |
4 plans |
~68h |
Notification infra, email delivery, content platform, CAAS subscription lifecycle + UI |
| Phase 4 |
Admin Panel |
5 plans |
~115h |
RBAC, dashboard + user mgmt, health analytics, content CMS, reports + export, gating/session/subscription admin UIs |
| TOTAL |
~295h |
20 plans across 4 phases |
Recommended Team Plans
Dev workload~148h each / ~7.4h per day
QA workload~80h / testing + regression across 4 phases
Parallel capacity2 tasks at a time (Wave 2 plans)
BufferMinimal — limited room for scope changes
Best forExperienced team, fixed scope, minimal unknowns
WEEKLY CADENCE
Dev A owns frontend, Dev B owns backend. QA starts testing Phase 1 while devs build Phase 2. Tight handoff — QA must start by end of Week 1.
Option B
Recommended Team
Recommended
Dev workload~98h each / ~4.9h per day
QA workload~80h / testing + regression across 4 phases
Parallel capacity3 tasks at a time (full Wave 2 parallelism)
BufferGood — handles scope changes and sick days
Best forBalanced risk, allows for BDApps integration unknowns
WEEKLY CADENCE
Dev A: frontend lead. Dev B: backend + API lead. Dev C: admin panel + integrations (BDApps, SMS). QA overlaps testing Phase N while devs build Phase N+1. Comfortable pace with room for iteration.
QA
QA Engineer Responsibilities
Manual testing of each phase after development completes. Cross-browser verification (Chrome, Safari, Firefox). Mobile responsive testing (375px, 768px, 1280px). Bengali language QA — verify all strings, date/number formatting, text overflow. Multi-profile data isolation testing (user A cannot see user B's data). Security testing for admin RBAC, session management, and feature gating. BDApps billing edge cases (lapse, grace period, re-activation). Regression testing across phases as new features are added.
11
Deployment Architecture
Zero-cost experimental stack using Vercel + Supabase + Upstash. Every service has a defined upgrade trigger so the client can scale without re-architecting.
$0
EXPERIMENTAL PHASE
per month
~$45
AFTER UPGRADE
Vercel Pro + Supabase Pro
0
SERVERS TO MANAGE
fully managed PaaS
| Service |
Provider |
Free Tier Limits |
What it replaces |
Upgrade trigger |
| Frontend React + Vite build |
Vercel Hobby |
100 GB bandwidth/mo
Unlimited deploys
Preview URLs per PR |
Vercel (already planned) |
Team members or >100 GB/mo |
| API (serverless) Express wrapped as Vercel functions |
Vercel Hobby |
100 GB bandwidth/mo
10s function timeout
1M invocations/mo |
Railway Express server ($5+/mo) |
Long-running tasks (>10s) or team |
| Database PostgreSQL 16 + RLS |
Supabase Free |
500 MB storage
2 active projects
Pauses after 7d inactivity |
Railway PostgreSQL ($5+/mo) |
>500 MB or need no-pause guarantee |
| Session / Cache JWT blacklist, rate-limit state |
Upstash Redis |
10,000 commands/day
256 MB storage
HTTP-based (serverless-safe) |
Railway Redis ($5+/mo) |
>10K commands/day |
| Cron jobs Daily CAAS check, reminder scheduler |
Vercel Cron |
2 cron jobs (Hobby)
Daily minimum frequency |
BullMQ persistent workers |
More than 2 crons or sub-daily schedule |
| Async job queue Email delivery, prediction recalc |
Upstash QStash |
500 messages/day
Max 1MB payload
Built-in retries |
BullMQ queues |
>500 messages/day |
| Email Transactional + notifications |
Resend Free |
3,000 emails/mo
100/day limit |
Already planned |
>3K emails/mo or custom domain |
Infrastructure Diagram
┌─────────────────────────────────────────────────────────┐
│ VERCEL (free hobby) │
│ │
│ ┌──────────────────┐ ┌───────────────────────┐ │
│ │ React + Vite │ │ Serverless API funcs │ │
│ │ (static build) │ │ (Express adapter) │ │
│ └────────┬─────────┘ └────────────┬──────────┘ │
│ │ │ │
│ ┌────────┴──────────────────────────┴──────────┐ │
│ │ Vercel Cron (2 jobs) │ │
│ │ daily-caas-check │ daily-reminder-push │ │
│ └───────────────────────────────────────────────┘ │
└───────────────────────┬─────────────────────────────────┘
│
┌─────────────────┼──────────────────┐
│ │ │
┌─────▼──────┐ ┌───────▼──────┐ ┌───────▼──────┐
│ SUPABASE │ │ UPSTASH │ │ RESEND │
│ (free) │ │ Redis (free) │ │ (free) │
│ │ │ │ │ │
│ PostgreSQL│ │ JWT blacklist│ │ Email alerts │
│ + RLS │ │ Sessions │ │ Templates │
│ + pgcrypt │ │ Rate limits │ │ │
└────────────┘ └──────────────┘ └──────────────┘
│
┌───────▼──────┐
│ UPSTASH │
│ QStash (free)│
│ │
│ Email queue │
│ Pred. recalc │
└──────────────┘
⚙️
Express → Serverless Adapter
Express 5 runs as a Vercel serverless function via @vercel/node + a single api/index.ts entry point. All existing middleware (JWT, RLS, rate-limit) works unchanged. The only real change: BullMQ persistent workers are replaced by Vercel Cron (scheduled) + Upstash QStash (async). Function timeout is 10s on Hobby — sufficient for all API routes; upgrade to Pro (60s) if prediction recalculation grows.
🔒
Supabase RLS replaces checkProfileOwnership middleware
Enable Row Level Security on period_logs, symptom_logs, and profiles tables. Set auth.uid() policy so users can only read/write their own rows — enforced at the database level, not just the application layer. Keep the Express middleware as a belt-and-suspenders check. Field-level encryption via prisma-field-encryption still applies on top of RLS.
Deployment Tasks by Sprint Day
| Day | Deployment Task | Owner |
|---|
Day 1 |
Provision all free-tier services
Create Supabase project, enable pgcrypto + RLS. Create Upstash Redis + QStash instances. Create Vercel project, link GitHub repo, set environment variables. Confirm Resend domain verified.
|
Back-end |
Day 2 |
CI/CD pipeline
GitHub Actions: typecheck + lint on every PR. Vercel auto-deploys on merge to main. Supabase migrations run via supabase db push in CI. Preview environments per PR branch.
|
Back-end |
Day 3 |
Vercel serverless adapter + env config
Wrap Express app in api/index.ts with @vercel/node. Verify all middleware works. Set all env vars in Vercel dashboard (SUPABASE_URL, UPSTASH_REDIS_URL, BDAPPS_*, RESEND_API_KEY).
|
Back-end |
Day 8 |
Replace BullMQ prediction recalc with QStash job
On period log save → publish QStash message to /api/jobs/recalc-prediction. QStash delivers with automatic retry on failure. Remove BullMQ dependency.
|
Back-end |
Day 11 |
Vercel Cron setup
Configure 2 cron jobs in vercel.json: 0 8 * * * → /api/cron/daily-reminders (email alerts), 0 2 * * * → /api/cron/caas-check (Pro subscription status). Both secured with CRON_SECRET header.
|
Back-end |
Day 20 |
Production hardening + smoke test
Verify Supabase is not paused (ping endpoint in cron). Set Upstash eviction policy to allkeys-lru. Enable Vercel Analytics. Run full sign-up → OTP → Pro upgrade → CAAS charge smoke test in production.
|
Both |
Upgrade Path
Trigger 1
Supabase project pausing becomes a problem
Upgrade to Supabase Pro ($25/mo) — 8 GB database, daily backups, no inactivity pausing, PITR.
Trigger 2
Need team members or longer function timeouts
Upgrade to Vercel Pro ($20/mo) — 60s function timeout, 1 TB bandwidth, team seats, more cron jobs.
Trigger 3
Redis commands or QStash messages exceed free tier
Upstash is pay-as-you-go above free tier — typically <$1/mo at early scale. No migration needed, just billing kicks in automatically.
Trigger 4
Need persistent workers or prediction model training
Add Railway ($5/mo credit) for a dedicated Express + BullMQ worker process. Frontend + DB stay on Vercel + Supabase — no full migration, just add a worker service.
Required Environment Variables (Vercel Dashboard)
SUPABASE_URL=https://xxxx.supabase.co
SUPABASE_SERVICE_ROLE_KEY=eyJ...
DATABASE_URL=postgresql://postgres:[pw]@db.xxxx.supabase.co:5432/postgres
UPSTASH_REDIS_REST_URL=https://xxxx.upstash.io
UPSTASH_REDIS_REST_TOKEN=AXxx...
QSTASH_URL=https://qstash.upstash.io
QSTASH_TOKEN=eyJ...
JWT_SECRET=[random 64-byte hex]
FIELD_ENCRYPTION_KEY=[AES-256 key for prisma-field-encryption]
BDAPPS_APP_ID=your_application_id
BDAPPS_PASSWORD=encoded_password
RESEND_API_KEY=re_...
CRON_SECRET=[random secret to auth cron endpoint calls]