Commerce & platforms
Scaling a Multi-Tenant NFC Platform
Led a team to modernize infrastructure and build a platform that scales to thousands of users.
- Deploy Speed60% faster
- Scale1000+ concurrent users
- TeamLed 5 engineers globally
Problem and stakes
HELPAR needed to modernize their aging CRA app and build a new multi-tenant NFC platform for brands to track product interactions. I joined to lead the rebuild and architect the new platform.
- Legacy CRA app: Slow deploys, poor developer experience
- Multi-tenancy requirements: Needed to support multiple brands with isolated data
- Scale challenges: Needed to handle thousands of concurrent users
- Distributed team: Managing engineers across multiple time zones
My role
- Role
- Head of Engineering
- Stage
- Series A, scaling phase
- Team
- Led 5 engineers (global team)
Strategy and decisions
Led migration to Next.js Turbo monorepo
Modern infrastructure
- Migrated from CRA to Next.js 14 with Turbo
- Reduced deploy times by 60%
- Improved developer experience with faster builds
- Set up shared component library across apps
Architected multi-tenant NFC platform
AWS serverless infrastructure
- Built on AWS Lambda, DynamoDB, and S3
- Designed tenant isolation and data security
- Created analytics dashboards for brands
- Integrated NFC tag reading and tracking
Scaled to thousands of concurrent users
Zero downtime
- Implemented auto-scaling infrastructure
- Optimized database queries and caching
- Set up CDN and edge caching
- Monitored performance and fixed bottlenecks
Outcomes
- Reduced deploy times by 60%Team can ship features faster with confidence
- Scaled to 1000+ concurrent usersZero downtime, auto-scaling infrastructure
- Enabled multi-brand platformBrands can track customer interactions post-purchase
- Improved team velocityBetter tooling and processes for global team
Evidence
Optional layers for anyone who wants to inspect the reasoning.
Architecture
Decision log
How to rebuild the legacy app
Options considered
- Keep improving the existing Create React App build
- Migrate to a Next.js Turbo monorepo with a shared component library
Chose A Next.js Turbo monorepo with a shared component library across apps
Why Faster builds and deploys, and one set of components instead of copies per app.
How to serve many brands
Options considered
- A separate deployment per brand
- One multi-tenant platform with tenant isolation
Chose One multi-tenant platform, with each brand's data isolated
Why One platform serves every brand while each brand's data stays separate.
How to handle load
Options considered
- Servers sized in advance
- Serverless functions with auto-scaling, plus CDN and edge caching
Chose Serverless functions with auto-scaling, plus CDN and edge caching
Why Capacity follows demand instead of being sized ahead of time.
Trade-offs
- Moving to a monorepo pauses some feature work while the foundation changes underneath it.
- Serverless keeps operations small, but cold starts and local debugging become things to design around.
What's public and what isn't
The figures on this page (deploy-time reduction, concurrent users, team size) come from my own records of the engagement. They are not independently published.