Pathana Platform

What is Pathana?

Pathana is a planning tool for schools. Its site describes it as giving students "clear, actionable roadmaps for their journey to college and career success", and sets out five steps: choose a goal, build a profile, generate a roadmap, check status, and stay accountable through regular check-ins.

The product pages list the pieces behind those steps. Students get career exploration with skill alignment, comparison of majors and their requirements, and a step-by-step plan organised as Now / Next / Later, with prerequisite mapping and next actions that carry deadlines. Counsellors get caseload visibility with urgency indicators, task templates, recurring check-ins and support plans. Families get "permissioned summaries and milestones". Programme administrators get an aggregate overview of programme health, caseload balancing and reporting.

Two details on the site set its tone: every status and recommendation comes with an explanation, and the guidance is labelled "Guidance only. Outcomes and policies vary."

What problem is Pathana addressing?

Moving from high school to college or a career is a multi-year sequence of dependent decisions: which courses to take, which prerequisites they unlock, which options they quietly close. Yet nothing in a typical school's software models that path as one continuous object.

When no single system owns the path, the record of a student's progress fragments. Course history lives in one place, a counsellor's notes in another, a family's understanding somewhere else, and nobody holds the full picture at the moment a decision has to be made.

The cost of that gap stays invisible until it is too late to fix. A missed prerequisite early on can close options years later. Pathana's approach is to make the sequence explicit, trackable and shared before the consequences arrive.

What did Sameem work on?

Sameem worked on Pathana as an engineer at ivector. The platform is built with Next.js on the front end and Node.js behind it, served through serverless APIs rather than a permanently running application server, with Firebase handling authentication and data storage.

The sections below explain why that stack suits a school planning product and what each part has to get right.

Why serverless APIs for school software?

School software does not see steady traffic. It sits close to idle at night and through holidays, then spikes during course registration, advising periods and reporting deadlines. A serverless API absorbs those spikes without anyone provisioning servers for a peak that comes a few times a year, and costs close to nothing in between.

Different schools also run on different calendars, so a platform meant for more than one school sees its peaks arrive at different times. That makes fixed capacity planning especially wasteful, and it is a large part of the case for serverless here.

Keeping the API in Node.js means the same language runs on both sides of the boundary. Validation rules, roadmap structures and milestone shapes can be defined once and reused by the Next.js front end and the API, rather than rewritten for each tier.

Why Firebase for authentication and data storage?

Firebase handles authentication and data storage on Pathana, which addresses two problems education platforms hit early. The first is identity. A school platform has to admit students, counsellors and family members as genuinely different kinds of user, each seeing a different slice of the same record. Firebase Authentication supplies sessions and tokens without a custom credential store, and those tokens can carry role claims that storage rules and API handlers read directly.

The second is authorisation at the data layer. Student records are sensitive by default, and a counsellor at one school must never be able to open a student's record at another. Enforcing that only in application code means every new endpoint is a fresh chance to leak data; enforcing it in storage rules tied to the signed-in identity makes the restriction structural.

Firebase's real-time data model also removes most polling, so a milestone marked complete can appear for other viewers without a refresh.

How do roadmaps and milestones map onto data?

The roadmap is Pathana's core object: a personalised plan that spans high school and points at a college or career goal, broken into milestones a student can be measured against. On the site it appears as a Now / Next / Later plan with prerequisite mapping and deadlines.

Modelling it well is harder than it looks, because a roadmap is both a template and an individual record. Schools need shared pathway structures so counsellors are not writing every plan from nothing, while each student's plan has to diverge from the template as course choices, interests and results change. That argues for a document store, where each student's plan carries its own state, over a rigid relational schema that forces every plan into identical columns. Firebase's data model works that way.

Milestone tracking then becomes a state machine over the plan's steps: not started, in progress, complete, blocked. Storing progress per step rather than as a single percentage is what lets a platform explain why a student is behind, not just that they are, which is what the site means by progress tracking "with clear reasons".

How does sharing between students, counsellors and families work?

Sharing one student's plan between three parties is mainly an access-control problem, not a design one. The student owns the work, the counsellor advises and steps in, and the family needs visibility without editing rights that would distort the record. Pathana's site states that family visibility and messaging "depend on permissions and school policy", which is exactly that model.

With Firebase Authentication, each of those people is a separate signed-in identity rather than a shared login, so every change to a roadmap can be attributed to a person. Over a plan that runs for years, that attribution is what makes the record trustworthy.

Real-time updates matter here too. When a counsellor updates a milestone during a meeting, the student's and the family's views should reflect it straight away rather than at the next page load, so everyone is working from the same version of the plan.

What do dashboards and reporting demand?

Counsellor caseload views and programme-level reporting are a different workload from editing one plan. Reading a single student's roadmap is a cheap lookup. Asking which students in a caseload are falling behind, or how a whole programme is doing, is an aggregation across many records, and running it against the live store on every page load does not scale.

The usual answer, and one a serverless Node.js API supports well, is to move aggregation off the request path: compute summaries when data is written or on a schedule, store the result, and let the dashboard read something already summarised. Next.js contributes through server-side rendering and caching, so an expensive view is computed on the server and sent as HTML rather than assembled in the browser.

That matters on the low-powered laptops and Chromebooks many schools issue to staff and students.

What engineering challenges does a multi-school platform raise?

A platform meant for more than one school turns several quiet design decisions into hard constraints. Multi-tenancy is the first: every query, rule and API handler has to be scoped to one institution, and the isolation has to hold by construction rather than by careful coding, because a leak of student data across schools is not a bug a product recovers from.

Seasonality is the second. Academic calendars concentrate registration, planning and review into narrow windows, and the serverless API model is the direct answer to that curve, scaling with demand instead of against a fixed number of servers.

The third is long-term integrity. A roadmap is a record that runs for years, so changes to the schema, revisions to pathways and graduating year groups all have to be handled without corrupting history. A plan written years earlier still has to display correctly for the student who owns it.

Where can you see Pathana?

Pathana's site is live at pathana.net. Its product pages describe the student, counsellor, family and administrator views covered above, and its main call to action is "Request a Pilot", a form addressed to schools and programmes.

Pathana is a web platform for schools. Sameem worked on it at ivector, with Next.js, Node.js, serverless APIs and Firebase.

Why this stack

• Next.js: the front-end framework. Pathana serves students, counsellors, families and administrators, often on low-powered school devices, and server-side rendering moves dashboard and roadmap composition onto the server, so heavy views arrive as HTML instead of being assembled in the browser. Its routing and API route model also let one framework own both the pages and the endpoints behind them.
• Node.js: running the API in Node.js keeps one language across the stack, so roadmap structures, milestone states and validation rules are written once and shared rather than duplicated between front end and back end. Its non-blocking I/O suits a workload dominated by waiting on database and authentication calls rather than by heavy computation.
• Serverless APIs: school traffic is seasonal, idle for long stretches and then spiking during registration and review windows. A serverless API scales with that curve instead of against a fixed number of servers, which matters more when different schools hit their peaks on different calendars.
• Firebase: it supplies authentication and data storage in one model. Its tokens give every student, counsellor and family member their own identity, so roadmap changes are attributable rather than hidden behind a shared login. Its rules layer lets school and role isolation be enforced at the storage boundary instead of re-implemented in each endpoint, and its real-time model removes the polling a shared, multi-viewer plan would otherwise need.
• Document-oriented storage (via Firebase): a student roadmap is part shared template and part individual divergence, which fits a document model better than a fixed relational schema that would force every plan into identical columns and need a migration every time a pathway is revised.