Website, web app, or mobile app: what to build first

Kathmandu University School of Education's EMIS has a Flutter mobile app. It is not the heart of the system. The heart is a web app and API that more than ten roles sign in to, from applicants to the exam department, and the app is one more way in.

That is the pattern we keep coming back to, because the word "app" usually stands in for one of three different things, and they solve different problems. A website gets strangers to find you. A web app gives your staff and customers a system to work in. A mobile app sits on the phone of someone who already uses you often. Pick the one that matches your problem today, and the other two can come later on the same backend.

Our short answer for most Nepali businesses: website first if people need to find you, web app first if your work runs on spreadsheets and phone calls, and the mobile app once you have people who would open it every week.

The three things people mean by "app"

A website is public pages: who you are, what you sell, how to reach you. Its job is to be found on Google and to turn a visitor into an enquiry. Every hotel, trekking and consultancy project on our projects page is a web build.

A web app is a logged-in system that runs in the browser. Staff, students, agents or customers sign in and do work in it: submit an application, approve a request, see their results, pay a fee. Nothing gets installed, and it works the same on a laptop in the office and a phone on the bus.

A mobile app is installed from the Play Store or App Store. It can use the phone more deeply, sends notifications people actually see, and stays one tap away on the home screen.

Build the website first when strangers need to find you

If your next customer does not know your name yet, they will search for what you do, and Google answers that search with pages. A trekking company needs a page that answers "Annapurna base camp trek cost", not an app listing. Nobody installs an app from a company they found five minutes ago.

This is why the Avaani group's companies, Avaani Enterprise, Avaani Real Estate and Avaani Cricket Club, each run on a website we built rather than an app. Their job is to introduce a company to people who do not know it yet. An app would put a download step in front of that, for people who have not decided to trust you.

Build a web app first when the work lives in spreadsheets

The second common case is a business that is already busy and drowning in its own process. Applications arrive on WhatsApp, fees are tracked in Excel, and the person who knows where everything is goes on leave.

That is a web app problem, and the fix is a system people sign in to. When Kathmandu University School of Education asked us for EMIS, the core was a web app and API: applicants are tracked through admissions, become student records organised by batch, and results are published only after fees are verified. About 5,700 existing student records were moved in from the old tools. An exam department publishing results needs a system with roles and checks, not a phone screen.

Starting in the browser also means every user gets the same version on the day you release it. No one is stuck on last month's build because they never updated.

Build the mobile app when people come back every week

The case for a mobile app is frequency. If the same person opens it several times a week, the home screen icon, the notifications and the faster interface are worth paying for.

EMIS has its Flutter mobile app alongside the web app. Travel Quoter runs a web app for travellers and agencies, plus iOS and Android apps built with Flutter, so a traveller can negotiate a quote with an agency in chat from their phone. In both cases the app sits on the same API as the web app. It is a second front door to a system that already works, not the system itself.

Apps also need the phone itself in a way websites do not: scanning with the camera, working with no signal, tracking location in the background. If your product needs those, the app moves up the list.

What an app adds that people forget to budget for

An app is not one project. It is two store listings, two review processes and a release routine that runs every time you change something. Flutter lets one codebase serve both iOS and Android, which is why we use it, but the stores still review each release on their own schedule.

Then there is the paperwork. Apple asks an organisation for a D-U-N-S Number and a membership of 99 USD a year. A new personal Google Play account has to run a closed test with at least 12 testers for 14 days before it can publish. We covered who should own those accounts in choosing a mobile app company in Nepal.

One middle path is worth knowing. A web app can be added to the phone's home screen, and since iOS 16.4 Apple allows web push notifications for web apps added that way. For a business that mostly wants "an icon and notifications", that can carry you a long way before a store app is needed.

The order we usually suggest

Build	When	Main job
Website	People who do not know you need to find you	Get found on Google, turn visits into enquiries
Web app	The work behind the business has outgrown spreadsheets	Give staff and customers one system to sign in to
Mobile app	You have users who open it every week	Notifications, the home screen, the phone's camera and location

Some businesses need more than one at once. Travel Quoter's marketplace runs as a web app and mobile apps on one API. But the order holds more often than not, and the thing to avoid is building the app first and finding out your customers never got as far as installing it.

We build all three: web development for sites and web apps, and mobile app development in Flutter on top of the same API. If you are not sure which one your problem is, tell us what you are trying to fix and we will say which to build first, including when the answer is not an app.