How To Release Without Fear
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.
Continue reading this post for free in the Substack app
|
