Every decision has to earn its place.
These are not aspirations. They are the constraints we apply before any feature ships — on battery draw, permissions, and scope. If something can't justify its cost, it doesn't make the build.
Nothing ships without a reason
Battery, data, storage — all counted
Lighter sometimes means fewer features
Each animation, network call, and background process must justify its resource cost before it ships. If it can't, it's cut — not deferred, not deprioritised.
Environmental footprint is tracked at the product level: wake-lock duration, data transferred per session, storage delta after install. Numbers, not intent.
A smaller scope is often the right call. We say so in the app description and in the build log — not as a caveat, but as the actual design rationale.
We request only what the feature actually requires.
Before any permission dialog appears, the request is reviewed against the specific function it enables. If the feature works without it, the permission isn't requested. This is logged in the build notes for every release.
The reasoning is documented, not summarised.
The build log covers specific decisions: what was cut, why a feature scope was narrowed, and what the measured impact looked like. Short posts, no press-kit tone.