Ajman / UK product surface (mansah.co.uk) · Custom Software / Enterprise Platform
Mansah – Enterprise School Management
How Mansah replaced fragmented school tools with a multi-tenant operations platform — 7 Spring Boot services, schema-per-tenant isolation, and production Nginx ops
Executive summary
- •Problem: schools ran admissions, fees, attendance, and messaging in disconnected tools — data drift and unsafe multi-campus growth.
- •Solution: enterprise multi-tenant platform (Java 21 / Spring Boot 3 + React 19) with schema-per-tenant PostgreSQL, Stripe/GoCardless, and role portals.
- •Result: one operable system for school lifecycle; new schools onboard via owner portal without rewriting the product per tenant.
The business challenge
Education operators needed one enterprise platform for a full school — not a lightweight SaaS with bolted-on modules. Students, parents, teachers, and admins each needed distinct workflows. Payments, invoicing, email/SMS, admissions, attendance, homework, discipline, and staff compliance had to live together, with hard isolation when multiple schools shared the platform. Fragmented tools created reconciliation work; copying a school setup for a new campus copied risk.
- •Data inconsistency between fees, attendance, and parent messaging
- •No safe tenancy model for branding + payment credentials per school
- •Peak classroom wifi failures broke attendance capture
- •Compliance tracking (DBS / safeguarding / first aid) lived outside the system of record
Goals & non-goals
Goals
- •Multi-tenant isolation without a separate server per school
- •Role-correct portals for Super Admin, Admin, Teacher, Parent
- •Per-tenant Stripe/GoCardless + email/SMS configuration
- •Production ops: Docker, Nginx SSL per subdomain, observability
Non-goals
- •Generic white-label marketplace (purpose-built school ops instead)
- •Native mobile apps as v1 primary surface (PWA resilience first)
- •Invented concurrent-user marketing claims without measurement
The solution
StackWise designed Mansah as an enterprise multi-tenant school management system. Each school is a tenant with isolated schema, branding, gateways, and messaging settings. Domain microservices sit behind Spring Cloud Gateway; the React 19 client delivers role dashboards with PWA offline-tolerant attendance sync for unreliable classroom networks.
Multi-tenant isolation
Schema-per-tenant PostgreSQL + subdomain routing; Flyway migrations per school boundary
Role portals
Super Admin / Admin / Teacher / Parent experiences with JWT + RBAC enforcement at API layer
Finance
Invoices, subscriptions, Stripe + GoCardless configured per tenant
Communications
Gmail SMTP / Microsoft 365 + SMS templates with delivery/open/bounce analytics
Academic ops
Admissions, classes, timetables, exams, homework, discipline, staff compliance alerts
Resilience
PWA/Workbox shell; offline-tolerant bulk attendance sync
Technical architecture
| Layer | Technology | Why | Alternatives |
|---|---|---|---|
| API edge | Spring Cloud Gateway | Single entry, routing, cross-cutting auth | Exposing each service publicly |
| Services | Java 21 / Spring Boot 3 (7 domains) | Clear bounded contexts; independent deployability | Modular monolith only |
| Resilience | OpenFeign + Resilience4j | Timeouts/circuit breaking between services | Naive sync HTTP only |
| Data | PostgreSQL schema-per-tenant + Flyway | Hard data boundary without N servers | Shared tables + tenant_id only |
| Cache | Caffeine | Low-latency local cache for hot reads | Redis-first complexity before need |
| Client | React 19 + Vite + TanStack Query | Modern SPA DX; role dashboards | Server-rendered monolith UI |
| Payments | Stripe + GoCardless | Card + direct-debit school fee patterns | Manual bank transfer only |
| Ops | Docker + Nginx + Prometheus/Grafana | Linux production shape buyers recognize | Laptop/demo hosting |
Implementation path
- 1.Domain split: auth, admin, student, teacher, course, parent, support services
- 2.Tenancy model + Flyway seeding scripts for safe school onboarding
- 3.Payment gateway settings + webhook-ready finance flows per tenant
- 4.Role dashboards + PWA attendance path for classroom wifi failure modes
- 5.Nginx SSL per school subdomain; observability dashboards
Challenges & trade-offs
Multi-school data bleed risk
Why hard: Shared DB without isolation would leak PII/fees across schools
Solution: Schema-per-tenant + subdomain routing
Trade-off: More migration complexity than a single-schema MVP
Unreliable classroom wifi
Why hard: Attendance capture fails during peak periods
Solution: Offline-tolerant bulk sync via PWA shell
Trade-off: Eventual consistency until sync completes
Payment credentials per school
Why hard: One global Stripe key breaks multi-tenant finance
Solution: Per-tenant gateway configuration in Payment settings
Trade-off: Ops must validate keys during onboarding
Results & metrics
Labels: WP = website-published · OPS = operational outcome · ARCH = design target
| Metric | Before | After | Source | Label |
|---|---|---|---|---|
| Microservices delivered | — | 7 domain services | Architecture | OPS |
| Role portals | 1 generic dashboard risk | 4+ role experiences | Product design | OPS |
| Tenancy model | No isolation | Schema-per-tenant PostgreSQL | Architecture | OPS |
| Stack generation | Legacy JVM risk | Java 21 + Spring Boot 3 + React 19 | Engineering | OPS |
| Observability | Blind deploys | Prometheus + Grafana | Ops design | ARCH |
Value by stakeholder
Ops / school admin
One system for admissions → fees → messaging; less reconciliation
IT / technical buyer
Spring Boot microservices, gateway, tenancy, Nginx — production-shaped
Finance
Per-school Stripe/GoCardless; invoice + subscription flows
Parents / teachers
Role-correct portals instead of one overloaded UI
Planning something similar?
Tell us the stuck flow. We can start with a scoped paid diagnosis — reproduce, investigate, and give written options.