We can’t all afford platform teams and release trains, but perhaps we’ll get there one day if we can avoid committing prod incident seppuku 🗡️.
Startups are a rollercoaster.
Move fast and break things is the mantra, and sacrificing (some!) quality to maximise velocity is the name of the game. YOLO-ing a release to 100% of your users at 11pm is part of the fun.
Releasing is the hardest problem on mobile.
You can’t just deploy a fix like you can on web or backend. Apple and Google gate your releases via App Review™, so you have no guarantee of shipping your fix quickly. Without dedicated QA, your first sign of a production incident might just be when Twitter blows up.
This is cute when you have a few hundred DAUs (daily active users). You and your cofounder can apologetically ship a release over the weekend to your understanding cult of early adopters.
The risk profile changes as you scale up.
At about 10-100k DAUs, production incidents become existential: if a core feature is inaccessible, there’s a widespread crash, or your users all get logged out, growth nosedives and you’ll have to go back to Amazon.
I’ve spent 5 years in mobile at early-stage startups, and I’ve lost a lot of sleep to P1 alerts. For my own sanity, I’ve created a few novel approaches to app releases so we can move fast without breaking things.
Not today, Bezos.
The below paywall below goes down on March 31st.
If you don’t want to wait, please pay me 🙏❤️
Full subscribers to Jacob’s Tech Tavern unlock Quick Hacks, my advanced tips series, and enjoy my long-form articles 3 weeks before anyone else.
Keep reading with a 7-day free trial
Subscribe to Jacob’s Tech Tavern to keep reading this post and get 7 days of free access to the full post archives.