Skip to content
Projects
1 min read

University Super App

Multi-tenant Flutter + Firebase platform for students, teachers, parents, and staff with role-based dashboards, offline support, and configurable per-university branding.

Role
Architect and lead engineer
Year
2025
Status
prototype
mobilemulti-tenantfull-stack

Overview

A multi-tenant university mobile app built on Flutter and Firebase. Supports four user roles (students, teachers, parents, staff) with role-based dashboards, offline-first reads, and per-university configuration so a single codebase serves multiple institutions with their own branding, modules, and access policies.

Problem

Universities each want their own app, but most can't afford to build and maintain one. Off-the-shelf vendors charge per-seat and lock everything down. The team needed a single codebase that could serve multiple universities cheaply, with each tenant feeling native to its institution.

Approach

Treat every university as an isolated tenant. Load tenant configuration at app boot: branding, theme, enabled modules, role hierarchies, integrations. Use clean architecture so the domain layer doesn't know it's multi-tenant; only the infrastructure layer does. Cache aggressively for offline support since student campuses have spotty WiFi.

Architecture

  • Framework: Flutter 3.41+ with Dart.
  • State management: Riverpod, scoped per-feature.
  • Routing: GoRouter with role-aware route guards.
  • Backend: Firebase (Auth, Firestore, Storage, Cloud Messaging, Analytics, Crashlytics).
  • Offline storage: Hive for cached reads with conflict-aware sync on reconnect.
  • Architecture: Clean architecture pattern, domain-driven feature folders.

Tech stack

  • Flutter 3.41+, Dart
  • Firebase (Auth, Firestore, Storage, FCM, Analytics, Crashlytics)
  • Riverpod (state), GoRouter (navigation)
  • Hive (offline storage)

Engineering highlights

  • Role-based dashboards: student, teacher, parent, staff each see a different home screen tied to their permissions and current academic context.
  • Offline-first reads: Hive caches every read; the UI never blocks on the network.
  • Per-tenant config at boot: branding, theme, enabled modules, and role hierarchies all loaded from a tenant config doc.
  • Clean architecture: domain layer is multi-tenant-blind, infrastructure layer handles isolation.
  • Modules: academics (grades, schedule, courses), campus (map, services), communication (announcements, messaging), documents (forms, transcripts).

Status

Production-ready prototype, awaiting institutional pilot.

Want to dig deeper?

Ask my AI agent anything about how this was built, what tradeoffs I made, or how it could fit your team.

Ask my AI →