The work that starts after merge
Shipping code isn't the end of the job. For a small team, I own the seam between 'merged' and 'working in production' — the staged release path, and the live-ops that keeps thousands of clinics running. This is the case study about why owning production is a design input, not a chore that comes after design.
I joined a seven-person team a few months in, brought on as the experienced engineer for the complex modules. That's how the case studies here started. But over three years my role widened past writing the hard module: I became the person who gets the team's work to production and keeps it running there.
This is the least glamorous work I do, and I'd argue it's some of the most valuable. It's also where I have to be most careful about what I claim — so I'll be exact: I enforce and own the release path; I did not design it. That precision is the point of the whole case study.
Shipping code isn't the end.
It's the start of the responsibility.
A feature being merged and a feature working for a clinic are separated by two seams that a small team rarely staffs — and where things break quietly if nobody owns them.
The release seam. Seven engineers merging across six-plus services through staged environments. Without one person integrating and de-conflicting, the wrong version wins a merge, a change silently doesn't make it to live, or two features collide in a way no single author can see.
The production seam. A clinic's data is corrupted — duplicate patients, a broken blockout, a bad sync. Who notices, who diagnoses it, and with what tools? Without an owner and repeatable tooling, every incident is bespoke firefighting and the client notices before we do.
Neither seam is a feature ticket. Both are where a healthcare platform earns or loses trust. The problem I took on was making both seams have an owner — and letting what I learned at them change how I build in the first place.
Seven engineers, six-plus services.
Real-shaped verification before anything nears clinics.
A staged line between beta and live.
3,500+ clinics depending on it.
Two standing roles, neither of which is a feature assignment. The numbers below are read from commit history, not memory — activity, not a hero metric.
I merge the team's work to production.
Integrating and de-conflicting the team's branches through each staged environment, enforcing the process, and making sure the right version lands at every promotion.
The hard client bugs route to me.
Ticket-driven bug and hotfix resolution, plus data-repair scripts for corrupted client data — duplicate patients, providers, blockouts, and outage recovery.
The failure modes I've watched a small team fall into, and the stance I hold instead.
Everyone self-merges to production
FailsFast until two changes collide across services with no one holding the whole picture. On a healthcare platform, a silent bad merge to live is a clinic-facing incident.
Fix corrupted data ad-hoc, by hand
FailsA one-off query under pressure is how you turn one broken clinic into two. No reuse, no review, no audit trail — the opposite of what production data deserves.
Big-bang ship, hope it holds
FailsSkipping the soak on hot, high-blast-radius code trades a few days of patience for an outage across thousands of clinics. Never worth it.
A human gate + reusable tooling + de-risked rollouts
What I doOwn the gate, turn repair into reusable scripts, soak hot changes in beta, and surface failures fast — while being honest that the right long-term answer is to automate the gate away.
Five practices — the ones that make owning production a discipline rather than a scramble.
Hold the release gate
Integrate and de-conflict the team's work through each staged environment; make sure the right version wins every promotion and nothing is silently dropped on the way to live.
Soak hot changes before they ship
Behavior-preserving refactors on the highest-blast-radius code, verified locally and soaked in beta, rolled out staged — never a blind big-bang on the paths clinics depend on.
Make failures surface, don't wait to be told
Route errors from the hottest service into a chat-based alert feed during a modernization pass, so a failure shows up to us as a message rather than as a client complaint days later.
Turn repair into reusable tooling
When client data breaks — duplicate patients, providers, phone records, blockouts — I write it up as a repeatable repair script, not a one-off query. The second incident of a kind should be cheaper than the first.
Scale myself through delegation
Design the complex or high-risk part, define the contract, hand implementation to a teammate, and mentor — as I did designing the AI voice-booking backend and then mentoring a junior on it. Ownership isn't hoarding the work.
Owning production
changes how you design.
Every reliability pattern in these case studies is production pain, fed back into design.
This is why I keep owning the seam. When you're the one who gets paged, you stop designing for the happy path — the failure modes become the first thing you reach for, because you're the one who'll live with them.
Logs lost under load. A change reverted by a stale sync. A 12-second page.
Durability over speed. A dirty-flag guard. Measure before you touch it.
Built with the failure mode designed out from the start.
Losing logs under load taught durability-first — at-least-once + idempotency.
Clients losing changes taught the dirty-flag guard — never clobber a pending write.
A hot path timing out in prod taught: instrument first, and design so the fix is one module.
A human gate
Soak over speed
Repair scripts
On being precise: the release process was designed before I arrived, and I co-own its enforcement with another senior engineer. My credible claim is operational ownership and technical leadership — not process design, and not sole authorship.
Merges shepherded through staged environments across the team's services — the release path had a reliable owner, co-held with one other senior.
releaseClient-bug and hotfix commits in the past year, ticket-driven — the hard ones routed to me, plus reusable data-repair scripts for corrupted records.
live-opsSystems I designed, then delegated and mentored others to build — the AI voice-booking backend among them. Owning production includes growing the people who'll run it.
leverageThe instinct I'd keep. The manual parts I'd engineer away — most of what I'd change removes me as a dependency.
Automate the gate away
CI checks and promotion automation that enforce the same discipline a human does at each stage — so the process doesn't depend on a specific person being available. Turn the bus-factor into a pipeline.
Detect corruption before the client does
A data-integrity monitor for the common failure shapes — duplicate patients, orphaned blockouts, stalled sync — so "a client reported broken data" becomes "we caught it and repaired it first."
Promote repair scripts into guarded admin tooling
The ad-hoc scripts should become reviewed, audited, permissioned operations anyone on the team can run safely — repair with a trail, not a senior engineer with a keyboard and a production connection.