Every web-to-mobile project I've been on had the same scoping meeting. Someone opens with "we already have the API, so mobile is mostly UI," the room nods, and a quarter gets pencilled in.

That sentence hides four things: the read contract your web app grew up with, the auth model that lives in a cookie, the OS plumbing a browser gave you for free, and a release cycle where "ship the fix" meant a redeploy, not a store review.

Most of the work lands behind the screens. The mobile client is the cheap part; what costs money is everything the web app was allowed to assume. This is about re-negotiating those assumptions, with shipped projects as evidence.

Decide what parity means before you scope

"Parity" is the default nobody chooses. It arrives because nobody wrote down a narrower target, and it quietly becomes the acceptance criterion.

There are three defensible targets, and you should pick one out loud:

Companion app.…