Backend and platform engineering for systems that have outgrown their first design

Your system is failing on assumptions nobody revisited

The design was right for its first thousand users. Then write contention builds up on a few hot rows until throughput collapses. Retries and unbounded queues turn a brief slowdown into an outage, because every client helps the overloaded service fail faster. A hot cache key expires and every request hits the database at once.

A schema migration that was instant on a small table locks a large one. Consumer lag grows quietly until a queue is hours behind. A deploy cannot be rolled back because the data has already changed shape. These failures are predictable, which is why each one can be designed against before it becomes the next incident.

You can rebuild a system while it serves traffic

I ran a platform whose traffic was spiky and whose margins were thin enough that a small inefficiency could wipe out its earnings. Servers went down constantly, and vertical scaling and rushed patches did not hold. I rebuilt it while it was live: the system split into smaller services, most backend services rewritten in Go for lower latency and better concurrency, and routing that connected each client to the nearest edge proxy. It stayed profitable throughout.

Your system gets the same order of work: one component, one migration, one deploy pipeline at a time, with the system serving traffic throughout.

Changing the design beats adding servers

On one accounting platform, customer syncs took days and a polling-heavy model was straining as transaction volume grew. I moved it from polling to streaming once historical data was archived, and built a job queue that batches work across customers and reprioritizes accounts by their transaction volume. Syncs went from days to minutes, and full re-syncs stopped being necessary.

A small team can carry launch load

I led the backend for a marketplace launch with a small team: login, payments and checkout, listings, on-chain event ingestion and the data models under them. Load testing and security reviews hardened it ahead of launch day, and it carried real traffic, payments and on-chain events with no critical backend issues. The architecture was then reused for the marketplaces that followed.

I have done this work at around twenty companies

I have done platform and backend engineering at around twenty companies, as a founder, a founding engineer and inside larger organizations. That range is why I start by asking what your system assumes, before asking what to replace.

Platform work is mostly infrastructure work, so my factory covers both

On one infrastructure-heavy platform project, 76% of the merge requests merged touched infrastructure as code. That counts what the work touched, not how long it took. So my software factory works across the service code and what it runs on: Go and Rust services, Kubernetes and Terraform, GitOps and deployment automation, and observability that traces a failure to its cause.

You get a workflow review first and no constant meetings

It starts with a workflow review of how a change moves through your team today, and you leave with a plan either way. After that, my software factory does the volume, I review what it produces, and your team sets the priorities with no constant meetings.

Start with a workflow review, and bring the incident that cost your team the most.