App Ops Desk · Issue #17
Hotfix trains without thrash
A hotfix is a surgical build, not an excuse to merge everything waiting in main. Solo founders lose the week when the fix train becomes a second feature train.
One action this week: Define hotfix eligibility in one sentence: “Production-only blockers that break launch, login, pay, or data.” Put it at the top of your release log.
Hotfix eligibility
- Launch crash / blank screen for many users
- Auth broken
- Payments charging wrong or blocking access
- Data loss / corruption risk
Ugly UI and “nice polish” wait for the normal train.
Process that stays small
- Branch from the shipped tag / last known good SHA
- One commit theme: the fix only
- Bump build number; marketing version only if your policy requires it
- Smoke the archive path that failed in production
- What’s New says what broke and that it’s fixed
- Do not drag feature work from main unless it is required for the fix
Communication
Hotfix 1.6.1 (build 242) Root cause (1 line): Fix: Who should update now: Known remaining issues: Next normal train:
Ignore list
- “While we’re here” dependency upgrades
- Redesigning onboarding mid-hotfix
- Skipping dSYM retention because “it’s small”
Bottom line
Hotfixes are narrow by definition. Branch from good, fix the break, ship, then return to the planned train.
Resources hub → Full library and jump-by-symptom links. Join the App Ops Desk waitlist Weekly release ops for people who ship alone.