Overview
Portalº Thermaculture is a membership-based wellness company offering contrast therapy, sauna, and recovery experiences across multiple physical locations in the U.S. As the business grew, Portal made a deliberate decision to move off an existing third-party booking platform and invest in a fully custom product that could better support its brand, operations, and long-term growth strategy.
I led product design across two major phases of this effort: an initial definition and discovery phase focused on the customer booking experience, followed by a platform expansion phase centered on admin tooling, operations, and reporting. Today, Portal is live in production, supporting hundreds of bookings per day across multiple locations, and has fully replaced the legacy systems it was built to supersede.
Background
Before Portal began building its own platform, the business relied on Glowfox, an off-the-shelf booking system that quickly became a limiting factor.
The team faced several issues:
Frequent bugs and reliability problems
A rigid system that couldn’t support Portal’s unique workflows
A generic, dated customer experience
Little ability to express Portal’s brand, voice, or values
Limited flexibility for future expansion
Beyond day-to-day frustrations, Glowfox also represented a strategic ceiling. Portal’s long-term vision included white labeling and franchising, and it became clear that this would be nearly impossible on top of a closed, inflexible third-party platform.
Building a custom product wasn’t just about improving UX. It was about owning the platform, unlocking flexibility, and creating a foundation the business could grow on for years.
Project Scope
Phase 1
Customer booking and membership experience
Session discovery, booking, and checkout
Early platform definition and system foundations
Rapid iteration directly with the founding team
Phase 2
Admin and operator workflows
Session creation and scheduling
Reporting and analytics
Role-based permissions
Operational tooling to replace the existing backend system
Team & Role
My role
Lead product designer across multiple development phases
Owned experience definition across customer and admin surfaces
Worked closely with stakeholders to translate loosely defined needs into concrete systems
Partnered with engineering on feasibility, scope, and phased delivery
Team
Founder and executive stakeholders
Product and operations leadership
Engineering team (frontend and backend)
Phase 1: Defining the Customer Booking Experience
Context
Phase 1 was less about “redesigning a booking flow” and more about discovering what Portal’s digital experience should be.
We were simultaneously:
Replacing a legacy system
Defining new business rules
Establishing design patterns that would need to scale
Iterating directly with a highly involved founding team
This meant design was deeply collaborative and highly iterative. Decisions were often made in tight feedback loops, refined, and pressure-tested against real operational needs.
Designing Through Discovery
The early booking experience needed to feel:
Calm and approachable
Clearly differentiated from generic fitness or booking apps
Flexible enough to support memberships, credit packs, and one-off sessions
Simple on the surface, without hiding important information
Rather than locking into rigid requirements, we treated early designs as working hypotheses. Flows were refined continuously as Portal learned what resonated with customers and what broke down in practice.
Crucially, this phase established foundational patterns and data models that made subsequent development phases possible. The flexibility of the admin platform, reporting, and scheduling systems all trace back to decisions made during this initial discovery phase.
Designing Within Portal’s Brand
Portal has a modern, new-age aesthetic rooted in colorful geometric forms with a calm but confident tone. The brand intentionally avoids looking like traditional fitness software, which created a real opportunity to design something memorable and differentiated.
At the same time, this introduced tension:
Very dark palettes risked poor contrast
Warm reds and oranges sometimes read as error states
Highly stylized UI elements occasionally competed with clarity
Part of my role was helping the team find the line. I regularly pushed back when design choices crossed into accessibility issues or introduced confusion, while still honoring the spirit of the brand. The result was a UI system that feels distinctly Portal, but remains usable, accessible, and clear under real-world conditions.
Phase 2: Scaling Into an Operational Platform
The Shift in Focus
As Portal expanded, the center of gravity moved from customer experience alone to the systems required to actually run the business.
Phase 2 introduced a different class of problems:
Admin users with varying levels of technical comfort
Increasing operational complexity across locations
The need for insight without overwhelming users
Replacing the legacy admin backend entirely
This phase was about turning Portal into a true operating platform, not just a booking interface.
Key Design Challenges & Decisions
Admin Tools Without Overwhelm
Admins needed power, but not complexity for its own sake.
I focused on:
Clear defaults and progressive disclosure
Scoping complex actions into side sheets and contained workflows
Separating high-frequency actions from advanced configuration
The goal was to let admins move quickly for common tasks while still supporting deeper control when needed.
Session Scheduling as a System
Scheduling needed to support:
One-time and recurring sessions
Multiple session types
Capacity, pricing, and audience rules
Operational realities like staffing and availability
To incorporate these complex and variable requirements, scheduling was treated as a configurable system, borrowing familiar patterns from calendar tools while remaining flexible enough to grow as Portal’s offerings evolved.
Reporting That People Can Actually Use
Reporting was one of the most complex areas of Phase 2.
Stakeholders wanted insight into:
Membership trends
Retention and cohorts
Engagement and utilization
Geographic distribution
At the same time, not every user needed every metric. Reports were organized by intent, with thoughtful defaults and filters to avoid overwhelming users or presenting misleading data. In several cases, simpler visualizations were chosen intentionally to balance accuracy, clarity, and development effort.
Outcomes & Impact
Portal is now live in production and fully replaces the previous booking and admin systems.
The platform supports hundreds of bookings per day across multiple locations
Admin workflows are faster, clearer, and more reliable
Customer feedback on the booking experience has been consistently positive
Staff and operators report greater confidence and control
Most importantly, Portal now owns its product experience end-to-end, rather than working around the limitations of third-party software.
Reflection
Portal was an exciting opportunity to design both a consumer-facing experience and the internal systems that power it, all while working within the constraints of a unique and quirky brand.
Phase 1 required speed, intuition, and comfort with ambiguity.
Phase 2 required systems thinking, restraint, and long-term planning.
If revisiting this work, I’d push even earlier on formalizing permissions and continue refining reporting as more real-world usage data becomes available. Overall, the project reinforced my interest in designing complex platforms where clarity, flexibility, and judgment matter.
