The product and context
A connected operating system for schools, colleges and institutes. This case study focuses on one architectural decision, rather than claiming to document every part of the product.
My role
My contribution spans strategy, technical project management, qa and infrastructure. The decision described here is my first-person account of the direction I advocated. It is not a claim that I independently built every component of the platform.
The problem
A separate deployment for each institute would multiply release work and make onboarding harder to repeat.
The product needed to support multiple institutes without turning each onboarding into a separate infrastructure project. The concern was how the architecture would behave as the platform grew.
The options and tradeoffs
One approach is to deploy a separate instance for every institute. That provides a visible infrastructure boundary, but increases the number of environments to maintain. The alternative is a shared application with explicit tenant boundaries and institute-specific configuration.
The decision
Use a shared codebase with multi-tenancy, institute subdomains and tenant isolation from the start.
The system focus is:
- Tenant boundary
- Role-based access
- Shared platform
- Institute subdomains
What the design needs to protect
- Every request must resolve to the right institute.
- Authorisation must respect the tenant boundary.
- Shared services must not expose another institute’s private data.
- Onboarding configuration needs consistent validation.
These are design requirements and review questions, not a claim that a complete public audit has verified every control.
Delivery and verification questions
Can an authenticated user request another institute’s records? Does onboarding require code changes or only approved configuration? Do background jobs retain the correct tenant context? These are useful acceptance questions for delivery and QA.
The tradeoff
Tenant-aware access and testing require care up front. Every request needs to respect the correct institute boundary.
Outcomes and evidence
This account establishes the problem, my reasoning and the design direction. It does not assert measured savings, performance improvements or a verified before-and-after result. Implementation artefacts, screenshots and measurements can be added when they are ready to share.
What I learned
Architecture decisions shape the cost of delivering the next customer, not just the first one.
The wider lesson is to connect the product’s operating constraints to the architecture and delivery plan. A decision is easier to evaluate when its assumptions, tradeoffs and verification questions are visible.