Pinecrest Academy.

Pinecrest Academy runs five campuses across the Las Vegas Valley, each carrying the same name with its neighbourhood after it: Cadence, Inspirada, Sloan Canyon, St. Rose and Horizon. Every campus takes students through the same curriculum with its own local character and co-curricular focus, and every campus ran its own paperwork, in its own filing cabinets, in its own way.

None of it talked to any of it. A family that moved a child from the Inspirada campus to Cadence did not move a record, they started a new one. A parent who wanted to know whether last term's fee had actually been paid called the campus office and waited for someone to go and look. A head office trying to compare enrollment across all five campuses had to ask each one to send numbers by email, then reconcile five different formats by hand.

None of this showed up as one dramatic failure. It showed up as hours, every week, spent finding things a system should have been able to answer instantly, and it showed up as the specific kind of anxiety that comes from not being sure the number in front of you is the current one.

The brief was not "build us an app". It was narrower and better: reduce the risk of losing things, and make it possible to know what is happening at any campus without phoning it. Visibility and durability, in that order. Everything downstream came out of those two words.

The instinct on a project like this is to start with the feature the client asks for loudest, which is usually finance. We started with School Setup and Student Profiling instead, because finance, attendance, communications and HR only make sense once the system agrees on what a campus is, what a class is, and who a student actually is.

School Setup defines the institution once, centrally: five campuses, eighteen classes spanning primary and secondary, sections within each class, twenty-eight distinct fee types, and the banking relationships each campus needed for deposits. Every other module reads from this. Change a campus's name once, and it is correct everywhere it appears, instead of correct only on the campuses someone remembered to update.

A school with a strong co-curricular sport program has a constraint an ordinary single-campus school does not: sections need to balance not just headcount, but training-squad gender limits and composition, per campus, per class. We built Section Allocation Rules so an admin sets capacity and gender limits once per campus and class, and the system enforces them at enrollment time rather than someone noticing after the fact that a section is over capacity or badly balanced.

Pinecrest also runs an inter-campus house system, used for internal spirit competitions and school events. Redistributing students into houses by hand, evenly, across five campuses, used to be a term-start ritual involving spreadsheets and a lot of manual counting. We built a House Balancer that does it in one action: random assignment, constrained to come out evenly balanced, in seconds instead of a day.

Finance was the module the client had been waiting for since the first conversation, and it is also where the paper process hurt the most: a printed voucher, a trip to the campus or the bank, a payment recorded by hand, and a parent with no way to check any of it without calling.

We built the finance module and the parent app in the same phase, deliberately, because a finance system nobody outside the office can see is only half solved. Automating collection mattered as much as digitising it.

A group of five campuses does not have one fee schedule, it has five, with per-class variation and a steady stream of individual exceptions: a sibling discount, a scholarship student, a mid-year fee adjustment. We built Class Fee Schedule for the default structure, campus by campus and class by class, and Student Overrides for the individual adjustments, so an exception is recorded against the one student it applies to instead of becoming a special case the whole schedule has to account for.

Discount Presets turn the recurring exceptions, the ones the office grants often enough to have a name for, into a one-click template instead of a manually typed adjustment every time.

Single Voucher Issuance and Bulk Voucher Issuance cover the two real cases: printing one fee slip for one family, or generating a term's worth of vouchers for a whole campus in one action. We designed the voucher PDF itself as a real deliverable, not an afterthought: legible on a phone screen, correct when printed, and carrying exactly the reference numbers the bank side needs to reconcile a payment automatically.

The detail that mattered more than the PDF, though, was what happens when a family cannot pay a voucher in full. The old process treated a voucher as one indivisible amount. We built Receive Deposit to accept a partial payment against any voucher and split the remainder into a new voucher automatically, so a family paying in instalments generates a clean, correct paper trail on both sides instead of a manual note explaining the shortfall.

Scheduled payments, where a family arranges to pay on a future date rather than immediately, are tracked as a first-class record with reminders and status, so the office knows what is coming instead of discovering a missed instalment after the fact.

None of the above matters if a parent still has to call the office to find out whether it worked. The parent app puts a family's own fee history, outstanding balance and upcoming payments in front of them directly, and lets them pay from the app rather than a bank counter. The office stopped fielding "did my payment go through" calls, because the parent could already see the answer.

Once fees and profiles were digital, the obvious next gap was that a parent with a question still had exactly one channel: call the campus. We built a communications module that looks, from the parent's side, like a chat, and behaves, from the school's side, like a ticketing system, because those are different requirements and neither one alone was right.

A parent opens a conversation the way they would open any messaging app. Underneath, the message becomes a ticket, categorised by query type (fees, transfers, attendance, general), and routed to whichever staff member actually handles that category at that campus, rather than landing in a shared inbox where it waits for whoever happens to open it. A billing question reaches the finance officer directly. A transfer question reaches the registrar. Nobody re-reads a message to work out whose job it is.

Attendance is the module where "digitally transform" stopped being an abstraction and started meaning hardware. We integrated the platform with ZKTeco biometric terminals installed at every one of the five campuses, for both staff and students, so a punch in or out is a timestamped device event, not a mark a teacher makes from memory at the end of a period.

That single change removed the most common dispute the client had been living with: a staff member insisting they had arrived on time, with no record either way to settle it. The device does not have an opinion. It has a timestamp.

A network running five campuses across one metro area, with a serious co-curricular sport program, does not have a normal timetable. Squads travel for away fixtures, and a class scheduled as in-person on paper is sometimes a class the coach and half the squad are attending from another campus or a game across town. We built that reality into the module rather than treating it as an exception.

The staff app followed the same logic as the parent app: put the record in front of the person it is about. A coach can see their own attendance history and submit a leave request from a phone between training sessions, instead of finding the one person at head office who has the paper form.

HR and payroll came after everything else deliberately. Payroll for a staff of over 110, across five campuses and six departments (teaching, sport and coaching, administration, facilities, wellbeing and enrollment), depends on an attendance record accurate enough to calculate against, and that record did not exist reliably until the biometric integration in the previous phase had been running for a full term.

Building payroll against the old, paper-based attendance data would have meant building it against numbers the client themselves did not fully trust, which produces a payroll system nobody wants to actually run a payroll through.

Pinecrest Academy now runs student profiling, finance, communications, attendance and HR for all five campuses inside one platform, with a parent app and a staff app putting the record in front of the people it concerns instead of behind an office door. The specific fear the client started with, that something would get lost because it only existed on paper in one filing cabinet, is no longer a live risk for anything the platform covers.

The build happened in the order it did because each module needed the one before it to mean anything. Finance needed a student to attach a voucher to. Attendance needed a student and a staff record to attach a punch to. Payroll needed attendance data solid enough to calculate a salary against. That was not a plan drawn up on day one so much as the honest dependency order, phase by phase.