Projects

Systems I built

Four products, written up the way I would explain them in an interview: what the constraint was, what I chose, and what the choice cost.

Ingests leads and dispatches each one to multiple third-party buyer APIs. The interesting part is not the request rate — it is that every lead multiplies into several outbound calls.

Inbound load tested: ~10k requests over ~4 minutes
Outbound workers: ~300 per instance
Peak fleet: ~30 instances (hard cap 50)
Instance type: AWS t4g.small

The constraint that shaped everything

A lead arrives once and leaves several times: each one is dispatched to multiple buyer APIs, each of which can fail, slow down or reject independently. That makes capacity a function of outbound concurrency, not of how many requests arrive per second. Optimising inbound throughput would have solved the wrong problem.

Three architectures, same product

Native PHP built for throughput under shared hosting (2012). Then AWS Lambda and API Gateway (2016), trading server administration for managed scaling and accepting cold starts. Then a rebuild of the dispatch layer in TypeScript with BullMQ and a Redis Cluster (2025), because the queue semantics and visibility the previous stack could not give me were now the requirement.

Scaling ahead of demand instead of reacting to it

A new t4g.small takes one to two minutes to become ready, and the traffic bursts I designed for last about four. A reactive autoscaler would deliver capacity after the burst was already over. So a controller watches live concurrency and provisions workers ahead of the curve, with the trigger threshold calibrated from load tests rather than guessed. The hard cap of fifty instances is a cost guardrail, not a technical limit.

How the numbers were obtained

Automated campaigns sending POSTs, with concurrency, queue depth and database connections read from CloudWatch, Bull Board and PgBouncer. This was a load test, not customer traffic — the distinction matters and I keep it explicit.

PHP · TypeScript · AWS Lambda · API Gateway · BullMQ · Redis Cluster · PostgreSQL · PgBouncer

A complete commercial product: front end, back end, API, payment-free licensing and a WordPress plugin that distributes it.

What it does

Generates SEO-oriented articles automatically, with multiple export formats, behind a React and TypeScript interface over a MySQL back end and a proprietary API.

The part most people skip

A SaaS is not only the application. It needs distribution, and that came from the official ArticleAI Fetcher plugin published on wordpress.org — an install path for people already running WordPress rather than another signup funnel to build.

React · TypeScript · MySQL · WordPress plugin

Three unreliable external sources — telephony events, public complaint data and scraping — normalized into one signal a customer can act on.

Normalising three bad sources into one good answer

Twilio supplies call events, the FTC supplies complaint data, and scraping fills the gaps between them. Each source has its own latency, its own idea of what a phone number looks like, and its own way of being temporarily unavailable. The product is the reconciliation, not the integrations.

Commerce built in

Access is sold through Stripe behind a dashboard, which means the integration surface includes billing state, not only the detection logic.

PHP · Twilio · Stripe · MySQL · jQuery

One REST API behind three clients: a web application, an Android app and an administrative dashboard.

One API, three consumers

Appointments, inventory, clients and reporting, served to a web app, a native Android client and an admin dashboard. The API contract had to be stable enough that three independent interfaces could ship against it without stepping on each other.

PHP · MySQL · REST · Android

Also

WordPress multisite optimisation for a US client: stabilised 30 sites on shared hosting through selective plugin loading, caching and bot filtering.
Multilingual Next.js site for rapidpersonalloans.com/es.
Airbnb calendar integration for metrorailhouse.com.

The source code for all of these is private, and most are no longer under my administration. What follows describes what I built and the decisions behind it — no client code, credentials or confidential data.