This week I wanted to “just start mobile development” for my checklist service: build a straightforward mobile client and cover the basic scenarios. The first questions looked practical: do I need a full editor on the phone, is the current API enough, and which stack and working setup should I choose?
But very quickly it became clear that this was not really a story about one more client. Mobile became a useful spotlight: it showed the places where I had not fully described the system as a contract, and where it still depended on browser defaults.
1) Product framing: a phone is not a second “full editor”
The request for a “full mobile editor” sounds logical until you break it down into real situations. In practice, it mixes two different user scenarios:
edits on the go: quickly fix text, mark a step, replace one item, continue a checklist in the field;
