3 min read
Institute ERP
From first enquiry to teacher payout.
An ERP for a coaching institute on Frappe and ERPNext. Enquiries, enrolment, instalment fees, class scheduling, attendance and visiting-faculty pay all live in one system, on top of ERPNext's accounting engine.
- Web
- Python
- Frappe
- ERPNext
- MariaDB
- Redis
- 32
- document types in a custom academic layer
- 10
- reports
- 1-click
- fee collection posts the full accounting trail
What it does
No lead goes cold
Every enquiry creates a follow-up. One follow-up engine serves admissions, payment chasing and referrals, with a board for what is overdue, due today or due this week.
Fees in instalments
Plans split into one, two or three instalments with payment links and reminders. The form refuses to save if the instalments do not add up.
Accounting without the paperwork
Collecting a fee posts the order, receipt, invoice and GST in one step, so front-desk staff never touch accounting documents.
Referral discounts you can audit
Each discount is recorded against the person who referred.
Visiting faculty paid from rate cards
Timesheets are approved against each teacher's agreed activities and rates, then invoiced and paid in parts. Teachers see only their own hours and pay.
Fair attendance
Attendance counts from a student's joining date, so mid-batch joiners are not penalised.
Schedules without clashes
Scheduling rejects overlapping classes for a batch.
Staff task dashboard
KPIs, a leaderboard, Excel export and a monthly emailed summary.
Under the hood, briefly
- An academic layer on an accounting engine. Students automatically become customers and teachers become suppliers, so ERPNext’s accounting does the heavy lifting.
- Evidence-based documentation. The codebase was reverse-engineered into a spec in which every statement is labelled with its evidence, plus a defect register and a hardening plan for reuse across institutes.
The results incident
The institute sends each student a monthly report of the tests they took. The send went out in a single batch: 50–70k WhatsApp messages at once, each with a link to the student’s result PDF.
- What broke. Each link hit an endpoint that rendered the PDF on request, and each PDF cost one to two seconds of SQL queries and API calls. At normal traffic that was fine. With everyone clicking within the same hour, the workers were exhausted and the site went down.
- Finding the cause. The messaging vendor blamed bandwidth. The server was upgraded and it still failed, which ruled out raw capacity. I measured the per-PDF cost on a local bench and confirmed that synchronous rendering alone was enough to exhaust the workers.
- Containment. The site went into maintenance mode to stop the overload.
- The fix, overnight. Rendering 50k PDFs one after another would take 13–26 hours, so I raised the long-queue worker count and queued one background job per student. Each job renders the PDF in memory, uploads it to S3 and stores a pre-signed link on the student’s record. The result link now only looks up that record and redirects, so the server never renders on click. Downloads worked the next morning.
- What I’d do before the next blast. Precompute expensive output before a mass send, keep heavy work in background jobs, and roll out in stages (say a thousand first) or load-test the endpoint first.
Next project
Notification Router →