EduPay

The problem

Tutoring centres run on cash, monthly instalments, and memory. The owner of a mid-sized centre is tracking who paid, who owes, and who needs reminding, across a few hundred students, in a spreadsheet.

I did not have to guess at this. It came from the first owner I spoke to, and he later put it in his own words: before EduPay, reconciling who still owed money was a weekend job. That is the actual product brief. Not "digitise payments", but give the owner back the hours they lose to admin every week.

The second half of the problem is the parents. Reminders were going out by hand over WhatsApp, one message at a time, which meant they went out late or not at all, which meant more money outstanding at the end of the month. And a parent who wants to check what they owe has to ask someone.

The goal

One screen where the owner sees every student's payment status, and a notification path to parents that runs without anyone remembering to trigger it. Everything else was scope to be resisted.

Two constraints shaped every decision. First, the users are not technical, so the system has to work on a phone at the front desk between classes, with no training. Second, this is financial data belonging to someone else's business, so losing it once ends the product.

What I built

• Student database — records, classes, and payment history per student, per centre.
• Payment status tracking — the core view: paid, pending, and overdue at a glance, updating in real time.
• A parent view reached by QR code — months paid and outstanding, per subject, with no app to install and no account to create.
• Automated parent notifications — payment reminders and confirmations through Firebase Cloud Messaging.
• Announcements from the centre, surfaced on the same screen parents already check.
• Class scheduling with timetable integration, so payments are tied to the classes a student actually attends.
• Automated cloud backups — unattended, because no centre has an IT person.
• Payment history reporting for end-of-month reconciliation.

Technical decisions

The three choices that mattered, and what each one cost.

What was hard

Going from one centre to many changed the shape of the problem. A single centre is an app; 31 centres is a multi-tenant system, where the thing that matters most is that no centre can ever see another's students. That pushed the security model out of the client and into Firestore rules, where access is enforced per centre regardless of what the front end asks for.

The second lesson was that onboarding is part of the engineering. Every new centre arrives with an existing spreadsheet and a way of working that does not quite match the last one's, and the product has to absorb that difference without growing a setting for every centre.

Nothing has broken in production. I put that down less to cleverness than to keeping the surface small: the fewer things this system does, the fewer places a centre's data can end up where it should not be.

The result

EduPay is in production with 31 tutoring centres managing 569 students, and took first place at the University of Crete Startup Idea Pitch 2026.

The number I care about is not the student count, though. It is the one in the sentence below, from a centre owner who used to spend his weekends on this.

Before EduPay I tracked payments on spreadsheets and spent every weekend working out who still owed us. Now every student's payment status is on one screen and parents get notified automatically. It's given me back several hours a week I used to lose to admin.