by Gary Worthington, More Than Monkeys

When the pandemic hit in 2020, youth sports stopped overnight. Training grounds closed, leagues paused, and coaches suddenly had no way to engage their players.

For one football coaching app, this moment could have been chaos. Instead, it was a demonstration of what happens when you design with scaling in mind.

The app went from 5,000 to 500,000 users in a year, not because the engineering team pulled endless all-nighters, but because the foundations were already there. Cloud-native design, elastic infrastructure, and clean product decisions meant the surge could be absorbed rather than fought.

The Premise: Football Skills in Your Pocket

The app’s purpose was simple: break football (or soccer for our American readers) into fundamental skills (dribbling, passing, finishing) and give kids the tools to practise at home. Each drill came with instructional videos and clear success criteria.

For coaches, there were dashboards to assign drills and track progress. For parents, a way to keep children engaged in something structured and positive.

Before 2020, this was a niche tool with steady adoption. When lockdowns hit, it became essential.

March 2020: The World Goes Remote

Clubs couldn’t meet in person. Coaches needed ways to justify memberships and keep their communities alive. Parents needed constructive activity at home.

The app already had everything required: asynchronous drills, progress tracking, and cross-platform access. It wasn’t retrofitted for the pandemic; it was built in a way that happened to be perfectly aligned with the new reality.

Scaling Without Firefighting

However, the real story here isn’t about heroic technical rescues. It’s about how little had to be done when growth went exponential.

1. Elastic Infrastructure

The application was containerised and deployed on cloud services that scaled horizontally. Autoscaling groups and managed services meant that when entire leagues onboarded overnight, extra compute and bandwidth simply spun up. Video content was delivered via a global CDN from day one, so the sudden load on streaming caused no disruption.

2. Database Designed for Growth

Instead of relying on a single overloaded database, the design separated concerns early. Core transactional data, reporting queries, and activity logs lived in different places. Read replicas and caching were already in place, so the system handled tens of thousands of concurrent queries without a scramble for optimisations.

3. Multi-Tenant From the Start

The product had been built with clubs and academies in mind. Data was partitioned by tenant, with clear access controls and indexing. This meant scaling from one academy of 30 players to a league of 30,000 required no re-architecture — just more of the same.

4. Observability Baked In

Metrics, logging, and tracing were part of the system long before the spike. When traffic surged, the team could see exactly how services were performing. There was no rush to install monitoring tools during the crisis . They were already in place, tuned, and alerting.

5. Customer Success at Scale

Even the human side of scaling had been thought through. Automated onboarding flows, video tutorials, and self-service help content meant that most coaches could get started without needing one-to-one support. Customer success was there to handle the edge cases, not every case.

Why This Worked

The growth story could easily have been one of outages, firefighting, and hastily re-architected systems. Instead, it was largely uneventful from an engineering perspective.

• Cloud-native choices reduced risk. Elastic infrastructure and CDNs absorbed the load.
• Separation of concerns kept data flowing. Activity feeds didn’t drown transactional queries.
• Multi-tenant design meant scale was linear. Each new club looked the same as the last, just bigger.
• Observability prevented surprises. Issues were caught before they escalated.

The pandemic didn’t force the product to pivot technically. It just forced the world to adopt it faster.

Lessons for Product Teams

1. Design for scale early. You don’t (and shouldn’t!) need to optimise for millions of users, but you can avoid choices that trap you at 5,000.
2. Lean on the cloud. Elastic services exist for a reason so my advice would be to use them.
3. Think about distribution. Building for clubs and leagues (B2B2C) multiplies growth far faster than one user at a time.
4. Treat observability as a first-class feature. You can’t respond calmly if you can’t see what’s happening.
5. Scaling isn’t just technical. Automating onboarding and support is as critical as scaling databases.

Beyond the Numbers

The app didn’t just survive the spike. It kept kids playing, parents sane, and clubs connected. What could have been a crisis for coaches became an opportunity to engage players in new ways.

From an engineering standpoint, the real win was that nothing dramatic happened. Growth was absorbed, not fought.

Final Thoughts

Scaling from 5,000 to 500,000 users in a year doesn’t have to be a war story. If you invest in cloud-first design, elastic infrastructure, and clean product decisions, it can be remarkably uneventful.

The best scaling stories are the boring ones, the ones where technology quietly gets out of the way, and users get the value they need, when they need it most.

Gary Worthington is a software engineer, delivery consultant, and agile coach who helps teams move fast, learn faster, and scale when it matters. He writes about modern engineering, product thinking, and helping teams ship things that matter.

Through his consultancy, More Than Monkeys, Gary helps startups and scaleups improve how they build software — from tech strategy and agile delivery to product validation and team development.

Visit morethanmonkeys.co.uk to learn how we can help you build better, faster.

Follow Gary on LinkedIn for practical insights into engineering leadership, agile delivery, and team performance.