The hidden cost of bloatware: why we keep our apps lightweight

It's easy for an app to grow heavier with every release without anyone deciding that on purpose. Here's how we try to avoid it.

Every dependency is a future liability, not just a current convenience

Adding a third-party SDK for one feature looks free at the time. A year later, that SDK has its own update cycle, its own permissions, its own crash reports to debug, and its own effect on app size — long after the original feature stopped being a priority. We ask "will we still want to maintain this in two years" before adding anything, not just "does it work right now."

App size affects who can even install your app

On a budget phone with 32GB of storage and three years of accumulated photos, a 150MB app and a 25MB app are not the same decision for the user. We treat install size as a feature, not an afterthought measured after the fact.

Background activity is a battery tax users didn't agree to

A feature that "just checks in the background" every few minutes adds up across dozens of installed apps. We default to the most conservative background behavior that still makes the feature work, and we make any background activity visible and controllable in settings — not invisible by design.

Fewer permissions is a feature, not a limitation

We regularly audit our own permission requests and remove ones tied to features that got cut, changed, or were never used as much as expected. A shrinking permission list over time is a sign of a healthy app, not a stalled one.

"Lightweight" is a constraint, not a slogan

We don't chase a small app size for its own sake at the expense of features people actually use. The goal is that nothing in the app exists without a reason someone can point to — that naturally keeps things lean without turning "lightweight" into a marketing checkbox.

This is slower to build than just adding things. It's also the difference between an app that still feels fast on a three-year-old phone and one that doesn't.