Technology & Architecture Brief

Built on the same modern technology used by the world's leading platforms — explained plainly, and in technical detail.

This page covers Stavion ERP's public website and platform technology from two angles: what it means for your school day-to-day, and — for anyone on your side who wants to go deeper — the actual stack, architecture, and security model underneath it.

For management: what this means for you
For IT/technical reviewers: the real stack & architecture
Part 1 — Your Public Website

Not a website builder with plugins bolted on — a platform engineered for you

Your public website is custom-engineered on a modern, secure, and future-proof foundation, and wired directly into the same platform that runs your admissions, fees, and communication.

Instant-loading, modern website

Built with the same class of technology (React + TypeScript) used by Google, Netflix, and Meta — your school's website loads in a couple of seconds, even on an average mobile connection.

📱

Looks perfect on every device

Phone, tablet, or laptop — the site automatically adapts, so every parent sees a polished, professional school online, no matter how they browse.

🔒

Secure by design, not by patchwork

No outdated plugins or themes to hack — unlike typical WordPress sites. Encrypted HTTPS connections, modern security headers, and a codebase that doesn't depend on third-party plugin updates to stay safe.

🔍

Found on Google, automatically

Search-engine optimisation is built in from day one — page titles, descriptions, sitemaps, and structured data help parents searching for "schools near me" find your school first.

🔗

Directly wired into your ERP

Admission inquiries, contact forms, and career applications on your website don't land in an inbox to be manually copied — they flow straight into Stavion's admissions pipeline, instantly.

🛠️

Future-proof and easy to extend

New pages, sections, or campaigns can be added without rebuilding the site. No recurring "theme" or "plugin license" fees — and no risk of the site breaking after a browser or platform update.

Part 2 — The ERP Platform

Built on the same architectural principles as enterprise software used by large organisations worldwide

Behind the portals, Stavion is an API-driven, configuration-driven platform — the same approach large enterprise software vendors use so their products can be customised for every customer without rewriting code for each one.

🔌

API-driven, not bolted together

Every module — admissions, fees, attendance, exams, payroll — is a connected service with a clean API underneath. New integrations (payment gateways, WhatsApp/SMS, government portals like UDISE+) plug in without re-engineering the core.

🧩

Configuration-driven, not hard-coded

Classes, sections, fee structures, grading rules, and approval workflows are set up through configuration screens — not custom programming. When a rule changes, it's a configuration change, not a software rebuild.

🧱

Modular — switch on what you need

Transport, library, payroll, analytics — each is an independent building block on the same core. Turning one on doesn't mean redeploying or disrupting the rest of the platform.

🏢

Multi-tenant, isolated by design

Every school's data lives in its own isolated space on shared, centrally-maintained infrastructure — never mixed or visible to any other institution on the platform.

🔐

Role-based access, enforced centrally

A teacher, an accountant, and a principal each see exactly what their role allows — automatically, consistently, across every portal — without relying on staff to "just not click that".

🔄

One source of truth, real time

Update a student's attendance once, and it's instantly reflected in the teacher's register, the parent's app, and the management dashboard — no exports, no manual syncing between systems.

☁️

Cloud-native and built to scale

Containerized services that run the same way in development and production — designed to grow from a single campus to a multi-school group without re-architecting.

📊

Reporting without raising a ticket

A built-in report and dashboard builder lets management create the views they need themselves — no developer, no vendor request, no waiting.

For Technical Reviewers

The actual technology stack, layer by layer

Every layer uses current, actively-maintained, industry-standard technology — not a proprietary or abandoned framework that locks you in or stops receiving security updates.

Layer Technology Why it matters
Public website & portals React 18TypeScriptVite 5Tailwind CSS 3React Router 6 Component-based, type-checked front end with instant navigation, a shared design system, and a build pipeline that produces small, fast-loading bundles.
Backend API Node.jsExpressTypeScriptZod A type-safe REST API with schema validation (Zod) on every request, so malformed or malicious input is rejected before it reaches business logic.
Database PostgreSQL 16Prisma ORM A proven, ACID-compliant relational database with type-safe queries and version-controlled schema migrations — no hand-written SQL prone to injection bugs.
Caching & sessions Redis 7 Fast in-memory store for session and cache data, keeping the platform responsive as more schools and users come online.
Authentication & access control JWTbcryptTOTP 2FA (speakeasy) Industry-standard token-based sessions, salted password hashing, and time-based one-time-password two-factor authentication for sensitive accounts.
HTTP security & logging HelmetCORS policyPino structured logs Secure HTTP headers applied by default, a locked-down cross-origin policy, and structured request logging for audit and incident response.
Infrastructure Dockerpnpm workspaces (monorepo)Shared TypeScript types Containerized services that run identically in development and production, with shared type definitions between front end and back end to prevent integration bugs.

Every dependency above is a widely-adopted, actively-maintained open-source project with a large community and long-term support — chosen specifically so the platform never depends on a single vendor or an obscure, unsupported tool.

For Technical Reviewers

API-driven and configuration-driven — what that actually means under the hood

"API-driven" and "configuration-driven" are common claims in enterprise software. Here's specifically how each one is implemented in Stavion.

What this means operationally

  • Add a new fee head, grading scale, or approval rule through a settings screen — no software update or downtime required.
  • Connect payment gateways, WhatsApp/SMS providers, and government portals through documented APIs, without touching core code.
  • Turn on transport, library, or payroll independently — the rest of the platform keeps running unaffected.
  • Every school's data stays in its own isolated space, even though all schools run on the same shared platform.
  • A staff member's permissions follow their role automatically across every portal — management, principal, teacher, parent, student.

How it's implemented

  • API-first: every module exposes a versioned REST API (Express + Zod-validated routes); portals and the public website are API consumers, not tightly coupled to the database.
  • Configuration-driven: fee structures, grading scales, academic calendars, and workflow rules are stored as data in PostgreSQL and read at runtime — changing them is a data change, not a code deployment.
  • Per-tenant feature flags: each module can be enabled or disabled per school without affecting other schools or requiring a redeploy.
  • Multi-tenant data isolation: each school's records are scoped at the data layer via Prisma, preventing any cross-tenant data access by design.
  • Centralised RBAC: roles and permissions are enforced via JWT claims checked by shared middleware on every API route — not re-implemented per screen.
  • Shared type contracts: a shared TypeScript types package keeps the API and every front end (website, portals) in sync, so a configuration or schema change is caught at compile time.
Security & Compliance

How data is protected — for the board and for your IT reviewer

These are the controls in place today, mapped to the questions both a school management committee and a technical reviewer typically ask.

For school leadership

  • Two-factor authentication on accounts that can change fees, marks, or configuration — not just a password.
  • Complete audit trail — every change to financial or academic records is logged with who, when, and what changed.
  • Isolated, private data per school — never pooled or shared with any other institution on the platform.
  • DPDP Act, 2023 alignment — consent capture, data export, and right-to-erasure built into the platform.
  • Your data, exportable, always — no lock-in by data hostage.

For technical reviewers

  • HTTPS/TLS everywhere — all traffic encrypted in transit, with HSTS enabled at the hosting layer.
  • No inline scripts / XSS-safe rendering — React escapes all rendered output by default.
  • Schema-validated API inputs (Zod) and parameterized database access (Prisma) — closes off SQL injection and malformed-payload attacks.
  • Salted password hashing (bcrypt) and short-lived JWT sessions — no plaintext credentials stored or transmitted.
  • Security headers via Helmet — Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, and Referrer-Policy set by default.
  • Dependency auditing — lockfile-pinned versions, checked regularly via npm audit.
How It Fits Together

One platform, cleanly separated into layers

The public website, the ERP portals, and the backend API are separate applications in a single monorepo, sharing types and a common data model — so they evolve together without becoming tangled.

Layer 1

Public Website

React + Vite site for admissions, school info, and inquiries.

  • Marketing pages
  • Inquiry & career forms
  • Staff login / portal entry
Layer 2

ERP Portals

Role-based apps for management, principals, teachers, parents, students.

  • Shared component & design system
  • Role-based access control
Layer 3

Backend API

Express + TypeScript service, the single source of truth for all apps.

  • Authentication & 2FA
  • Validated business logic
  • Audit logging
Layer 4

Data & Infra

PostgreSQL + Redis, containerized, with version-controlled migrations.

  • Per-school data isolation
  • Automated backups
  • Deployable to any cloud or on-prem