Better Than Starbucks

VASA Fitness, a national gym chain, needed a real mobile app. What they had wasn't working, and they needed it live in both app stores by Thanksgiving — less than six months away.

Our team was about ten people, all Neudesic. A couple of senior leads and a group of junior developers — several building their first native iOS or Android app. The timeline was set before we were staffed, the client was still figuring out what they wanted, and nobody on the team had worked together before. Classic consulting project: chaotic, fast, and exciting.

VASA's existing app was a Netpulse white-label — a generic template shared across dozens of gym brands. All of VASA's real member data — accounts, class schedules, payments, KidCare reservations — lived in a completely separate system called PAC. The two systems didn't talk to each other.

The result was maddening: members opened the app, logged in, then got launched into a browser window where they had to log in again to a different system just to see their class schedule. Two logins, two interfaces, no continuity.

The member we kept coming back to throughout the project — a single mom in her early thirties who drops her two kids at KidCare before her morning class — couldn't do the thing she needed most. KidCare scheduling wasn't available through any digital system. She had to call the front desk every time. We wanted her to open the app on Sunday night, schedule her KidCare and classes for the week in two minutes, and move on. That was the bar we designed toward.

Before we designed a single screen, we surveyed over 8,000 VASA members. The scale of that response was unusual for a project like this — it gave us a dataset that was hard to argue with when it came time to make priority calls.

Three findings shaped the entire product direction.

The single loudest frustration across thousands of responses was simple: members couldn't access or manage their own accounts through the app. Not "we want fancier features" or "the design feels dated." Just: let me see my own account. Let me book a class without logging in twice.

Every feature we designed had to work within the API boundaries of PAC, the third-party platform that held all of VASA's member data. PAC wasn't built to power a modern mobile app — it was built to manage gym operations from the back office. So it wasn't enough to ask "what's the best experience?" We had to constantly ask "what can PAC actually give us?"

KidCare scheduling was a perfect example. No system supported it digitally — members had been calling the front desk. We worked with PAC to figure out what data was available, what scheduling logic could be built on top of it, and how to present it as something that felt native. From the member's perspective, it just worked. She had no idea what was happening underneath.

VASA's brand lived in marketing — billboards, gym signage, promotional flyers, and a sales website built to convert, not retain. None of it was designed for a product. Translating that into a native mobile experience meant creating a visual language the brand had never needed before. I worked directly with VASA's Chief Brand & Marketing Officer, Mindi Bridges, through rounds of moodboards, style tiles, and early concept designs to lock the visual direction before building a single production screen.

That early investment paid dividends: when design questions came up later, we had a shared vocabulary vetted at the top, which meant I could move fast and make visual decisions with confidence rather than looping back for approval on every screen. From there, I designed over 390 screens across three major phases and multiple updates.

Design on this project wasn't a handoff — it was a continuous loop. Screens went into Figma, builds came back from developers, and we iterated in real time. What I designed this week was often in a build next week, which meant design decisions had to be made fast, communicated clearly, and revisited constantly.

But speed only works if the people building your designs understand them. About two-thirds of the development team were junior engineers learning native iOS or Android for the first time. Rather than treat them as downstream executors, we pulled them in early — into workshops, into whiteboard sessions, into the messy front-end of the design process where decisions were still being made. When developers understand why a design exists before they write a line of code, they build it differently.

I also started doing side-by-side reviews once builds came back. I'd sit with a developer, pull up the build on a device next to the design in Figma, and we'd walk through it together — talking through intent. Why this spacing exists. What the user is trying to accomplish on this screen and how the layout supports that. It wasn't just QA — it was teaching them to see the design the way a designer sees it.

That review cadence became the team's operating model for the rest of the engagement.

The return compounded over time. Developers started catching issues on their own, asking better questions before building, and developing an instinct for when something looked off. By Phase 2, the gap between design intent and built output had narrowed significantly — not because the designs got simpler, but because the team had internalized how to read them.

We didn't just ship and hope the numbers would tell us if it worked. Throughout the project, I ran guerrilla usability testing sessions at VASA gym locations — walking up to real members with prototypes on a phone, watching them try to complete tasks, and listening to where the design broke down. Across the project I tested with roughly 6 to 12 members, focused on the three flows that mattered most: class scheduling, KidCare booking, and the membership purchase process.

Filtering tripped people up — twice. The same problem surfaced in two different flows. In class scheduling, members struggled to filter and find the right class — the filter patterns we'd designed made sense to us but created confusion in practice. The same pattern repeated in KidCare booking. Seeing it in two flows made it impossible to ignore — this wasn't an edge case, it was a pattern in our design language that needed to be rethought. We simplified the filter interactions across both flows: clearer entry points, fewer steps, and interactions that felt invisible.

The membership purchase flow needed to breathe. In testing, the length of the flow created friction. Members weren't sure how far along they were, and the density of information on tier comparison screens made it hard to focus. We made a series of refinements — clearer step progression, streamlined screens, and a more scannable tier comparison. The flow was still detailed — it had to be — but it no longer felt like a slog.

After making changes, I went back to the gyms and put the revised prototypes in front of members again. The friction points were gone. That second round gave us the conviction to lock the designs and move into development, knowing the core experience had been validated by the people who'd actually use it.

The Phase 1 launch target was November 2019 — timed to a Thanksgiving marketing push. Less than six months from kickoff to both app stores, with a junior dev team and third-party API dependencies.

As the deadline closed in, it became clear we couldn't deliver the same quality on both platforms. The iOS experience was strong — the version the C-suite ended up raving about. Android was functional but carried compromises. My role wasn't deciding the tradeoff, but making sure what we shipped still made sense as a product — focusing design effort where it would have the most impact, tightening core flows, and working closely with developers to ensure that even where we cut corners, the experience held together.

With roughly 70% of VASA's members on iOS, we were delivering a high-quality experience to the majority while replacing something broken for everyone else. We treated Android as a gap to close, not a permanent state.

Shortly after launch, a message from Mehul Chaudhari — VASA's VP of Strategy and Analysis — made its way to our team through Slack. It got screenshotted and passed around to every person on the project.

That's the kind of thing you hold onto in consulting. You don't always get to hear how the work landed — you hand off the project and move on to the next one. When a client's entire C-suite is using your app to book their own gym classes and comparing it favorably to what Starbucks built with seven times the headcount, it tells you the work connected.

On March 19, 2020, VASA closed every gym in response to COVID-19. Revenue dropped to zero overnight. All vendor work halted immediately. For three months, the project didn't exist.

Before the shutdown, I'd made sure the design system and backlog were in a state where any team could pick them up — which turned out to matter more than I expected.

When VASA reopened and started bringing vendors back, Neudesic was one of the first calls they made. That decision — reinvesting in the app before most other vendor relationships — was a direct result of the trust built during Phase 1. That trust eventually led to two additional projects during the pandemic recovery, when every budget line was being scrutinized.

After launch, the feature backlog exploded.

With the roadmap locked, Phase 2 deepened member engagement. We added member referrals, check-in history, profile photo uploads, the ability to change your home gym, and a gamification system with badges — features designed to make the app feel personal, not just functional.

Six months into the engagement, the principal designer moved on. By that point, I was already running the design-dev collaboration, presenting directly to VASA's leadership, and making product-level calls — so the transition to UX Lead formalized a role I'd been growing into since the first sprint. I was no longer just designing screens — I was presenting directly to VASA's stakeholders, defining the product roadmap, writing user stories, managing the backlog, and keeping priorities aligned across a team that now spanned multiple workstreams and two platform-specific dev groups.

I became one of the primary communicators between VASA's leadership and our delivery team — translating business goals into design direction in stakeholder meetings, then translating design intent into implementation specifics in developer reviews. Two different audiences, two different languages, same product vision.

Ownership also meant caring about the product after it shipped. I wrote the app store update notes for each release and personally responded to user reviews — the kind of work that doesn't show up in anyone's job description but signals that someone on the team is paying attention to the full experience, not just the Figma file.

That trust came from showing up consistently — facilitating the card sorts, presenting design rationale in language stakeholders cared about, catching implementation issues before they became client-facing bugs, and being honest about what we could and couldn't deliver in a given sprint.

The trust built during the mobile app engagement led VASA to bring Neudesic back for two additional projects — a tablet-based sales tool and a self-service support site — both completed during the COVID recovery period in mid-2020, when every budget line was being scrutinized.

This project succeeded because the team learned how to make decisions quickly, align around what mattered, and move forward without perfect information.

For me, it reinforced where design has the most impact — not just in the screens, but in how decisions get made: helping a team converge, giving developers enough context to build with confidence, testing assumptions with real members, and making tradeoffs explicit so the product can actually ship.

The Starbucks comparison is the part people remember. The 4.3-star rating, the 300,000 installs, the revenue — those are easy signals. What mattered more was that the product worked, members could do what they needed without friction, and the client trusted us enough to keep going.

The platform tradeoff was the call that taught me the most — choosing to ship a strong iOS experience on time rather than a mediocre experience on both. Having the data (70% iOS users) made it defensible, but it still required the conviction to stand behind an imperfect launch.