Systems That Don't Break

Every client building a web app or platform eventually asks the same question: will this thing hold up?

Here's how I think about scale, drawn from three production systems I've built.

Captain HQ was a fintech platform managing the full lifecycle of home repair claims, from submission through payment. I joined as the first developer hire and built the core infrastructure.

The system processed $1M in total volume across claims, payments, and contractor workflows. That meant:

Dual payment processing through both Dwolla and Stripe, handling real money flows between homeowners, contractors, and the platform

A legal compliance engine that automated state-by-state claim validation on every submission, replacing what would otherwise be manual legal review

Multiple concurrent user types (homeowners filing claims, contractors in the field on mobile, ops teams managing workflows) all hitting the same system simultaneously

Automated document generation for legal and operational paperwork, reducing manual bottlenecks

Captain HQ was later acquired. The platform held up.

Black UX Labs needed an AI-powered career discovery platform for a large-scale research study. I led product and engineering.

The system ran 500 participants through a multi-stage AI agent pipeline: resume analysis, scoring, automated query generation, and broad opportunity discovery across multiple external APIs. The architecture:

FastAPI backend handling concurrent requests across the full participant pool

Multi-model LLM orchestration routing tasks to the right model (Fireworks AI Llama for fast function calling, GPT-4 for higher-reasoning steps)

External API integrations (Exa AI search) that needed to stay responsive under load

The platform achieved a passing satisfaction rate across the full 500-participant cohort and won the Goodie Nation x Google for Startups workforce grant based on its impact.

CulinaryHR is a structured hiring platform for restaurant kitchens, built as a two-sided marketplace with real-time evaluation tracking during live working interviews.

The infrastructure choices here are deliberate:

Convex for the real-time backend and database, built for concurrent state management

Vercel for auto-scaling deployment

TanStack for routing and data management

When a chef is being evaluated during a live stage, the system needs to handle real-time data from evaluators, update dashboards for restaurant managers, and track retention metrics at 30, 60, and 90 days. The architecture is designed so adding more restaurants and more concurrent stages doesn't require rethinking the foundation.

Scale isn't just about handling traffic spikes. It's about choosing infrastructure that doesn't need to be rebuilt when usage grows, separating concerns so one part of the system failing doesn't cascade, and building with payment processors, databases, and hosting providers that have their own reliability guarantees baked in.

The pattern across all three: pick boring, proven infrastructure for the critical paths, and save the creative engineering for the parts that actually differentiate the product.