Scoping a mobile build: what discovery should produce

01The questions that move the number most

Offline behaviour is first. 'Works offline' can mean cached reads or full bidirectional sync with conflict resolution, and the difference between those is substantial. A brief that says the app should work offline without specifying which has not specified anything.

Platform coverage is second, and it is not just iOS and Android. The oldest OS version you support and whether tablets are in scope both change the testing and layout surface materially.

Third is what the app does with existing systems. An app talking to a clean API is a different project from one talking to a legacy system that needs an integration layer built first - and that layer is frequently larger than the app.

02What discovery should hand over

These artefacts turn a range into an estimate, and they are useful regardless of who builds it.

• A screen inventory with states - loading, empty, error, offline - not just happy-path designs. States are where the hidden work is.
• The integration list: every system the app talks to, with a note on whether an API exists today.
• Explicit offline and sync requirements per feature, rather than a blanket statement.
• Non-functional requirements: supported OS versions, device tiers, performance targets, accessibility and compliance obligations.
• The list of things deliberately excluded from version one, which is as valuable as the inclusion list.

03Why a fixed price without this is a bad deal for both sides

A fixed price quoted against an ambiguous brief is priced for the worst reasonable interpretation. You pay for risk that may not materialise, and the vendor still argues about scope when it does.

With a clear scope, fixed price becomes reasonable because both sides are pricing the same thing. Without it, time and materials with a capped discovery phase is usually the fairer structure - and a partner who insists on fixed price for an unclear brief is either padding heavily or planning to litigate scope later.

The practical middle path is a paid discovery engagement producing the artefacts above, after which a fixed price for the build is meaningful. That discovery is portable; you can take it to another vendor.

04How long it should take

For a typical product, discovery is measured in weeks rather than months. Longer than that usually means the product decisions themselves are unresolved, and no amount of specification work substitutes for making them.

If discovery keeps expanding, the useful intervention is to narrow version one until it is describable, rather than to keep specifying a scope nobody has agreed to.