When I first got the call from POUND about a technical advisory role, I honestly wasn't sure what to expect. Here was this rapidly growing fitness brand that had caught lightning in a bottle with their unique drumstick-based workout concept. They were having challenges with their overseas development team and needed someone to help evaluate their options and potentially manage a transition to a new team.
What started as a short-term advisory engagement turned into a six-year journey that fundamentally changed how I think about technology leadership, team building, and business growth.
From Advisor to In-House Developer: The First Month That Changed Everything
I remember my first week working with POUND's team, trying to understand their technical challenges. They had an overseas development team that wasn't working out—communication issues, quality problems, missed deadlines—the usual pain points that happen when outsourced development doesn't align with business needs.
Initially, the plan was for me to help them transition to a different team and manage that process. But as I dug deeper into their systems and business model during that first month, a different picture emerged.
My initial mandate was simple: assess their current development situation, help them transition away from the problematic overseas team, and potentially find them a better outsourcing partner. But as I spent more time understanding their business model, technical challenges, and long-term vision, a different solution emerged.
The "aha" moment came during a strategy meeting in my third week. Instead of just finding them another team to manage remotely, why not bring development in-house? They could have better control, closer collaboration, and someone who truly understood their business building their technical foundation.
That's when we developed a mutual plan: I would transition from advisor to full stack developer, taking ownership of their technology stack and bringing all development in-house. This would give them the control and quality they needed, while giving me the opportunity to build something from the ground up.
Over the following years, as we refined our development processes, optimized our lean team structure, and established robust technical infrastructure, my role naturally evolved. By the time we had proven that a small, efficient team could handle global scale, I was named director of the engineering approach I had helped create.
The transition from advisor to in-house developer to department director taught me my first major lesson: sometimes the best opportunities come from solving the immediate problem in front of you while staying open to bigger possibilities that emerge along the way.
Building a Department While Building a Platform
Taking on the full-time in-house developer role meant I was suddenly responsible for everything technology-related that had previously been handled by the overseas team. It was exciting and terrifying in equal measure—I was inheriting years of technical debt while also being tasked with building a foundation for future growth.
One of my early realizations was that bringing development in-house meant more than just writing better code. We needed proper development processes, quality assurance, deployment pipelines, and all the infrastructure that makes a lean engineering operation effective. I found myself wearing multiple hats: developer, DevOps engineer, QA tester, and technical project manager.
But this broad responsibility turned out to be a gift. It gave me a complete understanding of how technology impacts every aspect of the business, from instructor onboarding to subscription management to content delivery. This perspective became invaluable when I eventually proved that a small, multi-skilled team could be more effective than a large traditional engineering department.
Start with APIs, Not Microservices
One of our smartest early decisions was building everything as a collection of well-defined APIs from day one. We didn't start with microservices (that came later), but we did start with clear separation of concerns.
The Foundation: Working with Inherited WordPress + Strategic Integrations
Here's something that might surprise you: a significant portion of our backend was built on WordPress—not by choice, but by inheritance. When I joined POUND, WordPress was already deeply embedded in the company's operations, and while I spent the next six years systematically reducing our dependence on it, completely migrating away wasn't feasible given our business priorities.
The challenge became: how do you scale a business when you're constrained by platform decisions made before you arrived?
WordPress Multisite for Strategic Separation: We used WordPress multisite for one specific purpose: separating our main POUND brand site from our merchandise shop. The merch operation needed to integrate with our global fulfillment partner, and maintaining it as a separate site within the multisite network allowed us to:
- Isolate e-commerce complexity from our core business systems
- Integrate seamlessly with our fulfillment partner's APIs without affecting other operations
- Maintain brand consistency while keeping the technical architectures separate
The Core Business: Subscription Portal for Certified Professionals The real meat of our business wasn't gym management or general fitness apps—it was our subscription portal exclusively for certified POUND instructors. This was built as a Progressive Web App (PWA) hosted within the WordPress ecosystem, leveraging WooCommerce Memberships and Subscriptions.
This wasn't my ideal technical choice, but it was the reality I inherited. The subscription portal handled:
- Instructor certification verification and membership management
- Exclusive content access for workout routines, music, and training materials
- Continuing education tracking and certification renewals
- Community features for instructor networking and support
Mobile VOD: Smart Third-Party Integration Rather than building our own video-on-demand infrastructure (which would have been a massive undertaking), we partnered with a specialized third-party VOD provider for our mobile app. This was actually one of our smartest technical decisions—we got enterprise-grade video streaming, analytics, and mobile optimization without having to build and maintain that complex infrastructure ourselves.
Strategic API Development: My focus became building clean API layers around the WordPress foundation to:
- Limit WordPress concerns to content management and basic e-commerce
- Create modern interfaces for mobile apps and internal tools
- Enable future migration paths by abstracting business logic away from WordPress
- Integrate cleanly with HubSpot CRM and our operational tools
The Integration Ecosystem: Making Inherited Systems Work
The real challenge wasn't building new systems—it was making inherited systems work together efficiently while gradually reducing our technical debt.
HubSpot CRM Integration (Also Inherited): Like WordPress, HubSpot was already in place when I arrived. Rather than fight it, I focused on making it work better:
- Automated data flow from our subscription portal to maintain accurate member profiles
- Behavioral tracking to understand instructor engagement patterns
- Retention analytics to identify at-risk subscriptions before they churned
- Personalized communication based on certification levels and engagement history
Slack + POUND Bot for Operations: We developed POUND Bot as our operational assistant living in Slack, which became our command center for:
- Subscription alerts when instructor renewals were approaching
- Content engagement reports showing which training materials were most popular
- Technical monitoring alerts for our WordPress and third-party integrations
- Business metrics delivered daily to keep everyone aligned on key numbers
Asana for Workflow Management: We integrated Asana with our WordPress backend to manage:
- Content creation workflows for new instructor training materials
- Certification processing and approval workflows
- Customer support escalation and resolution tracking
- Technical debt prioritization and sprint planning
The key insight was that you don't always get to choose your technical foundation, but you can choose how strategically you build on top of it.
Building a $50M+ Ecosystem with Never More Than Three Developers
Here's what might surprise people most about POUND's technical success: we built and maintained a global digital ecosystem serving millions of users with never more than three developers on staff at any given time. While other companies were hiring massive engineering teams, we took a completely different approach.
The Multi-Modal Developer Philosophy: Instead of hiring specialists, we focused on finding developers who could wear multiple hats effectively. Each team member needed to be comfortable with:
- Frontend and backend development - No "I only do React" or "I'm just a backend person"
- DevOps and deployment - Everyone understood the full pipeline from code to production
- Database design and optimization - No separate DBA team; developers owned their data
- Third-party integrations - Critical for working with our inherited WordPress ecosystem and external partners
This wasn't about overworking people—it was about building a team of true full-stack professionals who understood the entire system.
Efficiency Through Constraints: Having a small team forced us to make better architectural decisions. We couldn't afford to build complicated systems that required dedicated teams to maintain. Every technical choice had to be:
- Simple enough that any team member could understand and modify it
- Well-documented because we couldn't rely on institutional knowledge
- Automated wherever possible to reduce manual operational overhead
- Designed for reliability because we didn't have an on-call rotation
Strategic Use of CI/CD and Cloud Infrastructure: With only three developers, our CI/CD pipeline and Google Cloud infrastructure weren't just nice-to-haves—they were absolutely critical. We automated everything we could:
- Automated testing caught issues before they reached production
- Automated deployments meant we could ship code confidently without manual processes
- Automated monitoring alerted us to problems before users noticed
- Managed cloud services eliminated the need for dedicated infrastructure specialists
Global Reach with Distributed Efficiency: Our small team was globally distributed, which actually became an advantage. We had coverage across time zones without the overhead of a large organization. When a critical issue came up, someone was always awake to handle it. But more importantly, the geographic distribution forced us to build systems that didn't require constant human intervention.
The Power of Saying No: Perhaps most importantly, staying small forced us to be incredibly disciplined about what we built. Every feature request got filtered through the question: "Is this worth the ongoing maintenance burden for our small team?" This led us to build fewer features, but build them really well.
The result was a lean, efficient operation that could respond quickly to business needs while maintaining the reliability and performance that our global instructor community depended on.
Build Systems That Can Handle Success
Nothing breaks a growing business faster than systems that can't scale. With only three developers, we couldn't afford to rebuild everything when we hit growth milestones, so we had to make smart architectural decisions from the beginning.
Infrastructure Built for a Small Team
When you only have three people managing a global platform, your infrastructure choices become critical. We couldn't have someone on call 24/7 or dedicated operations people, so everything had to be designed for reliability and self-healing.
Our approach was to scale horizontally using containerized services on Google Cloud Platform. This wasn't just about handling more users—it was about building systems that could handle traffic spikes, geographic distribution, and maintenance windows without requiring constant human intervention.
Here's a simplified view of our architecture:
# Example: Containerized microservices architecture
services:
web:
image: pound/web-app
replicas: 3
environment:
- DATABASE_URL=${DATABASE_URL}
- REDIS_URL=${REDIS_URL}
api:
image: pound/api-server
replicas: 5
environment:
- DATABASE_URL=${DATABASE_URL}
- STRIPE_KEY=${STRIPE_KEY}
worker:
image: pound/background-worker
replicas: 2The beauty of this setup was that Google Cloud's managed services handled most of the operational complexity. We got automatic scaling, health checks, and load balancing without having to build or maintain those systems ourselves.
Database Decisions That Saved Us Later
I learned early on that database design mistakes are expensive to fix later. With a small team, we couldn't afford major migrations or performance crises, so we had to get the fundamentals right from the start.
We invested time upfront in proper indexing for our most frequent queries, especially around instructor lookups and subscription status checks. We also set up read replicas early, even before we strictly needed them, because we knew that analytics and reporting queries would eventually slow down our main application if we weren't careful.
One decision that paid huge dividends was implementing a data archiving strategy from day one. Instead of letting old subscription data accumulate indefinitely, we moved inactive records to cold storage. This kept our active database lean and fast, even as we scaled to millions of users.
Monitoring: Your Early Warning System
When you're a small team supporting a global platform, you need to know about problems before your users do. We couldn't rely on users reporting issues—by then, it might be too late.
We implemented comprehensive monitoring that covered both technical metrics and business indicators. Our monitoring setup would alert us if response times increased, if subscription sign-ups dropped below normal levels, or if payment processing started failing. The key was setting up alerts that were actionable and urgent, not just informational noise.
This monitoring setup was what allowed our small team to maintain high reliability even across different time zones. When something went wrong, we had enough context to diagnose and fix it quickly, often before it significantly impacted users.
E-commerce Lessons: The Details That Almost Broke Us
Building e-commerce systems taught us that the devil is truly in the details. What looks simple on the surface—"let people buy things"—becomes incredibly complex when you're dealing with global customers, multiple currencies, and subscription billing.
Payment Processing: More Complex Than You Think
Handling money sounds straightforward until you actually try to do it. Our subscription business meant we weren't just processing one-time payments—we were managing recurring billing for instructors around the world, each with different payment preferences and local requirements.
The complexity really hit us when we started serving international markets. We had to support multiple payment methods because what works in the US doesn't necessarily work in Europe or Asia. Apple Pay was popular in some regions, PayPal dominated others, and traditional credit cards were still the standard in many places.
But the real nightmare was subscription billing with upgrades, downgrades, and prorations. When an instructor wanted to upgrade their subscription mid-cycle, we had to calculate exactly how much to charge them, when to bill them next, and how to handle their new billing cycle. Get this wrong, and you either lose money or upset customers.
Failed payment handling became an art form. We learned that the first failure isn't usually permanent—cards expire, banks have temporary issues, people change payment methods. But we had to be smart about retry logic and customer communication. Too aggressive, and you annoy people. Too passive, and you lose revenue.
The Merchandise Side: Physical Products Are Hard
While our main business was digital subscriptions, we also had a merchandise operation that taught us why software companies avoid physical products. Digital products are infinitely scalable—you can sell the same workout video to a million people without additional inventory costs. Physical products are the opposite of that simplicity.
Real-time inventory tracking became critical when we started selling fitness equipment and apparel. Nothing frustrates customers more than ordering something that's actually out of stock. But tracking inventory across multiple warehouses, with different lead times and supplier relationships, required systems that were as complex as our main subscription platform.
Shipping integrations were another layer of complexity. Different carriers for different regions, different pricing structures, different delivery expectations. And then there's returns and refunds—a whole workflow that doesn't exist in the digital world.
This is why we eventually moved the merchandise operation to its own WordPress multisite. It wasn't that we couldn't handle the complexity in our main system, but the operational overhead wasn't worth it for our small team. Sometimes the best technical decision is to keep things separate.
Customer Support: Technology Should Empower, Not Replace
One of our best decisions was building admin tools that made our support team more effective rather than trying to automate everything. We learned that while customers might be okay with self-service for simple things, complex subscription and billing issues needed human intervention.
Our support tools aggregated customer data from across all our systems—subscription history, payment issues, content access, support ticket history—into a single view. When a customer contacted us, our support team could see their complete relationship with POUND without having to switch between different systems or ask the customer to repeat information.
We also built smart escalation workflows. Simple issues like password resets could be handled immediately, but billing disputes or technical problems got routed to team members with the right expertise. This kept our small support team efficient while ensuring customers got the help they needed.
The Platform Strategy That Kept Us Lean
Instead of building separate applications for each use case, we created a unified platform approach. This was partly born out of necessity—with only three developers, we couldn't afford to build and maintain completely separate systems for web, mobile, admin tools, and third-party integrations.
Shared Components: Build Once, Use Everywhere
Our authentication system became the foundation for everything. Whether an instructor was logging into the web portal, using the mobile app, or accessing admin tools, they were using the same underlying authentication and user management system. This meant we only had to solve problems like password resets, account security, and user permissions once.
The same principle applied to our payment processing, content management, and analytics systems. Every new application or feature could leverage these shared components, which dramatically reduced development time and maintenance overhead.
API-First: The Decision That Saved Us
Building everything API-first wasn't just good architecture—it was survival strategy for a small team. When our mobile app partner needed to integrate with our platform, they could use the same APIs that our web application used. When we needed to build internal admin tools, we could rapidly prototype them using existing endpoints.
This approach also made testing much more manageable. Instead of testing the full user interface for every feature, we could test the API endpoints directly and know that any application using those APIs would work correctly. For a three-person team, this kind of efficiency was critical.
Third-party integrations became straightforward because our platform was already designed to be consumed by external applications. When we needed to connect with new partners or services, we were usually just adding another API consumer rather than building entirely new integration patterns.
Managing Technical Debt While Growing
Growing companies accumulate technical debt quickly, but most advice about managing it assumes you have a large team with dedicated time for refactoring. With only three developers supporting a global platform, we had to be strategic about when and how we addressed technical debt.
The 80/20 Rule for Refactoring
We learned that most of our problems came from a small portion of our codebase. Instead of trying to keep everything perfect, we focused our refactoring efforts on the 20% of code that was causing 80% of our issues—usually the core subscription logic, payment processing, and user authentication systems.
Before any major refactoring, we measured the current state so we could prove the value afterward. This wasn't just about performance metrics; we tracked developer productivity, bug reports, and time spent on maintenance. Being able to show stakeholders that refactoring reduced support tickets or enabled faster feature development was crucial for getting buy-in.
Strategic Technical Debt
Not all technical debt is bad, especially when you're moving fast with a small team. We deliberately took shortcuts when shipping new features quickly was more important than perfect code. The key was being intentional about it.
We documented every shortcut we took and why we took it. This created a backlog of known issues that we could address when we had capacity, rather than letting technical debt accumulate invisibly. We also set aside time each sprint specifically for debt reduction—not enough to slow down feature development, but enough to prevent the debt from becoming unmanageable.
The principle "don't let perfect be the enemy of good" became our mantra. We shipped working solutions that solved real business problems, then improved them iteratively. This approach let us respond quickly to market opportunities while maintaining a sustainable codebase.
The Numbers: What Success Looked Like
After six years of building and refining our lean approach, the results spoke for themselves. We generated over $50M in total revenue while maintaining some of the leanest operational costs in the industry. What made this particularly meaningful was achieving 300% year-over-year growth during our peak years while keeping our core engineering team at just three developers.
We served instructors in over 40 countries, maintaining 99.9% uptime across all systems. This level of reliability was crucial for our global instructor community, many of whom depended on our platform for their livelihood.
From a technical perspective, our small team managed to support over 2 million registered users across multiple platforms, with peak concurrent usage reaching 50,000 users during major training events. We built and maintained applications for iOS, Android, Apple TV, Roku, and web—all while keeping our core development team lean and efficient.
Our deployment process evolved from manual, anxiety-inducing releases every two weeks to confident daily deployments through our automated CI/CD pipeline. This wasn't just about speed—it was about reliability and the ability to respond quickly to business needs.
Perhaps most importantly, our focus on user experience design and intuitive interfaces resulted in a 60% reduction in customer support tickets over three years. When you have a small team, every support ticket represents time that could be spent building new features, so this efficiency gain was crucial.
We consistently delivered 90% of planned features on time and within budget, largely because our constrained team size forced us to be realistic about scope and ruthless about priorities.
Key Takeaways for Technical Leaders
Business Alignment Changes Everything
The biggest mistake I see technical leaders make is building for technical elegance rather than business value. Every architectural decision, every tool choice, every process change should support specific business objectives. When our business needed to expand internationally, we prioritized multi-currency support and localization over performance optimizations that would have been more interesting to build.
Small Teams Can Outperform Large Ones
Conventional wisdom says you need large engineering teams to build large systems. Our experience proves that's not always true. A small team of versatile, skilled developers can often outperform a larger team bogged down by communication overhead and process complexity. But this only works if you hire the right people and build the right systems.
Success Requires Planning for Success
One of our smartest early decisions was building systems that could handle 10x our current scale, even when we weren't sure we'd ever reach that size. This meant choosing databases that could grow with us, APIs that could handle increased load, and infrastructure that could scale horizontally. The alternative—rebuilding everything when you hit growth milestones—is much more expensive and risky.
Measurement Drives Improvement
We implemented monitoring and analytics from day one, tracking everything from technical performance metrics to business indicators. This data-driven approach let us make confident decisions about where to invest our limited time and resources. Gut feelings are fine for inspiration, but data should drive decisions.
Communication Is Your Superpower
The ability to explain complex technical concepts to non-technical stakeholders became one of my most valuable skills. When you can clearly articulate why a particular architectural decision will save money, improve user experience, or enable new business opportunities, you get the buy-in and resources you need to build systems the right way.
Technical Debt Is Strategic Debt
We managed technical debt like financial debt—some was strategic and valuable, most needed to be paid down regularly. The key was being intentional about when we took shortcuts and having a plan for addressing them later. This let us move fast when speed mattered while maintaining long-term sustainability.
Looking Forward
The lessons from building POUND's digital ecosystem continue to influence how I approach technology leadership today. The fundamentals haven't changed: understand the business deeply, build efficient teams, create scalable systems, measure relentlessly, and communicate effectively.
What's evolved is my appreciation for the power of constraints. Having only three developers forced us to make better decisions, build simpler systems, and focus on what really mattered. In many ways, those constraints were the secret to our success.
Whether you're leading a small startup team or trying to optimize a large engineering organization, the principles remain the same: focus on business value, invest in the right people and processes, and never underestimate the power of doing fewer things really well.
What challenges are you facing in scaling your technology organization? I'd love to hear about your experiences and discuss strategies that might help.
