Case study · Booking platform
Youth Aquatics
A swim-school platform we inherited three-quarters built — finished, hardened, scaled from one city to two, and handed back with every account in the client’s own name.
75%
built when we took it over
4 roles
parents, instructors, pool partners, admins
2 markets
Boston and Austin, one codebase

The challenge
Youth Aquatics sells private, one-to-one swim instruction inside luxury hotel and private residential pools — a genuinely good read on an underused asset. Nobody is fighting over pool time at 10am on a Tuesday.
The software was the problem. A previous developer had taken the platform to roughly 75% and stalled. The booking flow and calendar were unfinished, mobile responsiveness barely existed, and — the part that mattered most — the Firebase project, the SendGrid account and the Twilio number were all still owned by someone outside the company. Expansion into a second city sat behind all of it.
The approach
Two jobs at once: finish the product, and give the client control of it. On ownership we moved Firebase into their hands, transferred the FlutterFlow project once they took a paid tier, stood up fresh SendGrid and Twilio accounts on their own domain, and mirrored the codebase to GitHub so the app no longer lived in exactly one place.
On the product, the booking flow came first. The original made parents click day by day to discover whether anything was available. We replaced it with an Airbnb-style list: city pre-selected from onboarding, a date range instead of a single day, and lesson type inferred from the swimmers you pick — one swimmer is a private lesson, two make it semi-private, capped at a three-year age gap. Age gating computes in months rather than rounded years, so infants land in the right lesson types instead of the nearest one.
The hardest bug was quieter. Instructor availability was stored as a DateTime and attached to the lesson, which broke every time Austin and Boston disagreed about what “9am” meant, and made recurring bookings stack onto a single date. We re-modelled availability as minutes from midnight, tied to the location rather than the lesson. Both classes of bug disappeared, and they stayed gone.
Then the parts a live operation actually needs:
- A manual approval gate on instructor and admin sign-ups — the original onboarding link granted immediate access to records about minors.
- A full notification matrix across push, email and SMS, including the A2P 10DLC registration and the explicitly unchecked consent checkbox Twilio requires before it will carry a single message.
- Off-site lessons at a family’s own pool, with address capture and a notes field for gate codes and parking.
- A post-lesson micro-survey two hours after class, and instructor swim reports as the signal that a lesson actually happened.
- A pool-partner tier, so a hotel can block its own hours for swim meets and maintenance and have that override every instructor calendar at that location.
The outcome
The platform is live on Google Play and on the web at swim.youthaquatics.com, running Boston and Austin off one codebase, serving four distinct user types with their own dashboards, permissions and alerts. Youth Aquatics owns every account in the stack — Firebase, FlutterFlow, SendGrid, Twilio, the repository. That was the part the previous arrangement got wrong, and it’s the part that makes the rest of it theirs.
Try Youth Aquatics: Web app · Android · youthaquatics.com
Inherited a half-finished app?
If a previous developer left you at 75% — or holding a product whose accounts aren’t in your name — that’s a job we’ve done more than once.
More work
Related case studies
- Piki — three coordinated apps and a credit-based booking economy
- Nani-Care — a four-language, six-vertical childcare marketplace
- My House Fax — four property data sources stitched into one defensible report
Building something in this territory? See how we approach MVP app development — or get a realistic schedule for your own project from the free app development timeline estimator, in about two minutes.