Guide · Technical decisions
Do you need an app or would a website do?
For an occasional task such as requesting a quote or booking a first appointment, start by testing a mobile-friendly website. Consider an app when frequent use or specific device capabilities justify installation. A progressive web app (PWA) sits between them, but its required features must work on your customers’ actual devices.
Start with the task and how often it happens
Hypothetical example: a new customer books one repair appointment. A link that opens immediately may be easier than asking them to install an app and create an account first. A technician recording jobs all day has a different reason to keep a tool on their phone.
Write down the entry point, frequency and result: “open a link from an email, attach a photo and confirm the visit”. Test that journey before choosing the delivery format.
Separate a responsive website from a PWA
A responsive website adapts its layout to the screen. A PWA uses web technology and can provide capabilities such as installation and offline operation. Those capabilities require implementation; adding an icon does not make every feature work offline.
MDN documents differences across browsers and operating systems. Test the intended installation route on the target devices instead of assuming one prompt or store will cover everyone.
Test the device feature that could decide the project
List the required camera, location, Bluetooth, scanning or background behaviour. “Uses the camera” is not a complete requirement: taking an occasional photo differs from continuous scanning during a shift.
Ask for a small technical test of the hardest capability on the oldest supported phone and browser. If it cannot meet the requirement reliably, that result is a reason to consider a platform-specific app; appearance alone is not.
Define what “works offline” means
Reading a cached price list is different from editing a shared job without a connection. Write down what remains available, what can be changed and what must wait for the server. Offline support and background work have platform constraints.
For a job form, test losing connectivity after attaching a photo, reopening the app and reconnecting after another person has edited the same job. Decide how to show pending uploads and resolve conflicts. Neither a web nor a native app solves those rules automatically.
Budget for the service behind the screen
Both choices may need accounts, a server-side service to store and process data, access permissions, backups and integrations. Compare the same workflow and support period. An app adds platform and distribution work; a demanding web application can also be costly.
Do not commission two separate products merely to have both icons and a website. Keep public discovery pages on the web and test the operational tool where its users need it. Shared code can help, but it does not remove device testing.
- 01 Input One customer or team task
- 02 Requirements Required device and offline behaviour
- 03 Test Complete the task on supported phones
- 04 Decision Choose the smallest workable delivery format
Test the essential task before choosing
For the booking example, observe whether a customer can complete the task on a phone without assistance. For the technician, test the offline and device behaviour that makes the work difficult. Record the failed step, not just whether the prototype looked good.
The first version should deliver one useful journey with its important failure cases. Add platforms when there is a demonstrated need and someone responsible for maintaining them.
To define the next step, read what drives app development cost.
Sources and further reading
Questions before we start
Is a website cheaper than a mobile app?
A simple responsive site often has less distribution work, but price depends on the workflow. Compare the same accounts, integrations, offline behaviour and support requirements before deciding.
Can a web app work without internet?
Some functions can, when caching and local data handling are implemented. Editing shared data also needs synchronisation and conflict rules. Test the required behaviour on supported devices.
Do I need an app for customers to book appointments?
Not usually just for booking. Start with a mobile-friendly booking journey. An app needs another reason for customers to install and return to it.
Can I turn the website into an app later?
Sometimes parts of the screens and the system that stores and processes data can be reused. Packaging a website as an app does not automatically add reliable offline support or every phone capability. Test the missing requirements before promising reuse.