NxtSzn — Multi-Tenant EdTech Platform

Two problems wearing one product

NxtSzn connects university students with mentors and internship opportunities, which sounds like a single system and is really two. There is a marketplace problem — matching students to mentors and opportunities well enough that both sides stay — and underneath it a multi-tenancy problem, because each university runs as its own tenant on shared infrastructure.

The tenancy requirement is not a preference. Institutions do not share their students' data with one another, so isolation between universities is the baseline condition for any of them participating at all. That has to be structural rather than a filter someone remembers to apply, because the failure mode is not a bug report — it is one university seeing another's students.

The marketplace half carries the harder behavioural problem. A matching platform is worth nothing while its profiles are empty: mentors will not engage with blank records, students will not complete profiles for a platform where nothing seems to be happening, and each side waits for the other. Whether the product works at all is decided during onboarding, before any matching logic runs.

Five tenants, one codebase, and a deadline that does not move

Five universities meant five cleanly isolated tenants served from one codebase. That combination is the constraint: shared infrastructure keeps the platform economically viable for a young company, while isolation has to hold as though the universities were on separate systems. Every query, every list, every export has to be scoped by tenant, and the cost of shared infrastructure is that this discipline can never lapse.

The delivery constraint was a hard launch deadline, and deadlines in this domain are unusually unforgiving. A platform serving a student intake has to exist when that intake happens; missing the window does not delay the launch by a few weeks but pushes it past the period it was built to serve. That reality shapes prioritisation more than any technical decision — it forces an honest split between what must exist at launch and what can follow, made early rather than discovered late.

The third constraint is that two different audiences had to be onboarded, and they are not variations of each other. Students arrive in volume, are unfamiliar with the platform, and abandon anything that feels like paperwork. Mentors are working professionals contributing time, arrive in far smaller numbers, and expect their effort to be respected. Building one onboarding flow with a role toggle would have served neither well.

How it was built

Multi-tenancy runs through the data model rather than sitting on top of it. Serving five universities from one codebase means the tenant is part of how records are addressed, not a parameter checked at the edge — which is what keeps isolation intact as features are added by people who were not present for the original decision.

The onboarding flows are where the product's success was actually determined, and they were built as two distinct paths. The student path is designed for completion under low motivation: short, obviously progressing, and asking for information at the point where its purpose is visible rather than all at once behind a wall. The mentor path is designed for a smaller, more deliberate audience whose time is the scarce resource, and it continues past signup into the management surface a mentor network needs to stay organised.

Next.js, Node.js and TypeScript across both ends is a choice that pays off specifically under a deadline. One language across the stack means the shapes crossing the boundary are checked rather than assumed, and the class of bug where the front end and the API quietly disagree about a field simply does not occur — which is exactly the class of bug that consumes the last fortnight of a fixed-date project.

What the numbers mean

85% profile completion across 5,000 students is the figure that deserves the most attention, and it is easily mistaken for a vanity metric. It is not. Profile data is the input to matching, so completion is not a measure of engagement — it is a measure of whether the core function has anything to work with. A matching platform at a low completion rate is a directory of empty records, however good its algorithm.

Five universities and 5,000 students describe the tenancy working as intended: one deployment, five institutions, and no evidence of the isolation being the thing anyone had to think about. The 40-mentor network alongside those 5,000 students shows how asymmetric the two sides are, which is why mentor onboarding and management were treated as their own problem rather than a smaller version of the student flow. When one side of a marketplace is that much scarcer, protecting its experience is what keeps the platform alive.

Shipping two weeks ahead of a hard deadline is worth reading against what the founder reported afterwards — that his university matched the total number of student internships from the previous summer in a single month. That is the outcome the platform existed to produce, and it is the more meaningful of the two figures. Delivering early only mattered because it meant the platform was live and populated before the period when those matches could actually happen.