What We Shipped This Quarter and Why

Build-in-public only means something if it includes what actually shipped, not just the roadmap. Three things went live this quarter: recurring billing for clinics and ongoing programs, a financial health view for directors, and self-service cancellation requests for season withdrawals. The first two came directly out of the same problem — payment status being scattered across tools instead of living where the rest of a club's operations do. The third closes a different gap: season withdrawals happening entirely outside the platform, over email or a phone call, instead of leaving a record where the rest of a family's history with the team already lives.

Recurring billing for clinics and monthly programs

Not every program a club runs fits a single season-fee model. Clinics, skills programs, and ongoing monthly commitments need recurring charges that happen on their own schedule, independent of the main season's payment plan logic. Before this shipped, clubs running that kind of program were handling it the way most clubs handle anything outside the platform's native flow: a separate tool, tracked manually, reconciled by hand against everything else.

We built recurring billing as a native option on the same athlete record and payment infrastructure as everything else — same Stripe Connect account, same club-as-merchant-of-record model, same visibility a director already has into season payments. A clinic subscription isn't a separate system bolted alongside the platform; it's another payment pattern the existing infrastructure already knows how to handle. That was the actual design goal: not "add subscriptions" as a feature, but make sure a new payment pattern didn't require a new disconnected tool to support it.

Financial health view

The second piece addresses a gap we heard consistently: directors could see individual payment statuses, but not a single view answering "where do we stand financially, right now, across the whole club." That's a different question than "is this one family paid up" — it's the aggregate view only a director actually needs, and it's exactly the kind of cross-team question a team-level tool structurally can't answer, because it was never built to see across teams in the first place.

The financial health view pulls together payment plan status, outstanding balances, and recurring billing health into one director-facing screen — not a report someone has to manually assemble from individual family records, but a live aggregate that updates as payments move. The goal wasn't a new report to check occasionally; it was removing the need to build that report by hand in a spreadsheet, which is what happens by default when a platform doesn't offer this natively.

Why these two, together

Both features solve the same underlying problem from different ends. Recurring billing prevents a new kind of admin tax from being created as clubs add clinics and ongoing programs. The financial health view removes an existing admin tax — the manual aggregation directors were already doing to answer a question the system should have been able to answer on its own. Shipping them in the same quarter wasn't a coincidence; they're both instances of the same principle: whatever a director currently does by hand to reconcile payment data across the club should be something the system does natively instead.

Self-service cancellation requests

The third piece: a guardian or player can now submit a season withdrawal request directly from their own account instead of emailing or calling staff to start it. It's scoped to season withdrawals for now — a clinic withdrawal still goes through staff. Submitting a request captures a reason (cost, schedule conflict, moving, and so on) at the same time, so a director gets real structured data on why families are leaving instead of whatever a phone call happened to capture. And it's still a pure record: submitting doesn't touch the roster on its own — a director still reviews the request and processes it before anything actually changes, the same explicit-staff-action pattern refunds already use.

---

Build-in-public means the backlog is honest, not just the launches. Recurring billing, financial health, and self-service cancellation requests all shipped this quarter because they closed real gaps directors were absorbing manually.