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.
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.
Published May 9, 2026 · 1 min read