delivery
A two-year release gap is not a mobile problem
Fact: when I joined Sheypoor, the Android application had gone roughly two years without a production release. Interpretation, formed later: that was never really a mobile engineering problem. It was a loss of organisational ability to ship — expressed, visibly, through one app store listing.
The fact, and the trap inside it
Let me keep the fact clean: the application had not shipped to production in about two years. Work on it had continued the entire time — development, refactoring, improvement. None of it had converged into a production release.
The trap is to read that fact as a mobile team failure. Two years is too long for any single-discipline explanation. If a team can build for two years but cannot ship for two years, the inability to ship lives somewhere larger than the team.
What "shipping" actually is
Releasing an app looks like a deployment step. It isn't. A release is the moment an organisation's ownership, architecture, process, risk management, and structure all have to agree — simultaneously — that something is safe to hand to users.
When a release doesn't happen, the blocker is usually one of those five, and rarely the deployment tooling:
- Ownership — nobody can say "yes, this is ready", with the authority to mean it.
- Architecture — the system has grown to where every release risks everything, so every release waits.
- Process — the path to production requires more coordination than the organisation can sustain.
- Risk management — the cost of a bad release feels higher than the cost of no release, so the org quietly chooses stale over sorry.
- Structure — the teams whose approval a release needs don't share priorities, or a calendar, or a definition of done.
What happened when we shipped
Fixing push notifications required a new Android release — which made the gap impossible to route around. Shipping it became one of the hardest and most valuable things the engineering team did during my time there. It was a team achievement; my role was to make it the priority, clear the path, and keep the organisation patient while difficult work happened.
The outcome that mattered wasn't the version number. It was that the organisation regained the ability to ship. The cycle corrected: the app moved to roughly monthly releases, and teams could release independently and regularly. Once shipping became routine, the organisation stopped treating releases as events and started treating them as work.
How to diagnose your own release gap
If your team's last release is further away than anyone would like, the useful question is not "how do we push this release out" but "which of the five is broken". In my experience the answer is usually structure before tooling: who owns the release decision, and does the path to production match the org chart or fight it.
I would now treat release cadence as a leadership instrument the way finance treats cash flow: a slow cadence is not itself the disease, but it is almost always a symptom of something that deserves leadership attention.