The context
Member Splash is membership-management software for swim clubs. I work as a Senior Product Engineer, carrying features across product design and implementation while partnering with Customer Success, support, and other engineers.
The work is operational by nature. A small interaction decision can affect a busy front desk, a family managing purchases for their children, or the developer who needs a working local environment before they can help ship the next improvement.
Member Check-In
A counter workflow built for the busiest moments
At a check-in counter, staff might need to find an account by member name or account number, select each family member present, add and name guests, check available guest credits, sell more credits if necessary, and finally confirm that everyone was checked in.
The old workflow was slow and unintuitive, especially around guest entry. That is a meaningful problem when the counter is staffed by high-school employees, volunteers, or an understaffed seasonal team and opening-weekend lines are building.
The interaction model
I owned the upgrade end to end. I replaced the fragmented lookup with an omnibox that accepts a last name, address, or phone number. Staff can then select the people who arrived, with a ready-to-use next guest row instead of another button press.
Guest credits are visible in context: how many are available and how many the current entry will use. When a family needs more, staff can purchase them in the same flow with bill-to-account or a credit card.
Working sketch reconstructed from the shipped interaction model. It compares the prior staff workflow with the redesigned flow; it is not a production screen.
How we evaluated it
There was no formal research program around the old flow. The signal was shared operational experience: people could get through it, but it took too long and everyone knew it could be improved. I ran timed workflow tests, used server data to model the consequence of opening-day volume, and reviewed the work with Customer Success, support, and other engineers.
In internal timing, the workflow went from more than 30 seconds to under 10 seconds. It rolled out to all clubs with documentation for staff and club administrators. Clubs described the redesign as faster, easier to understand, and better to use.
Internal reconstruction of the manual workflow-timing comparison behind the 30-plus-to-under-10-second result. It reflects timed manual runs covering search, arrivals, guests, and credits against a busy front-desk scenario, with server data used to understand peak-period traffic. It is not club-wide analytics and not a production screen.
Splash Cards
Prepaid spending that works for families and clubs
Splash Cards are entirely digital stored-value cards. They let primary account holders load money for children or unattended youth to spend at the snack shack, without needing a parent present. The same prepaid model also lets clubs collect money before purchases that members would have made anyway.
I owned the feature end to end, from the member-facing management experience through the payment and point-of-sale paths.
Designing for a real family account
The initial concept assumed one card per person. Customer Success and community-forum feedback changed that. Families needed to provision more or fewer cards, transfer funds, and pause a card when appropriate. A primary member can now manage multiple cards across a family account, so one child cannot spend the entire shared balance.
Members load cards in the portal using credit or debit cards through the existing payment gateway. At the snack shack, the attendant selects the member account as part of the usual order flow, and the account’s eligible Splash Cards appear as payment methods. Flexible card provisioning shipped in the first release; guest-pass payment support followed in July.
Working flowchart reconstruction. It traces card funding and status management from the member account through point-of-sale payment, including what happens when a linked card is paused or has insufficient funds; it is not a production screen.
Rollout and results
Work began April 15, 2026, and v1 shipped June 12. The capability was available to every club, behind a club-level toggle so adoption was opt-in.
In 2026, 72 of 499 live clubs had Splash Card activity. The feature supported roughly 4,979 people across 1,701 active cards and approximately $76,000 in card loads.
Money movement needed a safer boundary
An audit of the payment flow exposed a correctness risk: ambiguous gateway responses could be treated as successful loads even when payment confirmation was missing. I redesigned the failure boundary so the wrapper can return only a verified transaction ID or an explicit error. I added a second validation at the controllers where money moves, improved the authorized correction path for mistaken loads, and repaired a silently failing test bootstrap.
The principle was simple: money state should be verified at the edge or refused at the boundary. The issue has not recurred since the hardening work.
Abstract reconstruction of the payment-success and correction boundary. It shows flow structure only, not real payment data or production UI.
Developer experience
Turning a personal environment into a team tool
The old local environment used Lando plus a substantial set of configuration and tooling layers. Setup could take days of back-and-forth, and it was unreliable on my Mac. I began with a Docker environment that ran Member Splash on my own machine, then asked the lead developer what the wider team needed before turning it into shared infrastructure.
The result incorporated local SSL through mkcert and Traefik, along with the team’s existing Make commands. It runs on Windows, macOS, and Linux. After setting environment variables and adding local subsite host entries, normal setup is measured in minutes; slower cases remain under an hour.
Abstract infrastructure-onboarding reconstruction. It shows the before/after local development flow, not production configuration.
Existing developers adopted it, and new developers have used it to get running. The goal was not Docker for its own sake. It was reducing the delay between joining the codebase and being able to investigate, debug, and contribute.
Reflection
The strongest work here has been less about a single interface and more about keeping context across a system: the staff member at the counter, the parent managing a family account, the payment boundary, and the developer who maintains the platform. That is where design engineering is most useful to me: making the product decision and the implementation decision reinforce each other.