BOXSPOT
A two-sided product for traveling athletes and fitness spaces: discover a gym, choose a class, complete the admin, pay, and arrive ready to train.
A simple drop-in hid a lot of coordination.
For a traveling athlete, dropping into a gym meant searching for nearby options, opening multiple websites, comparing class times and programming, contacting the gym, signing a waiver, paying, and confirming the visit.
For the gym, every visitor could create another chain of messages, paperwork, payment handling, schedule uncertainty, and last-minute context for the coach.
BOXSPOT turned that fragmented exchange into one product flow.
Find the right place
Search by location, compare gyms, understand the programming, and choose a class that fits.
Complete the visit before arrival
Registration, waiver, payment, confirmation, and athlete context happen in one sequence.
Prepare without interrupting class
The gym receives the information it needs before the athlete walks in.
The platform coordinated four different realities.
Discover + book
Location, preferences, profile, goals or injuries, waiver, payment, confirmation.
Configure the offer
Classes, prices, capacity, schedule, amenities, waivers, location, payouts.
Coordinate both sides
Discovery, registration, transaction, confirmation, and operational hand-off.
Receive the visitor
Needs the right context at the right time without turning class into admin.
Compress the travel ritual into one sequence.
Search
Compare
Select class
Register
Sign waiver
Pay
Confirm / attend
The athlete side stayed intentionally simple.
For the gym, joining BOXSPOT meant configuring an operating system.
A gym did not just create a profile. It had to define the data that made discovery, booking, legal readiness, and payouts possible.
About
Name, summary, programming.
Amenities
What the athlete can expect.
Crew
Staff and operational roles.
Classes
Size, price, duration, schedule.
Passes
Multi-day or multi-class access.
Promotions
Deals connected to classes.
Gallery
Visual context for the venue.
Location
Address and coordinates.
Hours
Operational availability.
Business
Merchant and payout details.
Waiver
Legal agreement before attendance.
Publish
Move from draft to live gym.
The complexity lived on the operator side so the athlete journey could stay light.
The operator product organized the gym around a few operational domains: About, Classes, Crew, Legal, and Payout. The wireframe below reconstructs that structure as one dense working view.
Gym profile & operations
Classes
Schedule slots
Readiness
Commercial
Operators also needed a schedule-first view of the day.
The interface was a view onto a richer operational model.
Product decisions and implementation constraints were part of the same job.
I built the operator web application around the same model the product depended on: explicit onboarding states, authenticated data, editable classes and schedules, legal documents, merchant state, uploads, and publishing.
React + Gatsby
Responsive product UI, forms, routing, and the gym configuration experience.
Apollo + GraphQL
Queries and mutations for gym profiles, classes, crew, waivers, merchant state, uploads, and publishing.
State-machine onboarding
Gym setup moved through explicit states instead of a loose collection of forms.
Maps + place data
Venue location connected operator configuration directly to athlete discovery.
Cypress + Jest
End-to-end and unit-testing infrastructure covered core registration and login paths.
Netlify + Sentry
Deployment and error monitoring were part of the working product stack.
I worked across product definition, UX structure, and implementation.
Product & Technology Lead
I moved between the customer problem, the product model, and the software required to make it real.
- Turned the drop-in journey into product requirements and workflows
- Worked across athlete and operator use cases
- Designed the operational model behind gym configuration
- Built the React/Gatsby operator web application and GraphQL integration
- Connected UX decisions to real auth, validation, schedule, legal, and payment constraints
- Worked from concept through production implementation
What this case demonstrates
A real multi-sided product where the customer-facing flow depended on dense operational logic underneath.
This case focuses on the product and technical work: the operating model, flows, implementation, and shipped athlete/operator experience.
The product connected discovery, booking, operator setup, and class readiness.
Athlete and owner mobile experiences were launched alongside the operator web product. The underlying system covered gym registration, authentication, setup, class configuration, legal and payout readiness, and publishing.
The booking screen was never the whole product.
Convenience is operational design
Easy for the athlete meant moving legal, commercial, scheduling, and identity work into a coordinated system.
Two-sided products carry asymmetric complexity
The athlete journey could stay simple because the operator side exposed the configuration and edge cases required to support it.
Backend behavior shapes UX
Availability, class slots, pricing, waiver state, merchant readiness, and publishing status determined what the interface could truthfully promise.