BusinessRoadmap

Roadmap

Strategy in one line: ship, don’t build. The core product is built; the work is making it reliable, demoable, and revenue-generating for a Gujarat-school pilot.

This page reflects the product roadmap as understood in mid-2026. Treat phase status as a point-in-time snapshot — confirm against the current state of prod and the issue tracker before making commitments.

The central fact

The product spent a long time “largely built but not shipped” — a big refactor (new mobile UI, tenant-subdomain routing, sub-admin RBAC, announcements, student-leaves, transport/hostel on mobile) lived on a feature branch while production ran older code. That branch has since been merged to main and deployed to production for the backend and admin-web. The mobile app ships separately via Expo OTA / store release.

So the strategy is not “build more features.” It is: get what exists in front of paying schools, reliably.

Phases

PhaseThemeStatus
P0Security hardening✅ Done — internet-exposed DB closed, IAM static-key → instance-role, CI on OIDC, port 22 closed (SSH → SSM)
P1Safe coordinated ship to prod✅ Done — server + admin-web on main/prod, migrations applied, backups + rollback in place
P2Reliability🔄 In progress — prod email via AWS SES (exit sandbox), monitoring, N+1 fixes, pagination
P3Demo polish🔄 In progress — remove “coming soon”, native PDF download, dark mode
P4Online fee collection (Razorpay)⏳ Planned — the revenue lever. Schema is gateway-ready; the payment flow is not yet built
P5Mobile parity🔄 Ongoing — transport-admin & hostel-admin done on mobile; remaining parity is pilot-driven

The revenue lever

P4 (online fee collection) is the commercial priority. Fee structures, invoices, payments, and receipts already exist; what’s missing is an integrated payment gateway (Razorpay) so parents can pay online and money flows to the school. The payment schema already carries an idempotency key and gateway-ready fields, so the groundwork is in.

Until P4 lands, fees are recorded manually by finance staff. See Fees & Finance.

  • Mobile release — the Expo client ships on its own OTA/store cadence (release workflows are commit-token gated), independent of the server/admin-web deploy.
  • Control-plane split — onboarding and “login as tenant” moved into the super-admin panel; admin-web is tenant-only. See Control plane.
  • Scripted onboarding — white-glove tenant seeding via a script + YAML, with a school-setup wizard behind a feature flag. See Onboarding & Setup and ADR-007.
  • Performance — a Redis cache layer and permission caching are live; rate-limiting redesign and config caching are queued. See ADR-005.

Not yet built

These have a plan-feature key or placeholder only — no working module behind them: examinations, reports, assignments, library, inventory. They are intentionally out of scope until the pilot justifies them. See the feature matrix in Product → Subscriptions.