Choosing a mobile technology before defining the required capabilities can lock a product into avoidable complexity. A country-neutral product team may need reliable capture, secure account access, device integration or simple occasional self-service, and those needs do not all point to the same delivery approach.
This guide provides a capability-led architecture brief using a hypothetical inspection product sold to several organisations. You will distinguish business requirements from platform preferences, test device-dependent behaviour early and include distribution and support in the decision.
The objective is a maintainable product whose limits are understood, rather than a framework choice defended after the critical capability fails on a customer’s actual device.
In this guide
- Which capabilities should drive the decision?
- What should a technical spike prove?
- What belongs in lifetime cost?
- Which architecture shortcuts create later constraints?
- Before committing
- FAQ
- Further reading
Which capabilities should drive the decision?
List required device access, connectivity assumptions, background behaviour and distribution constraints. Separate essential capabilities from preferences inherited from an existing product.
Compare native, cross-platform and web approaches using the same critical journey. Progressive web applications can offer an installable experience, but support for a particular capability must be verified on the intended browsers and devices.
What should a technical spike prove?
Build the narrowest implemented journey that exercises the uncertain capability. Test permission denial, interruption, account changes and recovery.
A screen mockup cannot prove camera handling, reliable offline submission or background execution. Record observed behaviour, supported conditions and unresolved limits instead of turning a successful demonstration on one phone into a universal compatibility claim.
What belongs in lifetime cost?
Include build tooling, supported operating-system versions, distribution, accessibility, monitoring and incident support. Define how organisations enrol users and how access is revoked.
Plan release compatibility with the backend, including older installed versions still in use. Compare team capability and maintenance ownership alongside development effort; initial coding speed does not establish the cost of operating the product.
Which architecture shortcuts create later constraints?
Avoid requesting broad device permissions before the user needs them. Do not rely on an app-store listing as evidence of task quality.
Keep the business record and server authorisation authoritative even when the client stores drafts or offers a convenient offline interface.
Before committing
- List required device access, connectivity assumptions, background behaviour and distribution constraints.
- Build the narrowest implemented journey that exercises the uncertain capability.
- Include build tooling, supported operating-system versions, distribution, accessibility, monitoring and incident support.
FAQ
Is native always better for performance?
Evaluate the actual workload and devices rather than assuming a category guarantees the result.
Can a web application be installed?
Some web approaches support installation, with behaviour depending on the target environment.
What is a useful proof of concept?
Implemented evidence for the riskiest required capability and its failure conditions.
Should old app versions be considered?
Yes. Backend and release plans need to account for the versions customers can still run.
What determines the final choice?
Verified capability fit, operating constraints and sustainable ownership across the product lifecycle.
Further reading
Technical reference: Progressive web application guidance. The scenarios above are illustrative, not client case studies.
Related articles: Production Prompt Engineering: Treat Instructions as a Versioned Interface and Agile Integration Work: Define Contracts Before Counting Completed Tickets.
