01+
Operational Friction
- Agencies relied on phone calls, texts, and spreadsheets to fill shifts
- Workers had no centralized way to discover jobs or track schedules
Multi-Tenant Infrastructure
Multi-Tenant Deployment Infrastructure for 50+ Customer Apps
Configuration-driven platform and CI/CD infrastructure that deploys 50+ branded customer applications from a single codebase — 1,000+ production releases
50+ apps
1,000+ releases
35% faster release velocity
Context
I worked at WOLF, an Austin-based startup operating as a Shopify-like platform for staffing agencies — instead of online stores, each agency received their own branded mobile app and web portal to manage workforce operations.
- Shopify-like model — each staffing agency gets their own branded mobile app and web portal
- Workers interact like Uber — discover nearby jobs, book shifts, check in/out, log timesheets
- Single multi-tenant React Native codebase powers all 50+ branded app variants
- Verticals include healthcare, dental, hospitality, light industrial, and education staffing
One Codebase · 50+ Apps
10 shown · 50+ in production
Problem
Powering 50+ branded apps from a single codebase solved the scaling challenge — but it created a critical bottleneck in how those apps were built, tested, and shipped.
02+
Scaling Problem
- Each agency needed its own branded mobile experience to compete
- Building and maintaining a custom app per client was not viable
03+
Engineering Challenge
- Power 50+ distinct branded apps from a single codebase
- Per-tenant configuration, branding, and feature flags
Release Pipeline
Before this system existed, mobile releases were entirely manual. Engineers built apps on local machines, ran tests locally, and uploaded builds to TestFlight and the Play Store by hand — a process that took over an hour per app and depended on specific people and machines. With 50+ tenant variants, this became a critical bottleneck.
✕
Manual Releases
- ✕Local builds on developer machines
- ✕Manual testing and validation
- ✕Per-tenant builds handled sequentially
- ✕Manual upload to TestFlight / stores
- ✕Releases dependent on specific engineers
→
✓
Automated Pipeline
- ✓Fully automated CI/CD pipeline
- ✓Parallel builds across 50+ tenants
- ✓Automated testing and validation gates
- ✓Centralized signing and distribution
- ✓Deterministic, repeatable releases
Pipeline Architecture
PR Merge
GitHub Actions
E2E Smoke Tests
Katalon Studio
Parallel Build Matrix
GitHub Actions
Code Signing
Fastlane
Beta Distribution
TestFlightGoogle Play Console
QA Sign-off
Production Release
Key Stages
01
E2E Smoke Tests
Katalon StudioKatalon runs critical path tests across all variants before any builds begin, catching regressions early.
02
Parallel Build Matrix
GitHub ActionsAll 50+ tenant variants build simultaneously using a GitHub Actions matrix strategy, reducing total build time from hours to minutes.
03
Code Signing
FastlaneShared Apple team certificate with per-tenant provisioning profiles. Centralized signing across all variants without per-tenant certificate overhead.
Key Decisions
01
Single configurable codebase over per-client forks
The core platform decision. The alternatives were a separate app and repo per client — unmaintainable at 50+ tenants — or long-lived per-tenant branches that would drift and turn every merge into a conflict. I chose one multi-tenant codebase where branding, feature flags, and per-client rules are configuration, not code. The consequence: a fix or feature ships to all 50+ apps at once, and onboarding a new client is configuration work rather than a fork — the reason 50+ apps and 1,000+ releases stayed sustainable for a small team.
02
Code review as the release gate
With every tenant sharing one codebase, a single bad merge could regress all 50+ apps. I made review plus an automated E2E smoke gate a required step before any build ran, so release quality didn't depend on individual diligence. This standardized how the team shipped and directly fed the 35% release-velocity gain — fewer broken releases meant fewer rollbacks and hotfixes.
03
Why GitHub Actions
Chose GitHub Actions to keep CI/CD tightly integrated with the repository, enabling standardized workflows, centralized secrets management, and easier scaling across multiple tenants without introducing another external CI system.
04
Why Fastlane
Used Fastlane as the orchestration layer for mobile releases because it provides reliable primitives for code signing, build automation, and App Store/TestFlight distribution, allowing us to define repeatable release lanes across all tenant variants.
05
Code Signing Strategy
Used a shared Apple team certificate with per-tenant provisioning profiles, allowing us to centralize signing while maintaining isolation across 50+ app variants and avoiding the overhead of managing separate certificates per tenant.
06
Failure Isolation
Designed the pipeline to isolate failures per tenant build, allowing partial success across the matrix while surfacing granular logs and retry paths, preventing a single failing variant from blocking all releases.
35%
Faster Release Velocity
50+
Parallel Builds
0
Manual Steps
Live in Production
10 of 50+ production apps currently managed across the App Store
Impact
50+
Apps Deployed
1,000+
Releases Shipped
35%
Faster Release Velocity
Outcome
Increased release velocity by 35% by replacing manual builds and uploads with a fully automated pipeline. Improved customer retention by 20% and app-store ratings by 25% as delivery became reliable. Shipped 1,000+ updates across 50+ apps with near-zero regressions, backed by observability tooling that caught defects before customers did.
Lessons
Leading a multi-tenant platform at this scale reinforced the importance of architectural decisions that compound — investing in configuration-driven app generation, automated pipelines, and quality infrastructure paid dividends across every client deployment. Just as important was the leverage of standards over heroics: the code-review and release gates I set meant platform quality came from the process, not from any one engineer's diligence, and other engineers shipped confidently through the same guardrails. Cross-functional alignment with sales, product, and implementation teams was critical to translating technical capabilities into measurable business outcomes.