From scattered tools to one operating platform
A performing-arts school running on QuickBooks, Membermeister, spreadsheets and separate operational tools. I built one secure platform around how the organisation actually works.
The situation
The Arts Hub carried QuickBooks, Membermeister and a scattering of separate products and spreadsheets for staff details, timesheets, tasks, payment tracking, bank categorisation, classes, attendance, member records and family invoicing. Each subscription was defensible on its own. Together they created duplicated records, manual re-keying and no single operational view.
Sensitive data ran through those workflows, including children’s medical and emergency information. The incumbent member platform would not add multi-factor authentication when asked. The problem was no longer just software cost. It was fragmented ownership, weak assurance and an operating model shaped by the limitations of rented tools.
What I built
Not a collection of screens and forms. A working operating platform spanning the staff, family and financial sides of the organisation:
Identity and roles
Invite-only staff access, restricted Administrator and Teacher roles, a separate family portal, and private signed customer actions without public user-account registration.
Families and members
Families, multiple contacts, students, consent, emergency details, reversible archiving, privacy-safe histories, data-review workflows and controlled migration tools.
Classes and attendance
Terms, classes, enrolments, explicit sessions, teacher assignment, room conflict checking, private lessons, touch-first registers, attendance and printable emergency registers.
Communications
Individual, class and whole-school messaging, reusable templates, delivery history, family-portal records and deliberately consent-gated service SMS.
Invoicing and payments
Preview-first bulk invoicing, sibling reductions, scholarships, payment schedules, signed invoices, reminders, card and Direct Debit checkout, and exact bank-transfer matching.
Team operations and payroll
Shared tasks, repeatable timesheets, separated approval and payment duties, expenses, private staff conversations, Manx payroll registers, payslips and tax working papers.
Banking and reporting
Encrypted bank-statement imports, human-reviewed categorisation, transaction reconciliation, accounting-period controls, tax reports, receivables, attendance and formula-safe exports.
Operations and recovery
Native monitored deployment, encrypted off-site recovery, application-consistent database backups, controlled maintenance and health alerts across the supporting services.
Built around the work
Business analysis came first. I mapped what staff actually did, where the source systems disagreed and which decisions still needed a person. The platform then evolved through real staff feedback: mobile registers became touch-first, family records gained multiple contact roles, invoicing grew reviewable discounts and payment schedules, and payroll separated approval from recording payment.
The result is a Laravel monolith with SQLite, deployed natively behind Cloudflare’s access boundary. Staff operations remain private. Registration, family access and customer invoice actions use separate restricted public routes. Google Workspace handles branded email; hosted payment providers handle bank and card details, which the platform never stores.
Claude helped analyse the existing accounts and sharpen the operating model. Codex did engineering work across code, migrations, tests, documentation and deployment. AI accelerated delivery. It did not make the decisions that mattered: what to hold, what never to automate, what to encrypt, and what a person must review before it counts.
Privacy by design
Sensitive personal, medical, tax, payment and support fields are encrypted. Teacher access is limited to assigned classes and personal workflows. Bulk actions preview before they commit. Archiving is reversible. Audit records identify the action and changed fields without copying sensitive before-and-after values into history.
The same boundary applies to money. Customer payment details stay with the payment provider. A checkout is not treated as paid until the matching provider resource is retrieved and verified. The platform can reconcile banking evidence and prepare payroll, but it never initiates a Barclays payment.
The outcome
199 families and 257 students were brought into a controlled operating model. All 2,460 historic invoice rows were reconciled against the new family records: 2,139 matched exactly one family, while 321 were deliberately left unmatched rather than forced into the wrong account. That is a better result than pretending imperfect source data was clean.
Five rented tools were reduced to one platform the organisation controls. The same system now supports daily administration, classes, staff and family workflows, communications, billing, payroll preparation, banking review and management reporting. It is protected by strong access controls, encrypted sensitive data, off-site recovery and operational monitoring.
The trade-offs
A focused platform creates ownership as well as freedom. It needs backups, monitoring, documentation, careful releases and honest limits. Historical data still needs reconciliation. Payment and statutory decisions still need human review. Some workflows remain intentionally manual because automating them would create more risk than value.
Established products are still the right call most of the time. Here, the operational fit, security boundary and cost of fragmented work justified building the smaller system properly.
The original build write-up goes deeper on the judgement behind replacing poor-fit software.
Start a conversation