The Problem — A Centre Run Entirely by Hand
Before it had a tuition management portal, a UK tuition centre was running every part of its operation by hand. Student records lived in spreadsheets. Invoices were written and sent one at a time. Tutors logged their sessions on paper and handed them in. And parents — who simply wanted to know how many sessions their child had left, whether an invoice had been paid, or when the next lesson was — had no way to find out except by asking, which meant somebody had to stop what they were doing and go and look it up.
None of these were unusual problems alone. What made them serious was that nothing connected: the spreadsheet did not know what the paper timesheets said, and the invoices did not know what the spreadsheet said. There was no single source of truth about a student, only partial ones reconciled by a person who remembered how they fit together — so every new student and tutor added coordination work rather than being absorbed by a system.
That is operational debt that scales badly, and the failure mode is quiet: an invoice that never went out, a session logged twice, a top-up nobody noticed was due. What the client needed was not a better spreadsheet, but one centralised system handling students, tutors, scheduling, and billing together, doing the repetitive parts automatically.
The Solution — A Custom Multi-Role Tuition Management Portal
GrowwStacks built a fully custom, full-stack tuition management portal — not a template or a no-code tool bent into an unfamiliar shape, but a purpose-built application designed around how this centre actually operates. Admins, tutors, parents, and additional staff all sign into the same portal, and the interface changes automatically based on the role signing in. One system, one login, four genuinely different experiences.
That single decision is what makes the rest work. Because everyone is inside the same system rather than emailing each other about it, the data only ever exists once. When a tutor logs a session, that is not a note somebody later transcribes into a spreadsheet — it is the event that decrements the student's remaining sessions, populates the tutor's timesheet, and, when the count runs out, triggers the invoice. The same discipline shaped the custom web app that replaced a no-code workforce stack: build the tool around the real workflow, and manual reconciliation stops existing.
The Admin Dashboard — the Whole Business at a Glance
The admin lands on a single overview of the centre: revenue, active students and tutors, outstanding parent invoices, weekly outgoings, and monthly income and expenditure. It is the view an owner wants on a Monday morning — not a report to be assembled, but a state to be glanced at.
The part that matters is where those numbers come from. They are not typed in, and they are not a periodic export that was accurate only at the moment somebody ran it. QuickBooks Online is integrated directly on the backend and the dashboard reads from it live, so the portal and the accounting system are structurally incapable of disagreeing — there is no reconciliation step because there are not two sets of figures to reconcile.
Student Management and Auto-Decrementing Sessions
Each student record holds what the centre needs to teach and bill them: subjects, exam type and level, class type (individual or group), the linked parent, contact details, sessions booked, and the tutor rate. Parents with more than one child link to a single parent account, so a family is one relationship with several students under it rather than disconnected records that happen to share a surname.
The session count drives everything downstream. When a tutor logs a session the student's remaining count drops automatically, and when it reaches zero it triggers billing. Nobody maintains that number by hand, which means it cannot be forgotten, double-counted, or updated late.
Admins keep the commercial controls: they set the parent rate per student, choose QuickBooks invoicing or cash — cash suppresses the emailed invoice for families who settle in person — and can enable recurring invoices for parents who prefer a fixed weekly schedule to session-triggered billing. The automation handles the default path; the admin decides what the default is for each family.
The Automated Invoicing Engine
This is the core of the system, and the piece that removed the most manual work. When a student's remaining sessions reach zero, an advance invoice for the next block is generated in QuickBooks and emailed to the registered parent automatically. The trigger is not a date or a reminder but the actual exhaustion of the thing the parent paid for — the only moment at which the invoice is genuinely due.
Edge cases stay under human control, which is what stops the automation becoming a liability. When an admin adjusts a session count, the portal presents an explicit choice: raise an invoice for this change, or treat it as a general edit with no invoice. Mechanically those are the same action; commercially they are opposites, so asking at the moment of the edit means a correction never fires a bill.
Ad-hoc invoices cover everything outside the standard cycle: a one-off lesson, or physical products like manuals and workbooks drawn from a built-in inventory. The automation handles the repetitive majority while the manual path stays available for exceptions.
💡 The invoice nobody has to remember — Billing is tied to the thing that actually happens: a tutor logging a session. When the booked sessions run out, the next invoice raises and sends itself. No one watches a spreadsheet for who is due to top up, and no revenue slips because an invoice was forgotten.
Scheduling and Recurring Sessions
Scheduling runs on a colour-coded weekly calendar that filters by tutor, with a legend covering scheduled, completed, cancelled, and no-show sessions alongside tutor availability. Because the states are visually distinct, the shape of a week is readable at a glance — a run of no-shows, or a tutor with an unusually light week, shows up as a pattern rather than something you would only find by reading rows.
Recurring sessions are created once and repeat, so a standing Saturday morning slot is set up a single time instead of being re-entered every week. Available tutor slots surface alongside the calendar, which means bookings do not collide: the information needed to avoid the clash is on screen at the moment of booking rather than in somebody's memory.
Tutor Timesheets, Approvals, and Session Alerts
Tutors log their sessions into a weekly timesheet recording duration, tutor pay, parent bill, and attendance. Each timesheet carries a full status history — draft, then submitted, then approved — giving a clean audit trail of what was claimed, when, and who approved it. For a business where pay and billing both derive from the same logged session, that trail is what makes the numbers defensible.
Admins approve from a single screen rather than chasing paperwork, and can log a session on a tutor's behalf. Session alerts flag any session that should have been logged but was not, closing the most common gap in a manual system: the lesson that happened but never made it onto paper, and therefore never got billed. Overdue-invoice alerts do the same job on the finance side, surfacing unpaid parent invoices by age so the oldest debt is the most visible.
Role-Based Views — Admin, Tutor, Parent, and Staff
The same portal serves every role, and each one sees a system that appears to have been built specifically for them.
Parents
Parents see their invoices — due, paid, and outstanding — plus messaging, shared documents, scheduled and historical sessions, and remaining balances across each of their children. This removed a whole category of interruption from the centre's day: the questions that used to arrive by phone and require somebody to go and check a spreadsheet are now answered by the parent logging in.
Tutors
Tutors see their timesheets and earnings, their allocated students, their own calendar, and student change requests — a reschedule from noon to 10am, for instance — along with messaging, shared documents, and an editable emergency contact. Everything a tutor needs to do their job and get paid correctly is in one place, with no admin acting as a relay.
Additional staff
Exam setters, markers, and other support staff are added with their own roles and rates, so the system covers the whole team, not only the people who teach.
Two things hold this together at the oversight level: messaging is visible to admins, so direct tutor–parent contact does not cost the centre sight of what is being agreed, and every action is captured in an audit log, so who changed what, and when, always has an answer.
Under the Hood
The frontend is a React application. The backend runs on Node.js with Express, and the database is PostgreSQL hosted on Neon. Email is handled through Microsoft 365, so notifications and invoices send from the centre's own domain rather than a third-party address parents would not recognise.
Automation and integrations run through n8n, self-hosted on a VPS, with every invoice, notification, QuickBooks sync, and outbound email triggered automatically through webhooks fired from the portal into those workflows. Keeping the automation layer separate is deliberate: billing rules and notification logic are the parts most likely to change, and here they can be adjusted in a workflow without redeploying the application around them.
The result is a system that quietly does the work a full team used to coordinate by hand. That same event-driven pattern — something happens, a webhook fires, the follow-up handles itself — is what drives the automated sales follow-up engine, and the multi-role structure mirrors the shared WhatsApp team inbox, where several people work one system without treading on each other.
The Right Fit — and When It Isn't
This suits tuition centres, coaching businesses, and service businesses running scheduling, billing, and multi-party coordination by hand — organisations that have outgrown spreadsheets and need role-based access for staff and customers alike. The signal is usually not that the current system is broken, but that keeping it working has become somebody's job.
It is less suited to a single tutor with a handful of students, where a simple calendar and an off-the-shelf invoicing app already cover the need. It is also a poor fit for businesses whose billing rules change so frequently that a fixed automated engine would need constant rework — there, the automation becomes the maintenance burden it was meant to remove. Where the rules are stable and the volume is real, though, a portal like this turns a full-team workload into something that runs itself.