The visible feature was only the surface
Education organizations need familiar public information and publishing workflows, but cloning whole codebases per institution creates drift and costly maintenance.
The system also had to respect concrete constraints. Three institution types and multiple layouts must share behavior without content/theme leakage. MongoDB, Google OAuth/Drive, and Resend are optional/configured services. Public read-only defaults must remain usable when database-backed administration is absent.
My role covered application architecture and full-stack engineering, with responsibility for content architecture, authentication, and deployment.
I turned the constraints into boundaries
Next.js public/admin routes; feature-owned content/admission/media domain modules; centralized institution and visual-theme configuration/tokens; MongoDB/auth/Drive/email adapters with server-boundary enforcement.
Split institution identity tokens from layout composition so branding and structure vary independently.
Resolve both themes server-side to prevent a fallback-theme flash.
Keep route and feature code shared, accepting stronger configuration discipline to avoid forks.
The key decision: Split institution identity tokens from layout composition.
The implementation had to prove the model
I delivered the work across the full path: Built public education pages and admin publishing workflows. Implemented institution/layout selection with named themes. Added MongoDB content/admission storage, Google sign-in/Drive media, and email integration. Created Playwright coverage, archived prototypes, SEO/social metadata, and deployment docs.
The result is concrete: Developers can deploy one starter for three institution categories. Administrators can publish content and manage enquiries. Visitors get configured branding/layout on shared routes. Deployments can fall back to read-only repository defaults where documented.
The senior engineering lesson was that solving the visible workflow is only half the job. The architecture must also make constraints, failure modes, evidence, and ownership explicit enough for the next change to remain safe.