ThinkGrades
Building an AI-native operating system for modern schools.
A production SaaS case study demonstrating how Tectrom handles complex workflows, multi-tenant security, role-specific UX, AI integration, and continuous product development.
98.4% daily attendance logged across 12 grades. 3 fee follow-ups automatically dispatched.
Admin Dashboard • Central institutional hub showing real-time metrics, system health, and AI briefings.
Why we built ThinkGrades.
How an AI chatbot for schools evolved through real customer feedback into a complete production School Operating System.
ThinkGrades didn’t begin as a School ERP. It started with a simple question between two friends: what if school leadership, teachers, parents, and students could ask an intelligent assistant anything about their institution and get an instant, reliable answer?
The original vision was focused entirely on conversation. We set out to build an AI chatbot that could answer operational queries on demand—checking daily attendance percentages, querying exam performance across classes, retrieving outstanding fee statuses, looking up homework assignments, and summarizing student progress feeds.
While building the initial prototype, however, we ran into a fundamental engineering constraint: an AI assistant is only as good as the underlying data behind it.
We quickly discovered that school data was deeply fragmented. Critical records didn’t live in structured databases—they were scattered across ad-hoc Excel spreadsheets, physical paper registers, WhatsApp groups, legacy desktop software, and unwritten staff routines. There was no single, trustworthy source of truth.
To make the chatbot genuinely useful, we had to build the data platform underneath it first. We engineered core modules for student rosters, daily attendance, exam scheduling, multi-part marks entry, tuition fee ledgers, parent communication feeds, and class analytics. Initially, every single one of these modules was built for a single purpose: acting as a clean, reliable data pipeline for the AI.
Then something remarkable happened. Once schools started using the platform, they began requesting complete ERP capabilities. Teachers and administrators didn't just want to query the AI assistant—they wanted to manage their entire daily operations inside the same unified system.
Gradually, ThinkGrades evolved from a lightweight AI chatbot into a full-fledged School Operating System. Today, AI is no longer the entire product. It has become the intelligence layer running across the platform—helping administrators automate workflows, detect academic score variances, generate daily morning briefings, and make better decisions.
“We learned that intelligence cannot substitute for structure. Before an AI assistant can answer complex operational questions, you must first build the operational source of truth underneath it.”
— The ThinkGrades Product Engineering TeamThree Principles That Shaped the Product
AI Starts with Good Data
Intelligence is a direct function of data quality. Without a clean relational database foundation, AI models generate hallucinations rather than trustworthy operational answers.
Build Foundation Before Intelligence
Software must solve core daily utility first. High-frequency workflows like attendance, marksheets, and fee ledgers earn user trust long before AI insights add leverage.
Customer Feedback Shapes Products
Great products are rarely manufactured in isolation. The shift from a simple chatbot to a production School OS happened naturally by listening to how schools actually work.
AI Chatbot for Schools
Conversational assistant answering school queries.
AI Needs Structured Data
Discovered school data was scattered & unorganized.
Built Core Platform
Engineered rosters, attendance, marks & fee ledgers.
Requested Full ERP
Schools requested complete daily operations inside OS.
School Operating System
Production-grade AI-native School Operating System.
This journey shaped how we approach product strategy for institutional clients: rather than building isolated tools, we build unified operating systems. Here is how we turned that origin story into concrete product strategy.
Product at a Glance overview.
A quick overview of the platform we built and continue to evolve.
AI-Native Platform
AI is integrated throughout the platform to assist with insights, reporting, and intelligent workflows rather than existing as a standalone feature.
Multi-Tenant SaaS
A single platform designed to securely support multiple schools through isolated data and role-based access.
Role-Based Experience
Dedicated experiences for administrators, teachers, parents, accountants, and platform administrators.
Parent & Teacher PWAs
Mobile-first Progressive Web Apps built for high-frequency daily workflows.
Academic Operations
Attendance, examinations, marks, report cards, grading, homework, and classroom management in one connected platform.
Financial Management
Fee structures, invoices, payments, receipts, collection tracking, and reporting.
Analytics & Insights
School, class, and student analytics supported by contextual AI-powered insights.
Modern Architecture
Built using Next.js, React, Supabase, PostgreSQL, Tailwind CSS, and deployed on modern cloud infrastructure.
Designed for modern schools.
ThinkGrades combines administration, academics, finance, communication, and AI into one connected operating system, reducing the need for disconnected tools and manual workflows.
From fragmented legacy tools to an active School OS.
Educational institutions often run core daily workflows across spreadsheets, paper registers, legacy ERP software, and disconnected messaging apps.
Traditional School ERP
Legacy Model- ✕ Stores static records in passive database tables
- ✕ Form-heavy administrative entry screens
- ✕ Siloed, disconnected modules requiring re-entry
- ✕ Delayed reporting generated weeks after terms end
ThinkGrades School OS
Active OS Model- ✓ Connected, event-driven academic workflows
- ✓ Role-specific experiences (Admin, Teacher PWA, Parent PWA)
- ✓ Automated mark processing & fee receipts
- ✓ Real-time insights and AI-assisted decisions
Production-grade SaaS modules & real product screenshots.
A deep look into the core workflow modules designed, engineered, and operated within ThinkGrades OS.
School Operations & Roster Management
Centralized administration for academic sessions, sections, subjects, student records, teacher allocations, and multi-tenant role permissions.
Student Management • Centralized student list, profiles, and institutional academic roster setup.
Attendance Dashboard • Daily attendance tracking with heatmaps, reports, and instant alerts.
Daily Attendance & Mobile PWAs
Mobile-first Progressive Web Apps engineered for one-tap classroom marking by teachers and real-time attendance visibility and leave applications for parents.
Exams, Marks Entry & Server PDF Marksheets
Multi-component evaluation supporting theory, oral, and practical weightages with automated calculation engines and headless PDF marksheet generation.
Exam Management • Exam setup & grading scale configuration.
Marks Entry • Multi-component subject score entry grid.
Fee Management & Collection Ledgers
Streamlined tuition fee structures, collection recording, automated invoice generation, outstanding payment tracking, and financial analytics.
Fee Management • Fee collection, digital invoices, and outstanding payment analytics.
Analytics & AI • Performance charts, diagnostic insights, and automated daily AI briefings.
Institutional Analytics & AI Briefings
Real-time performance distribution charts, cohort score trend tracking, and automated AI diagnostic briefings providing actionable recommendations to administrators.
3 Hardest engineering challenges solved.
A detailed look into the architectural trade-offs, security models, and database challenges we solved while engineering ThinkGrades.
Secure Multi-Tenant Row Level Security (RLS)
Multiple institutions share the SaaS application database infrastructure, requiring strict tenant isolation to prevent cross-school data leakage.
Implemented school-based tenancy utilizing PostgreSQL Row-Level Security (RLS) policies in Supabase. Database queries evaluate active school membership context, enforcing tenant isolation at the database layer.
- Row-Level Security (RLS) policies enforced at database layer
- Explicit user-school membership mapping
- Super-admin tenant context switching
Complex Academic Data Modeling
School marksheets vary greatly across institutions and subjects—mixing theory, oral, practical components, and custom grading boundaries.
Engineered a flexible relational schema modeling marks as multi-part assessment components with dynamic weightages rather than hardcoding flat scores.
- Dynamic theory, oral, and practical component structures
- Configurable grading scales (letter grades, GPA, percentages)
- Flexible exam classification and term aggregations
Server-Side Report Card PDF Generation
Generating end-of-term student marksheets requires consistent printable layouts and reliable batch generation across entire classes.
Engineered a dedicated server-side Puppeteer PDF service rendering HTML/CSS templates into downloadable marksheets.
- HTML/CSS template-to-PDF rendering
- Batch marksheet generation queue
- Scalable worker service deployment
System architecture & technology stack.
Clean layered architecture connecting user interfaces, application routes, security boundaries, database tables, and external microservices.
End-to-End Data Pipeline
Frontend & Apps
- Next.js App Router
- React
- Tailwind CSS v4
- Teacher & Parent PWAs
Data & Security Layer
- Supabase PostgreSQL
- Row Level Security (RLS)
- Strict Schema Migrations
AI Layer
- OpenAI API
- Vercel AI SDK
- Structured JSON Output
Infrastructure & APIs
- Vercel Edge
- PDF Generation Service
- Web Push / VAPID
Product decisions & practical AI integration.
Key trade-offs made during product development to reduce friction, alongside practical AI assistance.
Why a dedicated Teacher PWA?
Teachers repeatedly perform a small number of high-frequency actions (attendance, homework, marks entry). Designing a dedicated PWA eliminated desktop clutter and enabled fast mobile completion.
Why simplify the Parent experience?
Parents need clear visibility into their child’s progress and fee receipts—not administrative software. We kept the parent PWA focused entirely on progress feeds and marksheets.
Why role-based interfaces?
Showing only functionality relevant to an active user role reduces cognitive load, speeds up task completion, and limits accidental administrative changes.
Why multi-tenancy from Day 1?
ThinkGrades was designed as a scalable SaaS product rather than separate software installations per school, dramatically simplifying maintenance.
Identifies score variance for early teacher intervention.
Aggregates subject performance overviews for admins.
Assists admins with legacy student data ingestion.
Current status & engineering roadmap.
Clear differentiation between deployed production modules, beta features, and planned engineering initiatives.
Core School OS
Multi-tenant RLS, operations, attendance, marks, fees & PWAs.
API Rate Limiting
Enhanced rate limiting and tenant security auditing.
Async PDF Queue
Worker queue for large-scale batch marksheet generation.
Offline PWA Sync
Background sync for attendance in low-connectivity environments.
What building ThinkGrades taught us.
Three core lessons learned while engineering multi-tenant SaaS platforms.
Complex workflows need simple interfaces.
Complexity should live inside the database and backend architecture—never on the user's screen.
Different users require different experiences.
An administrator desktop dashboard cannot simply be shrunk down and called a mobile app for teachers or parents.
Architecture decisions become product decisions.
Multi-tenancy, Row Level Security, and clean schema design directly determine how fast future features can be built.
Building a multi-tenant SaaS platform
or replacing a fragmented workflow?
Talk directly with the product engineering team behind ThinkGrades. 30-minute technical discussion • No sales handoff.