One system for enrollment, fee cycles, attendance, exams and parent communication — for academies that have outgrown registers and Excel.
public/images/solutions/coaching-center-dashboard.pngOwner dashboard — collections against target, attendance by batch, and the defaulter queue, all as of this morning.
Who it's for
Tuition academies, test-prep centres and subject institutes running multiple batches across one or more branches. The point where this stops being an Excel problem is usually around 150 students, three teachers, and the first month you cannot say with confidence who has paid.
The problem
In the words operators use, not the words software vendors use.
Fees are recorded in a register, receipts in a book, and discounts in someone's memory. Reconciling them means cross-checking three sources, so it happens monthly at best — which is exactly how three months of unpaid fees go unnoticed.
Registers are marked in class and then never aggregated. When a parent asks how often their child attended in October, the honest answer is that finding out would take twenty minutes of flipping pages.
Marks are collected on loose sheets, typed into a spreadsheet, weighted by a formula that lives in one teacher's head, and formatted into cards the night before they go out. Every term. With arithmetic errors every term.
Per-session, per-student, and fixed-salary teachers all get computed differently, usually by the owner, usually late at night, usually with a disagreement afterwards.
Revenue per batch is knowable in principle. In practice, with teacher cost, room utilisation and discounts spread across different records, almost no centre can tell you which of its batches is subsidising the others.
What it does
Feature lists organised by technical module tell you nothing about whether the software fits your team. These are grouped by the person who lives in them.
Admission through to alumni status as one record, so a student's fee history, attendance and results stay attached to them across batches and years.
Batches are the unit everything else hangs off — fees, attendance, teachers, rooms and results all resolve through the batch.
Marked once, in class, on whatever device is at hand — then available everywhere without anyone re-entering it.
The part that pays for the system. Fee structures are defined once per batch and then generate invoices on a schedule, with the messy real-world cases handled explicitly rather than as exceptions.
Marks entered once by the teacher who set the paper, then computed and formatted by rules that live in the system rather than in a spreadsheet formula.
Teacher compensation is computed from the same attendance and batch data the rest of the system already holds, so payout month-end stops being a reconstruction job.
The single highest-value feature for retention, and the one that most reduces inbound calls to the front desk.
The reports an owner actually asks for, available without exporting anything.
Screenshots
Every screenshot uses generated demo data. No real customer, student or member record appears anywhere on this site.
public/images/solutions/coaching-fee-ledger.pngA student ledger with a partial payment and a carried-forward balance. Every line is traceable to a receipt — this is the screen that ends the "but I paid last month" conversation.
public/images/solutions/coaching-attendance.pngRoll call as a teacher sees it on a phone. Three states rather than a tick, because "late" and "absent" have different consequences for the parent alert.
public/images/solutions/coaching-defaulters.pngAgeing defaulter report. The 90-day bucket is the one that matters — those are the students who have usually already stopped attending.
public/images/solutions/coaching-result-card.pngA generated result card. The weighting rules that produce the aggregate are configuration, not a spreadsheet formula, so they are identical for every student in the batch.
public/images/solutions/coaching-batch-profitability.pngBatch profitability. Most centres discover at least one batch running at a loss the first time they see this view.
Roles & permissions
Publishing this table is unusual. It is also the fastest way to show that the system was designed for a real deployment rather than for a demo.
Roles are enforced server-side on every endpoint, not by hiding buttons in the UI. In multi-branch deployments every role is additionally scoped to the branches the user is assigned to.
| Capability | Owner All branches | Admin Assigned branch | Teacher Own batches | Accountant Assigned branch | Parent Own children |
|---|---|---|---|---|---|
| Student records | Owner: Full | Admin: Full | Teacher: View | Accountant: View | Parent: Own |
| Enrollment and batch transfer | Owner: Full | Admin: Full | Teacher: — | Accountant: — | Parent: — |
| Timetable and batch setup | Owner: Full | Admin: Edit | Teacher: View | Accountant: — | Parent: View |
| Mark attendance | Owner: Full | Admin: Edit | Teacher: Own | Accountant: — | Parent: — |
| Fee structure and discounts | Owner: Full | Admin: View | Teacher: — | Accountant: Edit | Parent: — |
| Record payments and issue receipts | Owner: Full | Admin: Edit | Teacher: — | Accountant: Full | Parent: — |
| Waive or write off a balance | Owner: Approve | Admin: — | Teacher: — | Accountant: — | Parent: — |
| Enter exam marks | Owner: Full | Admin: Edit | Teacher: Own | Accountant: — | Parent: — |
| Publish results | Owner: Full | Admin: Approve | Teacher: — | Accountant: — | Parent: — |
| Teacher payout statements | Owner: Full | Admin: — | Teacher: Own | Accountant: View | Parent: — |
| Financial reports | Owner: Full | Admin: View | Teacher: — | Accountant: Full | Parent: — |
| Send bulk announcements | Owner: Full | Admin: Edit | Teacher: — | Accountant: — | Parent: — |
| User and role management | Owner: Full | Admin: — | Teacher: — | Accountant: — | Parent: — |
| Audit log | Owner: View | Admin: — | Teacher: — | Accountant: — | Parent: — |
Technical architecture
Skip this section if you are not technical — nothing later depends on it.
An ASP.NET Core API over PostgreSQL, with a React admin console and a deliberately minimal parent portal. Scheduled work — invoice generation, reminders, digests — runs on a background worker rather than in request threads, because fee-cycle runs are the one job that must complete whether or not anyone has the site open.
Clients
Application
Async work
Data & integrations
The team's deepest language, and a runtime that handles the scheduled and transactional work here without ceremony.
Money and attendance are relational problems. Transactional integrity matters more than schema flexibility.
Dense data grids and fast filtering, which is 80% of what an administrator does all day.
Parents open it on old Android phones over patchy mobile data. It must load in under two seconds on a 3G connection.
Persistent, retryable, and inspectable. A failed fee run must be visible and re-runnable, not silently lost.
WhatsApp is where parents actually read messages. SMS is the fallback when a number is not on WhatsApp.
Parents will not remember a password. Phone-number OTP is the only login they reliably complete.
Single-tenant by default — one database per centre, deployed to a small VM or a managed container host. Multi-branch chains run as one deployment with branch-scoped row-level access. Nightly encrypted backups with a documented restore drill.
Notable engineering decisions
This is the section that separates a system somebody built from a system somebody screenshotted.
The naive implementation of monthly fees is a scheduled job that inserts an invoice for every active student on the first of the month. It survives about two weeks of real use.
The cases that break it are all ordinary: a student joins on the 18th; a student leaves mid-cycle and wants the unused portion back; a batch’s fee changes in March but the student is on a discount agreed in January; a family pays three months in advance and then one sibling drops out.
What we settled on is treating the fee structure as a dated, versioned agreement between a student and a batch, not as a number on the batch. Invoice generation reads the version that was in force for the period being billed, which means:
That last point matters more than it sounds. The most common request from centres that have used other software is not a feature — it is the ability to explain why a number is what it is, two months after the fact, to a parent standing at the counter.
Chains want consolidated reporting; branches want their own data. Running a separate
database per branch gives clean isolation and makes cross-branch reporting painful.
Running one shared schema with a BranchId column gives easy reporting and one bad
WHERE clause away from a data leak.
We use the shared schema, but the branch filter is not left to the developer writing the query. It is applied by a global query filter at the ORM level, driven by the branch claims on the authenticated user, so a query that forgets to filter returns nothing rather than everything. Bypassing it requires an explicit, named call that only the consolidated reporting layer uses — and that call is what the audit log watches most closely.
This is the pattern we would use again at this scale. Below roughly a hundred branches, the operational simplicity of one database is worth more than the theoretical isolation of many, provided the filter is enforced somewhere a developer cannot forget it.
Sending a WhatsApp message is one API call. Being able to answer “did the parent get the fee reminder?” three weeks later is a different piece of engineering.
Every outbound message is a row in an outbox table before it is an API call. A worker picks it up, sends it, and writes the provider’s message ID back. Delivery webhooks update the same row. Failures retry with backoff, and messages that exhaust their retries land in a visible queue rather than disappearing.
The result is that a front-desk administrator can look at a student and see that the fee reminder was delivered on the 3rd, read on the 4th, and that the absence alert on the 11th failed because the number is not registered on WhatsApp — which is actionable, and which a fire-and-forget integration cannot tell them.
The same outbox also makes the system safe to re-run. If a fee-generation job partially completes and is retried, parents do not receive duplicate reminders, because the outbox row is keyed to the invoice and the period rather than to the job run.
A demo environment with seeded data is available on request during a call. It resets nightly, and every name, phone number and fee record in it is generated — no real student data exists in any demo or screenshot.
Most centres need the fee model adjusted — that is where every academy differs, and it is deliberately the most configurable part of the system. If your fee rules fit what is already built, deployment is mostly data migration and training.
FAQ
Yes. Branches share one deployment, with every user scoped to the branches they are assigned to and the owner seeing consolidated reporting across all of them. Fee structures, discounts and grading schemes can be shared or set per branch.
It gets migrated. We import from Excel or CSV as part of go-live, including outstanding balances, so the system starts with correct opening figures rather than a clean slate you have to reconcile against.
No. Notifications arrive on WhatsApp or SMS, and the parent portal is a web page that logs in with a phone-number OTP. Asking parents to install and maintain an app is the fastest way to make a parent portal go unused.
Usually. Most devices either expose an SDK or can export attendance logs to a folder, and we integrate with whichever your device supports. We confirm the exact model during discovery before committing to it.
You do. Full source, in your repository, with deployment documentation. There is no licence that expires and no vendor lock-in on the data.
Related
Operational systems built around how your business actually works — not around what an off-the-shelf product assumes.
Learn moreSenior engineers embedded with your team, at your cadence — with the person who writes the code being the person you talk to.
Learn moreWe will show you the working system, tell you honestly what would need changing for your operation, and give you a range before you commit to anything.
30 minutes · We reply within one business day.