Skip to content
Multi-tenant systems

One Attendance Model for Multiple Biometric Vendors

A multi-tenant operations platform for coaching institutes that connects academic structure, people, attendance, finance, biometric devices, and SMS workflows.

Written by Montasim
3 min read

The visible feature was only the surface

Coaching institutes often split student records, class structures, attendance devices, fee collection, expenses, and communication across disconnected tools. Operators need one system without allowing one organization to see or mutate another organization’s data.

The system also had to respect concrete constraints. Every academic and financial workflow must preserve organization isolation and granular role permissions. Students and teachers share physical biometric devices even though they have different domain records and responsibilities. Payments and other critical business records require audit history and recoverable soft deletion rather than destructive removal. Bangla SMS campaigns and attendance alerts must respect provider limits, scheduling, batching, and delivery state.

My role covered client platform architecture and full-stack engineering, with responsibility for multi-tenant rbac, academic operations, finance, biometric integration, and messaging infrastructure.

I turned the constraints into boundaries

Next.js App Router combines server-rendered reads with interactive client workflows, Prisma models PostgreSQL tenancy and audit state, Supabase provides database and identity infrastructure, and adapter boundaries isolate biometric devices and SMS providers.

Tenant identity and role checks are applied at server boundaries so client state cannot broaden access to academic or financial records.

Steller and Tipsoi integrations implement one internal device contract, allowing attendance workflows to remain stable when hardware protocols differ.

Students, teachers, payments, and related business records retain deletion reasons and history instead of disappearing through irreversible mutations.

Server Components handle initial data and access boundaries while TanStack Query supports high-interaction screens without turning the whole application into client state.

The key decision: Make organization scope part of every protected query.

The implementation had to prove the model

I delivered the work across the full path: Designed the multi-tenant organization, role, academic, finance, attendance, and audit data model. Built management workflows for students, teachers, class sections, enrollment, fees, payments, expenses, and administrative roles. Defined the encrypted biometric credential boundary, shared device identity strategy, polling workflow, and vendor adapter model. Implemented the SMS scheduling and batch-delivery architecture for attendance notifications and marketing outreach.

The result is concrete: Institute operators can manage academic, attendance, financial, and communication work from one tenant-aware platform. Granular roles separate platform administration, organization administration, finance, and academic coordination. Multiple biometric device vendors can feed one attendance model without leaking vendor-specific behavior into core workflows. Financial corrections and record removal retain audit evidence instead of erasing operational history.

The senior engineering lesson was that solving the visible workflow is only half the job. The architecture must also make constraints, failure modes, evidence, and ownership explicit enough for the next change to remain safe.

Working through a similar challenge?

Share your context, constraints, and timeline to start a focused conversation.

Leave a reply

Respond to the article or continue the discussion.

Ctrl + Enter to post

Your email stays private. Comments are stored securely.