MULTI-BRANCH TUITION OPS

Run every branch from one console.

Students, teachers, batch scheduling and the entire money workflow — multi-tender payments, allocations, discounts and receipts — with role-based access enforced down to the database row.

Built on Next.js 15 / React 19 / Supabase + RLS
app.centrely.io/dashboard
Dashboard
Camden Branch · Super Admin
ALL BRANCHES
STUDENTS
1,284
ACTIVE BATCHES
96
THIS MONTH'S COLLECTION
+12.4%
£84,920
OVERDUE PAYMENTS
AK
Aisha Khan
26-CAM-0431
£240 · 8d
RP
Rohan Patel
26-CAM-0388
£120 · 3d
Payment recorded
Receipt #INV-20418 · £200
16
Postgres tables · RLS
45/47
Pages are Server Components
23
Server-action modules
4
Tender types per payment
// EXPLORE THE SYSTEM

Three pillars, one type-safe system.

Pick a pillar to see how Centrely runs a multi-branch coaching business — from enrolment to receipt to row-level access.

Everything a coaching centre runs on

One data-heavy internal tool, no separate API layer — every domain from enrolment to receipt in the same system.

Students & teachers

Auto-generated student IDs, teacher profiles with subject specialisations and availability.

Batch scheduling

Flexible batches with weekly time slots, per-batch calendars and attendance tracking.

Enrolments

Regular and holiday-course enrolments, with multiple enrolments per subject supported.

Pricing & discounts

Year/class and subject-level pricing, plus per-student recurring or one-off discounts.

Reporting suite

Collection, enrolment, workload, utilisation, credit-due, overdue and transaction reports.

Progress & audit

Printable report cards per batch, and database triggers that log every data change.

The payments engine is the heart of the app

Hourly-rate pricing by year, class and study mode. A full invoice → allocation model with proportional discounts, grace authorisation, overdue flows — and a printable receipt at the end.

Multi-tender — cash, bank, card & direct debit in one payment
Proportional discount application across allocations
Money math unit-tested — proration, stacking, DST-safe dates
Record payment
INV-20418
INVOICE › ALLOCATE › TENDER › RECEIPT
Cash
£120.00
Bank transfer
£80.00
Subtotal £220.00
Sibling discount · 10% −£20.00
Total paid £200.00

One super-admin over every branch, enforced down to the row

Branch admins are scoped to their own branch in middleware, inside every server action, and by Postgres Row Level Security — defence in depth, not a single gate.

CAPABILITY
SUPER
BRANCH
Branch access
All
Own
Manage pricing & discounts
Validate electronic payments
Validate cash payments
Manage admin users
Run reports
DEFENCE IN DEPTH — every request passes all three
01
Middleware
Refreshes the session and gates every route.
02
Server action
Re-verifies role via verify_admin_user — never trusts the client.
03
Postgres RLS
Row Level Security — the final backstop, safe even if a check is missed.
// 04 — UNDER THE HOOD

A server-first architecture, no bespoke API layer.

Pages fetch data by calling server-action functions directly. Every action returns a uniform { success, data | error } contract, with auth and role checks inside — not just at the route.

Next.js 15 · App Router React 19 TypeScript · strict Supabase · Postgres + RLS Tailwind v4 shadcn/ui · Radix TanStack Table Recharts react-hook-form + Zod Vitest Sentry Next.js 15 · App Router React 19 TypeScript · strict Supabase · Postgres + RLS Tailwind v4 shadcn/ui · Radix TanStack Table Recharts react-hook-form + Zod Vitest Sentry

Server-first

Interactivity isolated to client components; pages stay thin and data-driven.

Type-safe end-to-end

DB types generated from the live schema; forms and actions infer from one source.

Tested where it counts

Money math and access control unit-tested — pure logic factored out of actions.

// LET'S TALK

See Centrely running your branches.

A 20-minute walkthrough of the dashboard, the payments flow, and the role model — with your own branch structure.