Building a Platform That Processes $4.5M Every Fortnight: The HUB Story

· Mohammad Syed

What happens when you're tasked with building an all-in-one SaaS platform for Australia's second-largest fitness operator? Here's what I learned managing 16 people across 42 sprints to deliver something that couldn't fail.

Key takeaways

  • HUB processes over $4.5M AUD every fortnight for 350,000+ members across 350+ gyms. A core team of 16 built it in 42 sprints.
  • The scariest part was integrating VivaPay, a payment gateway that was being built at the same time as HUB.
  • GraphQL made querying data easy and deployments painful. The next version of HUB moved to REST.
  • If I did it again, I’d hire a business analyst and testers from day one, and plan the reporting module properly.

When I joined Viva Leisure as Project Manager for Viva Labs, I knew we were building something significant. What I didn't know was that I was about to spend the next two years building a platform that would process over $4.5 million AUD in transactions every fortnight, serve 350,000+ members across 350+ gym locations, and fundamentally change how fitness businesses operate in Australia.

No pressure.

The Scale Hits You All at Once

We always knew we were building for the second-largest health and fitness operator in the APAC region. The member numbers—north of 350,000—were clear from day one. But there's a difference between knowing numbers on paper and realizing what they mean in practice.

The closer we got to production, the more the reality set in: we were about to process over $4.5 million in payments every fortnight. Through a platform built by a small, nimble team. With a payment gateway that was still in its infancy.

That's when it hit us—what we were building wasn't just another SaaS product. It was critical financial infrastructure for hundreds of businesses and hundreds of thousands of people.

And we had to get it right.

The Technical Bet: All In on React, AWS, and GraphQL

One of the first questions we had to answer was deceptively simple: "What are we building? How much do we want to build? How big is the HUB going to be?"

Viva Leisure wasn't a startup—it was an established company with 5+ brands serving customers across nearly every Australian state. We couldn't build a minimum viable product and iterate slowly. We needed an all-in-one platform that could handle everything from day one.

Our front-end lead, back-end lead, and CTO made the critical technical decisions early: JavaScript with React for the frontend, AWS and GraphQL for the backend. At the time, it felt like the right call—modern, scalable, powerful.

Spoiler alert: GraphQL would later become both our greatest strength and our biggest headache. But I'm getting ahead of myself.

The VivaPay Integration: When "Terrifying" Is an Understatement

Here's where things got interesting. Instead of using Stripe, PayPal, or any established payment gateway, we were told we'd be integrating VivaPay—Viva Leisure's proprietary payment processing system.

VivaPay was being built from scratch. At the same time we were building HUB. And HUB needed VivaPay to process those millions in transactions.

I kid you not, there were moments when we sat in meetings, watching the VivaPay timeline slip, knowing that every delay cascaded directly into our project. Building a payment gateway from scratch isn't easy, and we were completely dependent on another team delivering something that had never been done before.

The delays came. The integration was a massive hurdle. There were absolutely moments when we thought, "This could all go wrong."

But here's the thing about close-knit teams of 12-14 professionals who genuinely believe in what they're building: you find a way. The VivaPay team delivered (albeit with delays), we figured out the integration, and when we finally saw those first transactions processing successfully, we threw a massive party.

We'd earned it.

Building the Team: The Engine Running at 200 Miles Per Hour

I was probably the third person to join the HUB project, after the front-end and back-end leads. Which meant we had to build the entire team from scratch.

At our peak, we had around four front-end developers, four back-end developers, a designer, the head of labs, and me managing the chaos. We never got a dedicated tester—our amazing front-end team handled testing on top of their development work.

Not every hire worked out. We made some bad calls, had to let people go, and replaced them with better fits. Some team members left mid-project, and we had to onboard replacements while maintaining velocity.

But the core 16 people who delivered HUB across 42 sprints? They were the reason we succeeded.

We became an engine running at 200 miles per hour. A small team building a massive product that would serve hundreds of thousands of people and process millions in payments. We figured out how to work as one cohesive, agile, fluid team, always focused on the end goal.

The culture we built was second to none. That's one of my proudest moments as a project manager—not just delivering the platform, but cultivating a team culture where people genuinely wanted to show up and do great work together.

When Things Go Wrong (And They Always Do)

Let me be honest about what didn't work:

We missed sprint goals. Sometimes we simply didn't meet our commitments. Why? Because we didn't always have clear requirements.

Stakeholder management was chaos. I was dealing with our CTO, COO, CEO, general managers, state managers, and gym managers. Sometimes I'd be running around trying to figure out what the correct requirement actually was for a particular feature.

I couldn't always translate requirements effectively. As a PM, there were moments when I failed to clearly communicate what needed to be built. The ambiguity cascaded into the dev team, and we'd realize mid-sprint that we were building the wrong thing.

But here's what saved us: we never pointed fingers. We took responsibility collectively. Each one of us. If something didn't work in one sprint, we'd fix it in the next. We were laser-focused and resilient.

The GraphQL regret. This is the big one. GraphQL was brilliant for querying data, but every deployment became a nightmare. If a pull request was big or complex, it would take forever and fail multiple times. We all regretted that technical decision, but we didn't pivot—we found workarounds and kept moving.

Later, after we went live and were making incremental fixes, we realized GraphQL wasn't scalable for our needs. That's when we decided the next version of HUB would migrate to REST APIs. But by then, we'd already delivered the platform.

The reporting module disaster. We thought we'd built a perfect reporting system. We were wrong. It didn't work the way we needed it to. So we pivoted, built a data pipeline, and created "HUB Insights"—a separate dashboard that pulled data from HUB and generated the reports our users actually needed.

If I were building HUB from scratch again, I'd pre-plan the reporting module much more thoroughly.

The Feedback That Made It All Worth It

One of the most memorable moments was presenting HUB at an early Plus Fitness conference. We'd invited all the franchisees, and we were showcasing what Viva Labs had built.

The feedback was consistent: "Wow, this is beautiful. This is very simple. The UI and UX are easy to understand, easy to navigate. This would make our lives easier. We'd do a lot less admin work."

That's what we'd aimed for—simplicity at scale. And hearing it directly from the people who'd be using HUB every day? That's the validation that makes all the late nights and technical headaches worthwhile.

The Business Impact: When Failure Wasn't an Option

Here's the context that kept us up at night: Plus Fitness was using another software platform for member management and payments. That platform was being shut down. If we didn't deliver HUB before the shutdown date, Viva Leisure would lose millions in revenue.

No pressure, right?

When we finally went live and saw the dashboard showing real-time member counts, gym check-ins, and payment processing—watching those numbers climb into the millions every fortnight—it felt surreal.

We'd built a platform of this magnitude in just 42 sprints. And it was working.

Scaling Under Pressure: The Vietnam Team

About six months before our planned launch date, we realized we needed to scale the team. That's when we partnered with an amazing team of contractors in Vietnam.

The challenges were immediate: different time zone, language barriers, embedding a completely new team into our existing workflow. We had to get them working on our schedule, which wasn't easy.

But we had a representative from the offshore team who could translate requirements, and eventually, we found developers who were strong in English. Once we embedded them properly, the time zone issues disappeared.

Onboarding the Vietnamese developers was one of the best decisions we made. Their hard work, attitude, and work ethic helped us deliver HUB on time. Without them, we would have faced massive delays.

The Gym Flex App: A Game-Changer

While we were building HUB, we also launched the Gym Flex App—and it was a game-changer.

The concept was simple but revolutionary: users could buy gym passes for 5, 10, 15, 20, 50, or 100 visits instead of committing to a fortnightly membership. The entire process took 5-10 minutes. The UI was simple and intuitive.

The results? A 4.5-star rating and thousands of downloads in the first few months.

I believe we were the first health and fitness company in Australia to offer this kind of flexibility. It completely changed the game and showed that innovation doesn't always mean complexity—sometimes it means making things simpler and more accessible.

Managing Concurrent Chaos

Oh, and did I mention that while building HUB, I was also managing multiple other projects?

I was the single project manager juggling all of these. We delivered the Rebalance website on time. For the swim school and CRM, we eventually hired another brilliant PM who took those off my plate. The swim school platform launched; the CRM never saw daylight.

But the digital advertising overhaul? That was my personal pet project. When I saw the existing dashboard—poor UI/UX, barely functional—I thought, "This is not right."

I worked hand-in-hand with one of my key colleagues (my right-hand man) and directly with the CEO to redesign it completely. We fixed it in about a month and a half, turned it into an additional revenue stream, and rolled it out across all our gyms.

How did I manage the chaos? Planning. Obsessive communication. Multiple sprint boards. Knowing what's happening on every project at any given time.

I'm a shrewd planner. I note down everything I do during the day. I communicate obsessively with my teams, and I expect the same from them. We prefer synchronous communication and constant alignment.

That's how you manage chaos—you don't eliminate it, you orchestrate it.

Lessons Learned: What I'd Do Differently

If I were building HUB from scratch again, here's what I'd change:

1. Assemble the right team from day one.

We needed a business analyst, two testers (manual and automation), and a complete suite of skill sets. We made do without them, but it cost us time and quality.

2. Spend more time on architecture planning.

GraphQL seemed like a great choice, but we didn't anticipate the deployment nightmares. More upfront planning would have saved us significant pain.

3. Establish a more rigid requirements process.

Get requirements approved by management before handing them to developers. We were building so fast that we sometimes skipped this step, leading to rework.

4. Pre-plan the reporting module.

We thought we had it figured out. We didn't. Building HUB Insights as a separate system worked, but it would have been better to design it properly from the start.

5. Anticipate scaling needs earlier.

Bringing on the Vietnam team six months before launch was the right call, but we could have done it even earlier to smooth the integration.

The End Result

Was it worth it? Absolutely.

We built a platform that:

We proved that a small, nimble, well-gelled team can build enterprise-scale platforms that handle real money, serve hundreds of thousands of users, and fundamentally change how businesses operate.

The technical decisions weren't all perfect. We made mistakes, missed sprint goals, and had to pivot on features. But we never stopped moving forward, never stopped supporting each other, and never lost sight of what we were building.

That's what matters in the end—not perfection, but persistence, collaboration, and a genuine belief that what you're building will make people's lives better.

And when you see those transaction numbers climbing into the millions every fortnight? When you hear gym owners say your platform made their lives easier? When you watch your team celebrate after integrating a payment gateway that everyone said was impossible?

That's when you know it was all worth it.

What's the most complex platform you've built? Have you ever worked on a project where failure genuinely wasn't an option? I'd love to hear your stories and lessons learned in the comments.

More posts by Mohammad Syed