Case studies

org

Solving the problem: one engineer can work on a codebase at once

One engineer per project was the ceiling. Using tooling and process to clear bottlenecks.

1 → 12 engineers per release

Situation: One project, one engineer. Having two people work together required a great deal of coordination and communication.
Constraint: Two or more engineers trying to work together could easily override each other's work. Config might be stored in the database and require extensive manual steps for deployment. This slowed down development cycles and forced every engineer to be a full stack expert; there was little room for a junior.
Decision: Switch to git and adopt GitLab. Start using a development workflow with merge requests and timed releases. We ignore vanilla scrum and gitflow in favor of semantic git.
Tradeoff: Dynamic content is no longer in version control. Branching with multiple developers is possible in SVN, but git is easier to manage and has better tooling and developer experience.
Result: Two engineers on a release used to be a struggle; five became routine, and over twelve during crunch periods. Any project could take any number of engineers at any time, and a release no longer waited for the one person with the expertise to be free.

Read the full case study

scaling

Serving 20 million objects for nearly nothing

Using AWS serverless to build a COPPA-compliant save-and-share feature that has run for ten years.

20M objects · 10 years · 100% uptime

Situation: Our client wanted a way to save and share the current state of the application.
Constraint: The audience was four-year-olds, so the feature had to comply with COPPA. Technically it had to scale from zero users to thousands while keeping storage and maintenance costs to a minimum.
Decision: I chose AWS serverless for the application and S3 for storage, deployed through AWS SAM, which was new at the time.
Tradeoff: Hosting the service on a dedicated machine was the comfortable route. It would have meant a beefy box, or several boxes and a load balancer, sized for a peak we could not predict. AWS's managed services ticked every box, and the free tier made it cheap to find out whether an unproven system would hold.
Result: Prototyped in 2016, launched in 2017, and still running mostly the code I wrote then. Seven contributors across five releases, most of them maintenance or language-compatibility updates. Ten years at 100% uptime. The monthly bill is S3 storage and bandwidth on more than 20 million objects and roughly a terabyte. For a well-architected system at a certain scale, serverless is unbelievable.

Read the full case study

strategy

The process I rewrote before it became the bottleneck

A release process built to let a dozen engineers share one codebase was the wrong shape now that writing code is no longer the hard part.

Situation: The department ran on a release process I had written years earlier, and it worked: merge request per feature, review and sign-off before merge, releases cut on a timed cadence. Management asked me to find out what GenAI did to that, and by the end of 2025 the answer was that we had made the first weeks of a project faster and the engineering needed clearer requirements before serious work could start.
Constraint: The gate that made a twelve-engineer release safe stood in front of a one-engineer prototype and charged the same toll. Removing it to keep up with the tooling meant giving up the thing the gate was there to protect, and keeping it meant giving up the only real advantage the tooling offered.
Decision: Split the lifecycle into three funded phases instead of tuning the gate. Discovery produces a functional prototype fast, with engineering consulted rather than staffed, and its only job is a working baseline the client can argue with. Engineering then takes that baseline under Mark Cerny's pre-production method and develops it into a finished demo, which is the artifact the estimate gets written against: a date the client signs against and a token budget the shop holds itself to, both measured on a real build rather than guessed. The final build is scoped for maintainability and the decade after launch, because by then the features are already settled. The rejected alternative was to keep the existing process and simply run it faster, which fails because the cost was structural rather than a matter of pace; the other rejected alternative, shipping the prototype as the product, is the race to the bottom, since a prototype that survives contact with a client is not maintainable by default and pretending otherwise moves the bill to the next cycle.
Tradeoff: A functional prototype looks finished to the person paying for it, so managing that expectation became part of the job rather than an afterthought. Engineers inherit code from a phase where velocity was the point, the audit that follows has to be scheduled as real work rather than absorbed, and a method that bills the first two phases has to survive a sales conversation that would rather quote the prototype and be done.
Result: Three phases, two of them funded and delivered before a line of production code is written, and an estimate that arrives as a date the client signs against and a token budget the shop holds itself to, rather than a range. The number the method has to answer for is the gap between the demo's measured burn rate and the final build's, because that gap is the whole bet.

Read the full case study

tooling

The five-hour window, and the report nobody was there to start

A scheduling daemon for headless Claude Code sessions, managed through MCP because the users were not engineers and I was not building a GUI.

12 MCP tools · 0 lines of UI

Situation: Engineers on Claude Code subscriptions were losing capacity to the clock. The usage window is five hours long and it starts on your first prompt of the day, so a team that all sits down at nine is all locked out at two, in the middle of the afternoon.
Constraint: Anything that fixed it had to run with no terminal attached, which meant no interactive permission prompt, no TTY and, on macOS, no access to the credentials the interactive client had saved. It also had to be usable by producers and project managers, not only by the people who would happily hand-edit a TOML file.
Decision: I wrote blanket: a Go daemon that schedules Claude Code sessions on cron expressions and one-off delays. It drives Claude over the Agent Client Protocol rather than shelling out to `claude -p`, so the daemon itself answers the permission requests, and it exposes its whole management surface as an MCP server rather than a web UI.
Tradeoff: Making MCP the interface meant the interface is only as good as the model in front of it, and it has no authentication of its own: the trust boundary is the operating system's, so anyone who can run the binary as you can schedule anything, anywhere.
Result: Sessions fire at six in the morning. The window opens before anyone sits down and closes at eleven, and the morning report is finished and waiting instead of being something you start and then watch. Twelve MCP tools cover the entire CLI surface, and the GUI on the todo list never had to be written.

Read the full case study