Company
1 min

How a small team ships six apps without drowning in maintenance

Every shipped app is a permanent maintenance obligation. Our approach to keeping a growing portfolio sustainable.

Ramesh KannanFounder & Engineering

The exciting part of shipping an app lasts about a week. After that it is policy updates, SDK deprecations, OS releases and support mail — indefinitely. A portfolio of six apps is six of those obligations running in parallel.

A shared foundation, not shared products

Our apps look nothing alike and serve unrelated audiences, but they sit on the same internal foundation: the same networking layer, the same local storage conventions, the same release pipeline, the same privacy and consent components. When Android changes a rule, we fix it once.

Policy pages are code

Every app's privacy policy and terms live in this repository at a stable URL, versioned alongside the app. They are reviewed in pull requests like anything else. That sounds bureaucratic until a store review depends on the page being both accurate and reachable.

Say no to features, yes to fixes

Our default answer to a new feature in a mature app is no. Our default answer to a correctness bug is immediately. Portfolios die from accumulated half-maintained features, not from a missing one.

What is next

iOS is the most common request we receive and it is on the roadmap. We are approaching it the same way — shared foundation first, then products on top, rather than six independent ports.

ProcessTeamMaintenance

Published May 9, 2026 · 1 min read

Notes from the workshop.

Occasional writing on shipping mobile AI — architecture decisions, privacy engineering and what we got wrong. No cadence promises, no filler.

Keep reading.

All posts