Tuition Centre Fee and Attendance Manager with Parent Reminders

The problem tuition centres have with fees and attendance

In most cities there are small tuition centres and academies with one to ten teachers, a few hundred students and one person handling the office. Fees are tracked in a register or a spreadsheet, attendance on paper, and reminders are sent one WhatsApp message at a time. Families with two or three children get sibling discounts that someone has to remember. At the end of the month the owner does not know who has paid, who paid half, and who has not attended for two weeks.

It matters because fees are the centre's entire income, and parents increasingly expect to see attendance without calling the office.

What already exists and the gap

• eSkooly is a free school management system with fees, attendance and exams, built for schools.
• iEduCentre is tuition-centre software with lesson attendance, fee reminders and a family portal.
• Smart Classes offers a cloud app for coaching institutes with separate tutor, student and parent apps.

These products are feature-heavy and aimed at schools or larger institutes. A centre with 150 students and one office person often abandons them after setup because the fee rules (sibling discounts, one-time admission fee, a scholarship for one child) do not fit, and parents will not install another app. The gap is a small, fast tool whose fee rules match how tuition centres actually charge, and whose parent view is a link that opens in a browser.

What you build

Three roles:

• Owner or office admin: manages batches, students, fee rules and payments; sees the dashboard.
• Teacher: sees today's batches on a phone and marks attendance.
• Parent: opens a private link to see their children's attendance, balance and receipts.

Main flows: enrol a student in batches, generate the month's vouchers on the 1st, record payments as they come in, chase defaulters with pre-filled messages, and close the month.

The technically interesting part

Two things are worth your supervisor's attention.

First, fee rules as data. Instead of hard-coding "second sibling gets 10 percent off", store rules (percentage or fixed discount, applies to which fee type, condition such as sibling order) and evaluate them when generating vouchers. Write unit tests for tricky families: three children in different batches, one on scholarship, one joining mid-month.

Second, idempotent voucher generation. Running "generate March vouchers" twice must not double-charge anyone. Use a unique constraint on student plus month plus fee type, and make the job safe to rerun, the same idempotency pattern Stripe uses for retried API calls. The balance should always be computed from vouchers and payments, never stored as an editable number.

How to evaluate it

• Pilot: run it at one real centre for at least one full fee cycle. Report how many vouchers were generated, collected and chased, and how long month-end took before and after.
• Attendance speed: time five teachers marking a batch of 25; target under 60 seconds each.
• Correctness: a test file of at least 20 family scenarios with expected voucher totals, all passing.
• Parent usability: ask 5 parents to find their child's balance on the private link without help and record success and time.

Suggested plan

1. Week 1: interview the owner and office person at two centres; collect their real fee rules.
2. Weeks 2 to 4: data model, batches, students, enrolment and attendance.
3. Weeks 5 to 8: fee rules, voucher generation, payments, balances and tests.
4. Weeks 9 to 11: reminders, parent link, dashboard.
5. Weeks 12 to 15: pilot for one fee cycle, fix issues, write up results.

Path to a product

Your first customer is a centre where you or a friend teaches. Offer it free for the pilot month, then a small monthly fee per centre with a student limit per tier. Tuition centres talk to each other, so one happy owner is your sales channel. Add a second centre before adding features.

Scope warning

Do not build online classes, video, a learning management system or an exam engine. Do not integrate a payment gateway in version one; record payments made through existing channels. Do not build a native mobile app; a responsive web app is enough.

Learn what you need on Sefism

• Full-stack roadmap : the order to learn front end, back end and database for a project like this.
• Frontend cheat sheet : forms, lists and responsive layouts for the attendance screen.
• Supabase Documentation : auth, row level security and Postgres in one place for a small team.
• Learn Responsive Design : teachers will use this on cheap phones.
• Can follow tutorials but cannot build anything alone : a good first real project for exactly this feeling.

Get help with this idea

This is a good idea for a first real product, as long as the fee rules come from a real centre. Tauseef can help you tighten the scope, choose a stack your team can finish with, and design an evaluation your examiners will respect. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session