mobile release engineering,
for everyone.


Modern smartphones and their app stores are very new in the industry. iOS and Android saw exponential growth only after 2010. For a long time, this did not impact engineering because apps were either small in scope or secondary channels to a business.

This changed after the wild success of app-only businesses like Uber, Instagram, Swiggy, Gojek, etc. Today, it is common for businesses to be built around an app experience, which means apps are critical to the success of those businesses.

Engineering teams are acutely aware that the state of developer tooling for backend and frontend teams is a decade ahead of what mobile developers get to use regularly.

As a result, an app-first business tends to spend a lot of effort ensuring its apps are stable and perform reliably. This adds engineering overhead because now the organization must stitch together different tools to solve their needs. They must also maintain this internal tooling while also trying to meet business requirements.

A multi-faceted problem

This is not an easy problem, nor is it one that permits a singular solution, so with Tramline we’ve chosen to start with simplifying the deployment process.

Releasing apps is key to the success of an app-first business. It is a consistently repeated transaction because it is what delivers value to customers, ergo an incorrect build being released incurs a very high cost.

Further, the Play Store and App Store are walled gardens with Google and Apple setting all the rules, which can and do change many times. Continuous delivery, a proven valuable practice, is impossible in these stores and so is the rollback of bad builds. Even the control of over-the-air updates rests with the user and the device. In that sense, apps are much more like on-premise software that cannot be frequently updated.

For the vast majority of the app ecosystem, releasing a new version involves many steps and multiple stakeholders. The process is simple when the team and product are small and do not move fast. However, for large-scale fast-moving products, app releases become exponentially more complicated and begin to look something like this:

The release process is documented in a tool (e.g. Google Docs, Confluence) as a series of steps and checklists that have to be followed. The process is run by a person assigned as the release pilot – someone who is accountable for a correct run. The pilot’s role is one that often rotates within the engineering team because when a release is not being run the pilot can go back to their regular development duties. Some very large scale companies even have dedicated release engineering teams.

The release process checklist, like all checklists, is a maintenance burden because the process, tools, or steps change over time. Small out-of-band tasks may be done by a team (or specific engineers) that may never get mentioned in the checklist.

Human factors also play another role here. Churn in the team is expected at all organizations, and every time that happens the team must make sure that all release-related knowledge has been transferred from memory and committed to documentation.

A clear aim

Our mission is to equip teams with tools that help them focus on delivering business value, and not on ancillary activities like driving a release checklist. With Tramline, we hope to reduce the uncertainty around releases for everyone involved and reduce the opportunity cost incurred by the organization because of the aforementioned overheads.

Prior to starting Tramline, Pratul was the co-founder & CTO of Obvious, where he helped clients like Myntra, Dunzo, Ola Cabs and Flipkart with mobile engineering challenges.

Before Obvious, he was mobile engineer #1 at Practo and a contributor to Drupal.