Web app, mobile app or website? How to choose your first build

For most organisations the right first build is a website if you need to be found and trusted, a web app if users need to sign in and do work, and a native mobile app only if the product depends on the phone itself: camera, GPS, push notifications, offline use or a place on the home screen. Start with the smallest thing that lets real users complete the core task, then earn the next platform with evidence.

Three different things, often confused

The terms get used loosely, so it is worth being precise.

• A website is mostly read. Pages, content, forms, a booking or a checkout. Its job is to be discovered, explain, persuade and convert.
• A web app is mostly used. People sign in, create and manage data, collaborate, run a process. It lives at a URL and runs in the browser on any device, with nothing to install.
• A mobile app is installed from the App Store or Google Play. It can use the device’s hardware and sit on the home screen, and every release has to pass store review.

Many products end up being all three. The question is which one comes first.

Five questions that settle it

1. What is the one task a user must complete?

Write it as a sentence. “Book a consultation.” “Submit a monthly compliance report.” “Log a run and see progress.” If the task is reading and enquiring, you want a website. If it is creating, editing and tracking, you want a web app. If it happens on the move, in the field or with the phone’s sensors, you may need a mobile app.

2. Where are your users when they do it?

At a desk, a web app is more comfortable and far cheaper to change. On a job site, in a warehouse, on a bike or in a clinic corridor, the phone wins, and it may need to keep working with no signal.

3. How often will they come back?

People install apps for things they do weekly or daily. A product used a few times a year will not survive on a home screen. Membership associations, franchisors with annual renewals and public-sector services usually do better with a responsive web app that opens from an email link.

4. How fast do you need to learn?

A web app can ship changes several times a day. A native app waits for store review and then for users to update. If you are still discovering what the product is, the browser lets you iterate at the pace of the questions.

5. What does the phone give you that the browser cannot?

Be honest here. Modern browsers handle camera capture, location, payments and installable icons through progressive web apps. Native still wins for background location, reliable push notifications on iOS at scale, Bluetooth and health hardware, heavy offline sync and anything that must feel instant under the thumb. If none of those is central to the core task, mobile can wait.

When a website is the right first build

Choose a website when your growth problem is awareness and trust. A corporation launching a new division, a franchise recruiting operators, a professional practice that lives on referrals: all of these need to be found in Google and in AI answer engines, explain themselves clearly, and turn a visit into a call or a form. A well-built website with strong content, schema markup and bilingual EN/FR pages will do more for that goal than any app.

The trap is mistaking a website for a product. If your site’s most important page is the login page, you have already outgrown it.

When a web app is the right first build

Choose a web app when users have accounts and data. Member portals, client dashboards, internal operations tools, marketplaces, booking systems with staff on the other side, anything with roles and permissions. One codebase serves desktop, tablet and phone. Deployment is immediate. Accessibility to WCAG 2.2 AA is far easier to meet and audit in the browser, which matters for associations and government bodies with obligations to the public.

Build it responsive from day one and add a progressive web app layer so it can be installed and used offline. That covers a surprising share of “we need an app” requests without a single store submission.

When a mobile app is the right first build

Choose native when the phone is the product. Field-service and inspection tools that must work without signal. Fitness, health and habit products that rely on sensors and daily notifications. Loyalty and ordering for a franchise network where the app lives next to the customer’s wallet. Anything where a delay of even half a second breaks the experience.

When native is right, decide early between building Android and iOS separately or using a shared framework. Separate builds give the best feel and full access to each platform; shared code trades a little of that for speed and a single team. Neither is wrong, but the choice is hard to reverse, so make it deliberately.

A worked example

A provincial professional association came to us wanting “an app for members”. Its core task turned out to be annual licence renewal plus a handful of continuing-education submissions a year. Members were at their desks, once or twice annually, and the association’s real problems were a dated public site and a manual back office. We built a responsive web portal first, connected it to a new public website, and left mobile for a later phase. Renewal completion time fell sharply in the first cycle and support tickets dropped, without anyone installing anything.

Whatever you choose, start the same way

Every OlDevs build begins with a strategy call where we map the core task, the users and the constraints, then a design phase you can react to before any code exists. During the build you see a working demo every week, so the decision above can be revisited with evidence rather than opinion. After launch we help you grow it, and you own all of the code, designs, accounts and IP from the first commit.

If you want a second opinion on which to build first, tell us what the one task is. We will reply within one business day with a recommendation and a quote for the build that fits.