TSMulti-Tenant SaaS · EdTechEnterprise SaaSCase study
Technaut SMS — Coaching & Institute Platform
Gives a coaching institute one workspace for admissions, batches, attendance, fees and results — with apps for students, faculty and the office.
Multi-tenant SaaS for coaching centres, tuition classes, training institutes and subscription study libraries: students, batches, timetable, attendance, fees, tests, materials and a seat-based study library, served to three Flutter apps and a Next.js web panel from one NestJS API.
Source private
Industry
Education & Coaching
Role
Architect & Full-Stack Engineer
Type
SaaS Platform
Year
2026
Status
Delivered
3 + web
Client Apps
18
Modules
Isolated workspaces
Tenancy
Overview
Technaut SMS gives every institute an isolated workspace covering the whole operating cycle: admissions and student profiles, courses, subjects and syllabus, batches and timetable, attendance, fees with installments and receipts, homework, study material, tests and results, an inquiry CRM, certificates and ID cards, a book library, and a subscription study library with seats, plans and QR check-in.
Attendance is deliberately dual-mode. Manual marking covers the ordinary case, and a rotating QR code covers self-check-in — rotating specifically so a screenshot of the code is worthless a moment later, which is the failure mode of every static-code attendance system.
Four surfaces sit on one API: a Next.js web app serving the public marketing site plus the admin and faculty panels, and three Flutter apps for students, teachers and the office. A TypeScript package of Zod schemas and enums is shared by the API and the web app; a Dart core package carries the API client, models, theme and widgets for all three apps, so a change to the contract lands everywhere at once.
Where an integration is not configured, nothing pretends to have worked: WhatsApp and push messages land in a notification outbox with a QUEUED status and the admin panel labels them pending, rather than reporting a delivery that never happened.
The problem
Coaching institutes run admissions, batches, attendance, fees and results across registers, spreadsheets and WhatsApp groups. Nothing reconciles: a fee receipt does not know about the installment plan, attendance does not reach a parent, and the office cannot answer "who has not paid" without a manual pass through the books.
Discovery
Mapped the institute year rather than the feature list — inquiry, admission, batch allocation, daily attendance, installment cycles, tests, results, certificates — and modelled the objects that recur at every stage instead of building isolated modules.
The solution
Built a multi-tenant NestJS platform covering the whole cycle, with a Next.js web app for the marketing site, admin and faculty panels, and three role-specific Flutter apps sharing one Dart core package. Institutes are provisioned as isolated workspaces on a single deployment.
Technical stack
Frontend
Next.js 15
Tailwind CSS 4
TanStack Query
Zustand
Flutter
Riverpod
TypeScript
Backend
NestJS 11
Data
MySQL 8
Also used
Prisma
Dio
Zod
System architecture
1
NestJS 11 + Prisma over MySQL 8, with Swagger docs and a shared Zod contract package
2
Next.js 15 web app serving the public marketing site plus the admin and faculty panels
3
Three Flutter apps (student, teacher, admin) over a shared Dart core — API client, models, theme, widgets
4
packages/shared (TypeScript) consumed by API and web; packages/core (Dart) consumed by all three apps
Notification outbox with a channel-adapter interface — unconfigured channels park as QUEUED
Engineering challenges
Challenge
QR-based attendance is trivially defeated: one student screenshots the code and the whole batch marks itself present from outside the room.
How I solved it
Made the code rotate on a short cycle so a captured image expires almost immediately, and kept manual marking as a first-class path rather than a fallback, since connectivity in a classroom is not guaranteed.
Challenge
Fees, installments and receipts modelled separately meant a receipt could be issued that no installment plan knew about, so outstanding balances drifted.
How I solved it
Tied receipts to installment records so issuing one settles a specific scheduled amount, making "who owes what" a query rather than a reconciliation exercise.
Challenge
With no WhatsApp or push credentials in most deployments, a naive implementation reports every message as sent and nobody notices for weeks.
How I solved it
Routed all outbound messages through an outbox with a channel-adapter interface. Without credentials the job parks as QUEUED with a readable reason and the admin panel shows it as pending — never as delivered.
Core features
Multi-tenant institute workspaces with isolated data
Admissions, student profiles, guardians and batch assignment
Courses, subjects, syllabus, batches and timetable
Attendance — manual marking plus rotating-QR self-check-in
Fees with installment plans, receipts and expense tracking
Homework, study material, tests and results
Inquiry CRM for prospective admissions
Certificates and ID-card generation
Book library plus a subscription study library with seats, plans and QR check-in
Three Flutter apps — student, teacher and office — over one shared Dart core
Notification outbox that marks unconfigured channels QUEUED instead of faking delivery
Results & impact
An institute runs admissions through results in one workspace, and each role gets an app that shows only its own work. Because every surface reads the same API, a fee recorded at the office desk is visible to the parent and the faculty panel immediately.
Screenshots
What I learned
Modelling the annual cycle rather than the feature list is what keeps modules from drifting apart.
A rotating token turns a convenience feature into one that can actually be trusted.
Software that refuses to fake a delivery is easier to operate than software that always claims success.
