The hard part of running a swim school is the money.
Enrolments live on a whiteboard. Attendance lives in a spreadsheet. Payments live in a shoebox of receipts, a bank feed and someone's memory. That works, right up until a swimmer moves from Turtles to Stingrays halfway through a block, takes three weeks off in July, and their guardian asks what they owe.
Answering that question is where generic booking software gets it wrong. Pro rata charges, credits, level changes mid-block, holidays, makeup lessons: each one is a small money decision, and any of them going astray costs a family's trust and a front desk its afternoon. So we started there. SwimPilot was built billing-first. The ledger came before the timetable, and everything since has been fitted around it.
Two facts about the software, not about how many people use it.
SwimPilot is early, so there are no adoption numbers here and there will not be until they are real. What we can tell you is how the system is built and where your school's records physically live.
Databases, backups and uploaded files all run in AWS's Sydney region, ap-southeast-2. Your school's data stays in Australia and is handled under the Australian Privacy Act.
Every charge, credit and payment is kept for seven years. A correction is a new reversing entry rather than an edit, so what actually happened reads back years later exactly as it was recorded.
We built SwimPilot billing-first because billing is the part that goes wrong quietly. Taking a booking is easy. Knowing exactly what a family has paid for is not, and it gets harder after a level change, or when the pool closes for a week and every date has to move. So we decided the money would be an append-only ledger before we decided anything else. If SwimPilot ever loses value a family has already paid for, we have built it wrong.
The SwimPilot team
Studio Parallel · Australia
Six rules the product is built on.
These are decisions, not aspirations. They are enforced by the database and the code around it, not by anyone remembering to follow them.
Money is corrected, never edited
A mistake becomes a new reversing entry sitting beside the original, so you can always see what was charged, what was fixed, who fixed it and when. Nothing is quietly overwritten. There is no reconciliation job, because there is nothing to drift.
Paid-through dates are worked out, not stored
A family's paid-through date is derived from what they have actually paid for, every time it is shown. Approve a holiday, or close the pool for a week, and every affected date moves on its own. Nothing to re-enter, nothing to fall out of step.
Payments land in your bank, not ours
You connect your own Stripe account and stay the merchant of record, so families pay your school directly. SwimPilot takes no percentage of what they pay, and the only deduction is Stripe's own fee.
One school can never reach another school's data
Every query is scoped to a single school in the application, then checked again by Postgres row-level security in the database itself. Two independent locks, so a mistake in one cannot open the other.
Medical details are encrypted and shown on a need-to-know basis
A child's medical information is encrypted at rest with a key belonging to your school alone. Poolside, a teacher sees a safety alert against the name on the roll. The full notes stay with the admins who need them.
The AI assistant is off by default
A school that never enables it sees nothing at all. Switched on, it goes through the same permissions and the same checks an admin does, so it can do nothing an admin could not do. Anything that moves money or changes an enrolment comes back as a preview for a person to approve.
See what it does with your school's week.
Create your school in under a minute, then fill it with demo data and try a level change, a holiday and a term of billing before you import anything real. If you would rather ask a question first, email us.