4 comments

[ 2.4 ms ] story [ 19.4 ms ] thread
The example app is making me upset... Instagram redux? Why
The "what's the penalty for being wrong" question is the part I'd keep. That one works at any scale.

But I spent five years on a solo app and never wrote anything close to this. Not on principle event, just the design just kept moving. The decisions that ended up mattering weren't ones I could have named on day one, they were things I cut in year three once I actually understood what the app was for. If I'd written the objective sentence up front I'd have locked in a version that turned out wrong. The clarity came from building the thing, not from describing it first.

For coordinating people or catching a security flaw before it ships, sure, all of this makes sense. Solo just runs on different rules I guess.

Should permission handling, battery optimization, and foreground service behavior be included in the design doc or left to implementation?
How should you document Android-version-specific behavior (Android 6–16) without making the document difficult to read?