Should You Build an App or a Website?

This comes up on almost every first call, usually in the same shape. Someone has an idea, they know it needs building, and they want to know whether it should be an app or a website.

It is a reasonable question and it is usually asked the wrong way round, because three different things are hiding inside it.

Three things, not two

A website is pages of information. What you do, who you are, how to reach you. People read it and leave.

A web app is software that runs in a browser. People log in, things are saved, work gets done. Your bank's online portal is a web app. So is almost every tool you use during the working day.

A mobile app is software installed from the App Store or Play Store that runs on the phone itself.

When someone says "should I build an app or a website", they almost never mean the first one. They have described software, and the real question is whether that software lives in a browser or on a phone. Getting that straight changes the conversation immediately.

The question that decides it

There is one test, and it is simpler than the comparison articles suggest.

Does the thing you are building depend on the phone itself?

Not "would it be nice on a phone". Everything is nice on a phone, and a well built web app works perfectly on one. The question is whether your product genuinely needs the native capabilities of the device: constant location in the background, the camera as a core function rather than an upload button, offline use, push notifications that have to arrive when the app is closed, hardware like Bluetooth or sensors.

If yes, you need a mobile app, and the rest of this does not apply to you.

If no, and this is most products, start with a web app.

Why the web app wins by default

Nobody has to download anything

This is the one founders underestimate most. Asking someone to install an app is asking for a real commitment before they have any idea whether your product is worth it. Every extra step loses people, and installation is a big step.

A web app is a link. You send it, they open it, they are using your product. For anything early, where you are trying to get strangers to try something they have never heard of, that difference is enormous.

You ship faster

Fewer moving parts, no build process for two operating systems, no waiting on review before anyone can see a fix. When something is wrong you correct it and it is live. On mobile you correct it, submit it, and wait.

For a first version, where you expect to change things constantly because you are still learning what the product is, that difference compounds every single week.

No store policies to satisfy

App stores have rules about what you can build, how you can charge, and what you must include, and they can reject you for reasons that have nothing to do with whether your product works. That is a bottleneck standing between you and your users, and it exists on their timetable rather than yours.

The revenue is yours

Sell a subscription through an app store and the store takes a percentage of it, every month, forever. On a web app you choose your payment provider and you keep what you make, minus ordinary processing fees.

For an early business that margin is not a detail. It is the difference between a model that works and one that only works at scale you have not reached yet.

The sequence that actually works

The framing of app against website assumes you pick one and live with it. You do not.

Build the web app first. Get it in front of real users quickly, because it is a link rather than a download. Find out whether people want it, whether they come back, and whether they will pay. Change it as often as the answers require.

Then, if the demand is proven and there is a genuine reason to be on the phone, build the mobile app. And you build it from a completely different position: you know what people actually use, which features matter, where they get stuck, and what the thing really is. You are no longer guessing.

Almost every founder who goes mobile first is making an expensive guess. Almost every founder who goes web app first is buying the information that makes the next decision obvious.

Where this goes wrong

The usual mistake is deciding on ambition rather than requirement. A mobile app feels more like a real company. It has an icon, it sits on someone's home screen, it feels like arriving.

That feeling has cost founders a great deal of money. You spend longer building, you launch to nobody, and you learn nothing you could not have learned in a fraction of the time, because the barrier to trying it was too high for anyone to bother.

The other version is being told mobile is required by someone who only builds mobile. Ask what specifically about the product needs the device. If the answer is vague, you have your answer.

The short version

Ask one question. Does it need the phone itself, in a way a browser genuinely cannot do?

If yes, build the mobile app. If no, and if the goal is to move fast, get real users and find out whether the idea holds up, build the web app. Ship it, learn from it, and add the mobile app once you have proof rather than hope.

This is the same principle as validating an idea before you pay anyone to build it. Spend the least you can to find out whether you are right, then spend properly on what you have proven.

If you are working out which of these you need, we build websites and web apps, and you can see what we have shipped.