The Problem
Swimiss is a freediving academy that also teaches swimming, scuba, and other disciplines. Running it day to day touched a dozen disconnected pieces, who enrolled, who paid, who showed up, which instructor ran which session, what skills a student had ticked off, which affiliate brought a lead in, and who was owed commission.
The whole operation ran on Excel. Not one sheet but many, thousands of rows of students, sessions, payments, and commissions, each sheet maintained by hand and none of them agreeing with the others. A student existed in one sheet, their payments in another, their course progress in a third, and the affiliate who referred them in a fourth, with no shared key tying any of it together. The data was massive and it was disconnected, which meant every answer required someone to cross reference by eye and hope nothing had been mistyped or left stale.
Worse, the data was not even in one tool. It was scattered everywhere, spreadsheets in Google Drive, decisions and confirmations buried in WhatsApp threads, payment proofs sitting in chat images, schedules in one person’s head. The single source of truth for a given fact depended on who you asked and which app they happened to open it in.
None of it lived in one place. Enrollment, scheduling, instructor records, affiliate tracking, and student progress were spread across spreadsheets, drive folders, chat threads, and memory. The team could not answer simple questions confidently. Where is this student in their course? Has this lead been followed up? Who earned commission this month, and have we paid them? Every one of those questions meant opening three files, scrolling a chat history, and reconciling it all in your head.
The academy needed one system that the whole operation could run on, and a mobile app to carry the student and instructor journey out of the office and onto the poolside and the dive deck.
The Insight
A multi discipline academy is not one product. It is four audiences with four different jobs, all touching the same student.
- The team needs to manage students, sessions, bookings, enrollment follow up, and the affiliate program end to end
- The affiliate needs to bring in leads, see where those leads came from, and trust that commission is tracked and paid
- The student needs to enroll, see their course journey, and understand where they are and what to improve
- The instructor needs to run today’s session, record performance, and tick off the requirements a course demands
The mistake would have been building one generic dashboard. The real design was four surfaces over one source of truth, each person seeing only the job in front of them, all reading and writing the same underlying data.
The Approach
The system was built as a monorepo with three independently deployed apps, a public marketing site, a member dashboard that carries student, instructor, and admin surfaces, and a FastAPI backend on Postgres. Alongside it, a mobile app to facilitate the student journey and let instructors keep up with student progress on the poolside.
A few decisions shaped everything that followed.
One login model, capabilities looked up live. Web and mobile share a single no roles token. What a person can do is never baked into the token, it is read per request from sidecar tables. A student row makes you a student, an instructor row makes you an instructor, an affiliate row makes you an affiliate. The mobile app reads your capabilities after login and renders the student or instructor view accordingly. There is no separate staff login and no token escalation, which means access can be granted or revoked instantly without anyone logging out.
Money is a ledger, never a stored number. Wallet balances, payments, and commission are all derived from append only ledgers rather than mutable balance fields. A payment is a posted movement, a refund is a new row, nothing is ever edited in place. The instinct to “fix the balance” is always wrong here, you fix the ledger entry. This kept the financial picture auditable from day one.
Affiliate work is first class, not a bolt on. An affiliate gets a referral code, every click on a course link is recorded as an append only event, and attribution is snapshotted at the moment a lead converts. Commission is frozen once earned, plan edits after the fact never rewrite history. The team sees who earned what and who is due a payout, the affiliate sees their own leads with full detail so they can follow up over WhatsApp.
The Build
The platform covers the full operating surface of the academy.
- Enrollment and follow up, students enroll in any course, and the team tracks leads from first touch through to a paid, active enrollment, with payment links, deposits, and balances handled through the payment gateway
- Sessions and bookings, scheduled sessions any active student can book, paid by voucher or cash, with manual booking close and capacity handled per slot
- Instructor flow, instructors run the current session, mark attendance, record performance, and tick the course objectives a student must clear, with a short post session edit window to fix mistakes
- Student journey, students see their course progress live, which objectives are done and what is left, so they understand where they are and what to improve
- Affiliate management, referral codes, click insights, commission tracking, and payout visibility, so the team understands who earned commission and who needs paying
- The mobile app, carrying the student journey and instructor progress recording out to the poolside where the actual teaching happens
Two pieces of judgment are worth calling out. Student progress is recorded live against a course wide objective checklist rather than snapshotted, so an instructor’s tick on the poolside is immediately visible in the student’s journey, and corrections go through an append only supersede trail rather than an edit. And the admin AI agent that helps manage the catalog acts strictly as the admin who invoked it, replaying frozen payloads through the same permission gated routes a human would hit, with no power to delete, touch payments, or reach student data. It is a convenience layer, never its own authority.
Where My Judgment Showed Up
The critical calls were structural, made before most of the features existed.
- Four surfaces, one source of truth, the audiences are different but the student is the same, capability driven rendering kept that honest instead of forking the data
- Capabilities as live row existence, not token claims, this made the whole permission model revocable in real time and kept web and mobile on one identity
- Ledgers everywhere money moves, payments and commission are append only and derived, which removed an entire class of “the number is wrong” problems before they could happen
- Constraining the AI agent to the admin’s own authority, the agent never holds power the human does not, every existing gate applies unchanged
The Outcome
Swimiss now runs the academy from one platform. The web app is live at swimiss.com.my and the dashboard at app.swimiss.com.my, with the mobile app carrying the student and instructor journey to the poolside.
The team manages enrollment, sessions, and the affiliate program in one place. Affiliates see their leads and trust that commission is tracked. Students see their course journey and where they need to improve. Instructors record performance and tick course requirements in the moment, on the deck, instead of from memory after the fact.
What I Learned
What started as “give the academy one system” ended up a full blown product. By the time it was done, it was really several startups stitched into one.
- An affiliate system, referral codes, click attribution, commission, and payouts, the kind of thing companies sell as a standalone product
- A product and inventory layer in the spirit of Shopify, courses, vouchers, and catalog management with money moving through it
- A booking system, scheduled sessions, capacity, and reservations across multiple disciplines
- A student management system, enrollment, course progress, instructor records, and a live objective checklist
Each of those is a product in its own right. Building them as one coherent thing, on one source of truth, with one identity model, was the actual work, and it was far more than the original brief implied.
The hard part of a multi sided product is not building four feature sets, it is keeping them honest against one truth. Every shortcut that would have stored a balance, baked a role into a token, or let the AI agent act on its own authority was a shortcut that would have cost trust later. Choosing ledgers over stored numbers, live capabilities over claims, and frozen snapshots over editable history made the system slower to build and far cheaper to trust.
That is the lesson that carries forward. When one person builds what is effectively four products against the same data, the design work is in the invariants, not the screens.