Start with one real journey
Imagine a Budapest repair business. A new customer needs to understand the service, send photographs and request an appointment. A technician needs to review assigned jobs, record work and continue when the connection drops. These are different journeys. Put each on a separate page and list the steps, information and failure cases. Do not assume that both groups need the same interface simply because they belong to the same business.
Choose the web for a clear first encounter
A website or web app is a strong candidate when customers arrive through a shared link or search and need to finish an occasional task. MDN describes web distribution through URLs and the possibility of installable progressive web apps. For the repair example, begin with clear service pages and a short enquiry journey. Make the mobile layout useful before adding an account, dashboard or loyalty feature that the customer may never need.
Test the reason for a mobile app
A mobile app deserves serious consideration when there is a recurring, specific need on the phone. Ask the technician to walk through a normal working day: which information must remain accessible, when photos are added and what happens after an interruption. Test the most important device-dependent behavior on the actual phones your audience uses. Treat installation, permissions, sign-in and returning to unfinished work as part of the product, rather than details to fix after launch.
Use both when the journeys justify both
A public website and a mobile app can serve different people while sharing the same business rules. In our example, the customer submits a request on the web and the technician manages the accepted job on mobile. Define what a request, appointment and completed job mean before connecting the interfaces. Android’s architecture guidance recommends separating responsibilities within an app. Apply that planning discipline to your product too: name an owner for data, errors and changes so the two experiences do not drift.
Plan for languages and ongoing work
For a Hungary-based company serving European customers, start with the languages you can maintain well. Check the whole journey in each language, including confirmation messages, empty states and contact information. Leave room for longer labels. Assign responsibility for support, content updates and future releases. A platform choice is also a maintenance choice: list the devices, browsers and customer tasks that must still work after every important change.
Write a brief that can be tested
Before requesting an estimate, give the development team one primary audience, one complete journey and a short list of genuine constraints. Separate required behavior from attractive extras. Agree how you will decide whether the first release is ready, and what you want to learn after people use it. The next platform should earn its place through an unmet customer need, rather than being added simply because competitors have an app.
- Name the task and the person completing it.
- Identify the devices, languages and connection conditions that matter.
- Describe success, interruption and failure in plain language.
- Choose a small release, a responsible owner and a review point.