ABOUT
Pro Scale Team was formed in 2021 by four operators who kept ending up on the same incident calls at different companies. Rather than wait to meet again on the next one, we assembled deliberately.
WHO WE ARE
We are a partnership, not an agency. There is no bench, no sales team, no subcontracting. Every hour billed is one of ours. We do not plan to grow past six engineers because we have not yet seen a way to do so that does not dilute what the four of us actually sell: taste, judgment, and accountability for the call at 3 a.m.
Between us we have shipped systems at companies in logistics, fintech, developer tooling, healthtech, and streaming media; worked the on-call at three of them during their worst publicly-known outages; and written the postmortems that followed. We have also — more quietly — watched dozens of promising systems accumulate the kind of rot that eventually forces a rewrite. Most of our practice is about preventing that second outcome.
We met, variously, at a database conference in Berlin, on an incident bridge at 04:30 UTC during a Black Friday storm, and on a GitHub issue thread that ran to 180 comments. Two of the four had been co-authors on the same RFC for a queue-semantics proposal at a previous employer. We did not plan to start a firm. It turned out we were already one.
THE FOUR
Partner — Data & Storage
Previously principal engineer on the storage team of a logistics platform moving nine-figure parcel volume. Writes the firm's reference material on Postgres at scale. Keeps a running list of the worst EXPLAIN plans she's ever seen, indexed by species. Based in the Pacific Northwest.
Partner — Queues & Orchestration
Eleven years across two unicorn-scale event pipelines. Particularly interested in the pathologies of "just put it on a queue" culture, and in the specific moment when a scheduler becomes a database without anyone noticing. Based in the North Atlantic.
Partner — Build & Runtime
Formerly staff platform engineer at a developer-tooling company, where she rebuilt a CI system used by seven thousand internal engineers. Holds strong opinions about monorepos, most of them defensible. Can recite the contents of a Dockerfile from memory, which is less impressive than it sounds.
Partner — Observability & Incident
Incident commander on three publicly-reported Sev-1 events at previous employers. Now spends most engagements reducing the probability of the fourth. Believes a good dashboard is one you can read at 03:42 with one eye open, and designs accordingly.
HOW WE WORK
Engagements are fixed-scope and fixed-duration. Before we write any code, we write a memo: what's broken, what we propose to do about it, what the reversal plan looks like, and what will be measurably different at the end. That memo is the contract.
We work in your repo, on your infrastructure, in your Slack channels and issue tracker. We don't ship artifacts to review meetings; we ship merged pull requests. Every engagement ends with a walkthrough for your team and a single handoff document that outlives us. The templates we start from are in the Runbook.
We do not take equity. We do not white-label. We do not speak at conferences as the consultancy, though individually we sometimes do. We have a standing rule among ourselves: no engagement that requires one of us to work past 21:00 local more than two nights in a week. Tired engineers ship the kind of changes that produce the next engagement.
WHAT A WEEK LOOKS LIKE
Most engagements run in a steady rhythm, set in the first week:
If a week goes off the plan, the Friday note says so, and says why. That note is the most important artifact we produce.
ENGAGEMENT
Four engagements a year. Queue orders itself on the referral timestamp.
We only start work off a forwarded roadmap from someone who's been in our git blame. The queue reshuffles when an engagement closes or an ENG-number rolls over; the ledger of open slots lives on a whiteboard in Kahale's home office, not on this page.
If that isn't you yet: the most reliable path we've seen is to ship something hard next to one of our prior clients' staff engineers. Eleven of our last fourteen engagements started with a single Slack DM from someone we've paged with at 03:42 UTC.