Production Engineering
What I learned shipping software to 100K+ users.
July 23, 2026 · 6 min read
Past a certain number of users, software stops being something you build and becomes something you operate. These are the lessons that stayed with me from working on mobile products used by more than 100K people, and on health software that reached over 125K patients.
The long tail is the product
At small scale you test on your own phone. At scale, the old Android device with little free storage, the user who has not updated in months and the patchy network are no longer edge cases — they are a meaningful share of your users. Designing for them is not polish; it is the job.
Boring releases are a feature
Mobile releases cannot be rolled back the way a server deploy can. That makes staged rollouts, feature flags, crash monitoring and automated CI/CD more valuable than any individual feature. The goal is releases so routine that nobody schedules a meeting about them.
Reliability is the feature users never ask for and always notice.
Trust compounds
In field operations and healthcare alike, people build their routines around software that works. A single lost record costs more trust than ten new features earn. That shifts priorities: data integrity first, performance second, new capability third.
I build and lead teams around systems where reliability matters. If you're designing an offline workflow, evaluating an architecture, or untangling a queue that has become part of your product, I'm happy to compare notes.
More writing
- React Native Architecture Decisions That Become Expensive Later
React Native · 7 min read
- Why Good Engineers Care About Failure Modes
Distributed Systems · 5 min read
- What Engineering Managers Should Actually Measure
Engineering Management · 6 min read