I was a Principal Engineer (and at times Director) at Shopify and worked ~8 years on every aspect of scaling the infrastructure from 100s of RPS to ~1M, from 10s of engineers to 1000s. For 3 of those years I led a lab working on high-risk, high-reward infrastructure investments. I’ve seen every stage of scale: from startup to powering a significant part of the world’s commerce. More
I help companies scale and evolve their web infrastructure.
I will work with you to make the right decision on what to do if your database is shaking at peak loads, you lack a key piece of infrastructure for a product feature, you’re anticipating a serious bottleneck will cripple you soon, have reliability issues, performance problems, or if you are about to make a major infrastructure investment. Ranging from a re-architecture, addressing a single constriction, or help you get out of firefighting.
Making infrastructure decisions that age well is paramount to continue to move fast. Infrastructure development is time-consuming and hard to undo. You’ll be stuck with many of the choices you make for the lifetime of your product. The wrong decisions can cost you 1000s of wasted engineering hours, block product features for long periods of time, and cause serious reliability or performance problems. Making the right decisions can lead to building in a fraction of the time, accelerate your product execution, and keep your stack flexible to support your product’s changing needs.
Fundamentally, I believe in boiling technical decisions down to first-principles, as my Napkin Math series covers. Getting orders of magnitude improvements in system requires thinking from first principles. This is the process I use to solve problems.
Make your infrastructure decisions with someone who’s done it before.
From React to Rails to the Kernel, I work indiscriminately full-stack, but the majority of my experience is with the lower levels of the backend for web applications. Especially databases and multi-region application architecture.
Serving you a past solution I’ve seen and then skedaddle is not my M.O. To get to what will work best for your company, I will do the necessary work to understand your stack and team, read code, write prototypes, and do research.
Typically, we’d set up an agreement where I meet with the relevant technical person / CTO a few times a month to discuss key issues. From there, we coordinate projects to zoom in on for a few hours or days, or full sprints of up to 6-8 weeks to tackle larger issues. I work with a few companies at once, and you can think of me as a Principal Engineer across companies rather within a company across teams.
I want to be invested in the success of your business, so I prefer to work for mostly equity.
Tell me at
email@example.com what you’re
struggling with, and we’ll set up an informal intro call!