Modern smartphones and app stores are still young in the software world. iOS and Android only took off after 2010, and for years, apps remained small side projects or secondary business channels. Then came the breakout success of app-first companies like Uber, Instagram, Snapchat, and WhatsApp, and everything changed.
Today, many businesses are built entirely around their app experience. That makes mobile apps mission-critical, yet developer tooling for mobile teams lags a decade behind what backend and web developers take for granted.
As a result, app-first businesses pour enormous effort into keeping their apps stable and fast. They stitch together a patchwork of tools, maintain them in-house, and juggle this overhead alongside delivering core business features. It’s an expensive and complex balancing act.
Releasing apps is central to the success of an app-first business. Every release is a moment where value is delivered to customers, which means mistakes are costly.
The App Store and Play Store are walled gardens where Apple and Google set the rules, and those rules can change at any time. Continuous delivery, a proven best practice, is explicitly disallowed, so rolling back a bad build is not an option. Even over-the-air updates are ultimately controlled by the user and their device.
In that sense, mobile apps behave more like on-premise software that cannot be updated frequently.
For most of the app ecosystem, releasing a new version is a multi-step process involving many stakeholders. This process is manageable when the team is small and the product moves slowly. But for large, fast-moving products, app releases become exponentially more complex.
“It was the most terrifying thing to take 10,000 diffs, package it into effectively a bullet, fire that bullet at the horizon and that bullet, once it leaves the barrel, it’s gone. I cannot get it back, and it flies flat and true with no friction and no gravity till the heat death of the universe. It’s gone. I can’t fix it. That fundamental model is terrifying in effect.”
What goes into an app’s release cycle? A lot more than most people realize!
Most teams document this process in a tool like Google Docs or Confluence or Notion as a checklist of steps to follow.
The process is led by a Release Pilot, a designated person responsible for making sure everything runs correctly. In many teams, the pilot role rotates so engineers can return to regular development work between releases. At very large companies, there may be dedicated release engineering teams!
Checklists themselves are a maintenance burden. Processes, tools, and steps evolve, and small out-of-band tasks often happen without being captured in the documentation.
Human factors add further complexity. Teams experience churn, and every time someone leaves, release-related knowledge must be transferred from memory into documentation, or risk being lost entirely.
Tramline’s mission is to equip teams with tools that help them focus on delivering business value, and not on ancillary activities like managing a release checklist.
