Do you need a mobile application or a web portal? A decision guide

1. Start with a task, rather than an application idea

An application idea often begins with a sensible frustration: information is scattered, customers keep asking for updates or staff enter the same details twice. The next step is to describe the work behind that frustration. Choosing a platform too early can produce an attractive interface that leaves the underlying process unchanged.

List the people involved and the three most important tasks each must complete. A customer may need to view a booking, upload a document and ask a question. An office administrator may need to approve the document and update the booking. A field worker may need to record a visit where mobile reception is unreliable. These are connected but different needs.

Describe the context as well. Do people use a shared office computer, a company phone or a personal device? Do they work with gloves, need large text or move between locations? How frequently do they return? An occasional customer may find a browser link convenient, while a daily user may accept installation if it makes the work easier.

If you are exploring application development in Belfast, bring these tasks to the first discussion. They give a supplier something concrete to evaluate. A list of screens copied from another product is less useful because it does not explain the constraints, exceptions or responsibilities in your own organisation.

Write one short outcome statement for the first release. For example, a fictional maintenance team wants each completed visit to reach the office with the correct job reference and supporting notes. That statement helps judge platform choices and prevents the project from expanding into every related business process at once.

2. Understand the practical choices

A responsive web portal is a website with accounts and tasks designed to work across appropriate screen sizes. People normally reach it through a browser. It can support customer records, approvals, booking changes and other workflows. Its suitability depends on the actual implementation and user needs, not on whether the word application appears in the project name.

A mobile application built for a particular operating system is built for a mobile operating environment and distributed through an agreed route. Teams may build separate platform versions or share parts of the code using a suitable framework. Neither approach removes the need to test behaviour on each supported platform and maintain compatibility over time.

A progressive web application uses web technologies to provide features similar to those of an installed application. Mozilla’s documentation describes features including installation and offline operation, but support and behaviour depend on the relevant browsers, devices and implementation. Investigate this option against your requirements and test the features you need. Do not assume that every feature available in an application built for a particular device will also work in a browser.

The right answer can be mixed. A business might need an administration system accessed through a browser and a mobile interface for field work. The two can share underlying records without showing every user the same screens. Conversely, one carefully designed portal may be enough when the work mostly involves reviewing information and submitting forms.

Ask each supplier to explain the options it ruled out and why. A recommendation should connect to the hard tasks, distribution needs and support plan. Be cautious when the argument depends entirely on a preferred technology or a claim that one platform is always cheaper, faster or more professional.

3. Identify the requirements that could change the decision

Make a short list of capabilities that could genuinely affect platform choice. Examples include scanning labels, taking photographs, using location information, connecting to specialist equipment or receiving timely notifications. Specify what the user needs to accomplish rather than merely naming a device feature. Taking one photograph is different from capturing and organising dozens of images during a long visit.

For each capability, state how important it is and what happens if it fails. A missed convenience reminder may be tolerable. A missing record of an inspection needed for safety may not be. The consequences guide how much proof and operational control the project needs. Do not allow a long feature list to hide the single requirement that determines feasibility.

Ask for a small technical demonstration of the hardest capability on representative devices. This should test the real workflow, including permissions, errors and returning to the task after an interruption. A demonstration on the developer's own phone is not enough if your staff use a different device fleet or restrictive organisational settings.

Separate mandatory requirements from preferences. A customer may say the system must have an application icon when the actual need is to find the service easily. That can open up several options. Equally, a request that sounds small may involve a specialist integration that deserves early investigation.

Record the result of each proof: tested device, software environment, successful behaviour, limitations and remaining uncertainty. Keep that evidence in the brief so it informs supplier comparisons. Platform decisions become easier to review when the team can point to a tested task rather than a debate about labels.

A capability worksheet can have four columns: task, required conditions, proof and fallback. For a photograph upload, specify the expected number of images, supported connection conditions and how completion is confirmed. The proof might use representative images on an older supported phone. The fallback should explain what the user can do if the upload cannot finish. This format encourages practical decisions and exposes requirements that are still too vague. It also helps a supplier estimate the investigation separately from the rest of the build, instead of hiding uncertainty in a broad contingency.

4. Specify offline work precisely

Offline is not a single feature. A user might need to read previously loaded information, create a draft, attach photographs or confirm a completed job. Those behaviours have different implications. State exactly which tasks must work without a connection and what information must be available beforehand. Also explain how long a user may be disconnected.

Consider a hypothetical engineer arriving at a building with poor reception. The system may need the job address and checklist available before entry. During the visit, notes and photographs need a clear saved status. When connectivity returns, the office needs to know which information has arrived and whether anything remains on the device. This is a concept, not a description of a delivered project.

Conflicts need a policy. What happens if the office changes a booking while the engineer edits it offline? Does one version replace the other, do individual fields merge, or does someone review the conflict? The answer is a business rule that the interface must make understandable. Silent overwriting can create more confusion than a visible warning.

Test interruption and recovery. Close the application or browser, lose the connection during an upload, retry a submission and sign in again. Check whether records duplicate or disappear and whether the user understands the current state. Include recovery instructions for support staff, rather than assuming every user will diagnose the problem independently.

Offline storage also changes the information held on devices. Decide what can remain locally, for how long and what happens when a person leaves the organisation. Bring these questions into security and privacy planning. A platform recommendation that simply says offline supported has not yet answered the operational requirement.

• Which records must be available before a visit?
• Which actions can be saved without a connection?
• How does the user know an upload has completed?
• Who resolves conflicting changes?
• What happens after logout, device loss or staff departure?

5. Design the shared service behind the interface

The mobile screen is only part of the service. Someone needs to create accounts, correct mistakes, manage permissions and respond when information is missing. These administration tasks often determine whether a system is maintainable. Include them in the first scope so they are designed deliberately rather than left to database edits by a developer.

Map where each important record originates. A booking might begin in an existing scheduling tool, a customer in a customer relationship management system and an invoice in accounting software. Decide which system is authoritative for each item. If two systems can change the same field, define the rule for keeping them consistent.

Integrations require more than a logo on a proposal. Ask which information moves, which direction it travels, what triggers an update and what happens when the receiving service is unavailable. Establish who can inspect errors and retry failed transfers. A process that works only while every external service responds immediately is difficult to operate reliably.

Write down permissions in terms of actions. A customer may view their own booking but not another customer's record. An office user may correct an address while a field user can only report a proposed correction. Support staff may need limited access to investigate an issue. These distinctions should be tested, including attempts to reach a record through a direct link.

Finally, check the surrounding communications. Users may receive invitations, password recovery messages, confirmation emails and help instructions. The wording and delivery of those messages affect the experience just as much as the main interface. Include ownership of these messages and any external delivery service in the operating plan.

If customer records and staff handovers are central to the task, explore our custom CRM expertise before deciding what interface to build.

6. Make accessibility and privacy part of acceptance

Different users may need keyboard access, screen readers, larger text, clear errors or alternatives to gestures. Include representative users and their tools when testing the main tasks. Planning guidance from the World Wide Web Consortium supports assigning accessibility responsibilities throughout a project. An automated scan near the end of development cannot replace checking whether people can complete a real workflow.

Describe an accessible outcome in the brief. For example, a user should be able to find a booking, understand its status, correct an invalid entry and submit a request using their normal assistive technology. Ask the team to document the supported testing approach and any known limitations. Keep essential actions understandable without relying only on colour or an icon.

Privacy planning starts with the information the task actually needs. Identify personal information, who can access it, why it is collected and when it is removed. Guidance from the Information Commissioner’s Office on data protection by design explains the need to consider these issues from the beginning and throughout a service’s life. The choice of platform does not settle them automatically.

Use realistic but fictional test data where possible. Do not populate a demonstration with live customer records simply because it is convenient. If a supplier needs representative data structures, give examples with the same shape and edge cases. This lets the team test long names, duplicate records and missing values without casually exposing private information.

Include recovery and account administration in acceptance. Can a person regain access safely, can a manager remove a former staff member, and can support investigate without obtaining unnecessary access? A service is not ready merely because signing in and submitting information without any problems works once on the project team's devices.

7. Budget for distribution, updates and ongoing support

A service accessed through a browser and a distributed mobile application both need ongoing work. Servers, dependencies, integrations and user expectations change. The costs appear in different places, so compare the complete operating model rather than the first build figure. Ask what is included in the quoted support and which events create additional work.

For a mobile application distributed through an application store, allow for submission preparation, review and future updates. Apple's current Application Review Guidelines set out requirements for its store. Check the relevant distribution route before fixing a launch plan, especially where accounts, payments or restricted content are involved. Do not assume a finished build can be released immediately without further steps.

Define who owns the distribution accounts, source code, deployment configuration and services from other suppliers. The business should know how to obtain access and how a new supplier would take over. Ownership terms and licences need to be clear in the agreement. A backup of the source code alone is not a complete operating handover.

Ask how incidents are reported and prioritised. A forgotten password, a broken integration and a service outage require different responses. Document support hours, responsibilities, escalation contacts and the information needed in a support request. Avoid treating informal access to the original developer as a lasting support arrangement.

Plan the end of the service as well. How can records be exported, users informed and accounts closed? Which subscriptions remain payable during transition? A useful system should not depend on the business being unable to leave it. Include data export and documentation in the scope so continuity has a practical basis.

8. Work through a hypothetical decision with evidence

Imagine a fictional service business with office coordinators and visiting engineers. Customers only need to check appointment information occasionally. Engineers need to read job instructions and record visit notes daily. The office uses desktop computers and must review all completed visits. This is an illustrative decision exercise, not a Podium client case.

A sensible first investigation separates these users. The customer task may suit a secure browser link or portal because occasional use does not clearly justify installation. The office needs an administration interface. The engineers' requirements need closer examination because device use, photograph handling and poor connectivity could influence the technical approach.

The team writes a proof task: download an assigned job, open it without reception, record notes and photographs, then reconnect and verify that one complete record reaches the office. It tests that task on devices the engineers actually use. It also checks what happens if the office edits the job during the visit.

If the proof shows a web approach meets the agreed requirements, the business can evaluate that route with evidence. If a necessary capability remains unreliable, a mobile application may deserve further investigation. Neither conclusion should be assumed before the difficult task has been tested. The purpose is to reduce uncertainty, not to defend an initial preference.

The first release might cover only assigned jobs, completion notes and office review. Customers managing their own information, route planning and stock control can stay outside scope until the core process works. Keeping these exclusions visible protects the project from becoming a replacement for every system the business currently uses.

The fictional business can also test an occasional customer's journey. Send a trial invitation, ask the customer to find the appointment information and let them report a change. Observe whether the message is understandable, whether signing in adds unnecessary difficulty and whether the office can act on the request. This may reveal that a simpler interaction meets the need. Keep the result separate from the engineers' offline proof: one user's preference should not decide the platform for everyone. Shared records can support different interfaces when the tasks justify them.

9. Turn the decision into a brief suppliers can price

Prepare a short brief containing users, priority tasks, supported devices, offline requirements, existing systems and information responsibilities. Attach the results from testing the hardest task and identify unresolved questions. This is enough to start a meaningful discovery discussion without pretending every screen or technical decision is already final.

Write acceptance criteria around behaviour. A field user can see only assigned jobs. A submitted completion record appears once in the office view. A failed upload remains visible and can be retried. A customer cannot open another customer's appointment. These statements give the team something observable to demonstrate before release.

Ask suppliers to separate discovery, build, migration, training and ongoing operation in their response. Request the assumptions behind the estimate and a process for agreeing changes. If an integration or device requirement is uncertain, a priced investigation can be more useful than a confident fixed figure built on guesses.

Compare delivery approaches as well as totals. Look for early prototypes, user involvement, representative testing and a clear route from trial to release. Ask what evidence will be available at each checkpoint and who can accept the work. A long list of technologies does not explain how the team will establish that the service helps its users.

Podium's custom development page provides the service context for discussing the next step. Bring the task list and constraints first. The useful outcome of the first conversation is a clearer route to proving the service, whether that leads to a portal, a mobile application, an adapted existing product or a simpler change to the current process.

Keep a decision log with the date, options considered, evidence, choice and conditions for revisiting it. For example, a portal decision may depend on the current device fleet and the limited offline task. A later requirement to connect to specialist equipment may justify a new investigation. The log prevents the first choice from being treated as permanent truth while also preventing repeated debates with no new evidence. Share it with the future support team, because they need to understand why a limitation exists and when it becomes important enough to change.

Our custom application and portal service starts with that task and the practical requirements around it.

If you are planning a new product, our MVP app development guide helps define a complete first release and separate later ideas from essential work.

• Named users and their priority tasks.
• Supported devices and an explicit offline specification.
• Record ownership, integrations and permission rules.
• Observable acceptance criteria and representative user testing.
• Distribution access, support responsibilities and an exit plan.