Should I Build an App or a Website First? A Founder's Rule

Should I build an app or a website first? Most advice answers with a budget argument: a website is cheaper, so start there. That is half true and often wrong, because the cheapest product to build is not the one that teaches you the most. The better question is where your first real use has to happen, and the answer to "should I build an app or a website first" falls out of it.

Start With Where the First Real Use Has to Happen, Not What Is Cheaper

When founders ask me "should I build an app or a website first", they usually describe a feature list. I ask a different thing: picture your first ten paying users using the product. Where are they, what are they holding, and what are they doing in the moment it matters?

If they are at a desk, filling in a form, reading a report or sharing a link with a colleague, that moment happens in a browser. If they are walking a dog, scanning a coin, blocking apps on a child's phone or getting a reminder at 7 a.m., it happens on a phone, and a website cannot be in that moment at all.

That is the core of the app vs website for a startup decision. It is a question about context of use, not about technology. Cost matters, but only after you know which surface can deliver the core value at all. A cheap website that cannot do the one thing users came for does not save money. It delays the lesson.

Three quick tests help:

• Does the core value need the camera, sensors, push notifications or an OS-level API? If yes, the app comes first.
• Does a stranger need to reach it from a link, a search result or an email? If yes, the web has a structural advantage.
• Does the product work when the user is not looking at it? Background work, reminders and blocking features live on the device.

If you answer no to all three, the web probably wins. If you answer yes to the first or third, read on, because the website is only half the picture.

When a Website First Is the Right Call (and When It Is Only a Waiting Room)

A website or mobile app first for an MVP is a real decision, and for plenty of products the website is correct. In my experience it is the right first move when the product is a workflow rather than a moment: dashboards, booking tools, B2B software, marketplaces with a desktop-heavy buyer, content or calculators people find through search.

The advantages are practical. There is nothing to install, so a prospect can try it in thirty seconds. There is no store review standing between a fix and your users. And you can show it to an investor or customer by sending a link. For learning speed on a workflow product, that is hard to beat, and it is why I often tell founders in this position to read build vs buy for an MVP before they commit to any custom build.

There is a second case, and it is easy to confuse with the first. Sometimes the website is not the product. It is a waiting room: a landing page before building an app, with a clear promise, a waitlist and a way to measure whether anyone cares. That is a good idea for almost every consumer app, and it costs days. But it validates demand for the idea, not whether the product works. If your founder test is "will people use this on their phone", a landing page cannot answer it.

So when you ask yourself whether a website vs mobile app for startup is the right order, be honest about which one you are building. A workflow product first on the web is a plan. A waiting room standing in for an app you know you need is a useful step, but it is not the MVP.

When the App Has to Come First, and What to Put on the Website Anyway

Some products are mobile by nature, and building a web version first just delays the real test. The pattern is that the core value depends on something only the device has.

I have shipped products where this was the whole story. Focus Mode blocks apps and sets limits through Apple's Screen Time API, which a website cannot reach. Coin ID Scan is camera-first: take a photo, get an identification and a market value. A web upload form for the same job is a worse product, because the whole appeal is holding the coin and pointing the phone at it. In both cases, "should I build an app or a website first" had an obvious answer once we named the moment of use.

RoomFlash shows the other benefit of picking one surface decisively. It went to the App Store in a single sprint against a hard deadline, because the scope was one platform and one core flow, not a web app plus an app.

Even then, the website still has a job. Put these on the web from the first week:

1. A landing page with one promise. It is where search, social links and press land.
2. A waitlist or launch email list. It gives you a day-one audience and your first usable data.
3. Privacy policy and support pages. The App Store requires URLs for them, so you need a site anyway.
4. A shareable link that points to the store. Smart links make campaigns measurable.

The point of the website in an app-first plan is distribution and trust, not features. Keep it small.

What Going the Wrong Way Looks Like

Both mistakes are expensive, and I have seen both. I've seen founders spend months on a native app for a product that was really a form and a database, then find that customers wanted a link, not an install. I've also been brought in after a website-first build discovered, late, that the core feature needed the camera and background processing, and the team had to rebuild the product around a phone.

Neither failure is about talent. Both come from choosing the surface before naming the moment of use. The fix is cheap: spend one afternoon writing down where the first ten users will be and what they will be doing, then pick the surface that can be present in that moment.

There is also a middle road that founders reach for too quickly: a web app wrapped to look like a mobile app. It can work for simple content and form products. It tends to disappoint when the product needs real device features, reliable notifications or store-level polish, which is why I would not treat a wrapper as a free way to answer "should I build an app or a website first". The framework side of that trade-off is covered in Flutter vs native for a startup MVP.

A Decision Rule You Can Use This Week

Here is the rule I give founders who ask me, "should I build an app or a website first", with the hedges it needs:

• Workflow, B2B, marketplace or search-driven product: web app first, typically. A web app or mobile app first debate usually ends here, because the web removes install friction and speeds up learning.
• Camera, sensors, notifications, background work or OS-level features at the core: app first, with a thin website for distribution.
• Consumer idea you cannot yet describe in one sentence: a landing page and waitlist first, then decide with real sign-up data.
• Both surfaces matter equally: pick the one where the first ten users will actually be, and sequence the other. If the app wins, which store to launch on first is the next decision.

An unsure founder should not guess. Two days of customer conversations will settle most of these cases better than a planning document.

What This Does to Timeline and Budget

Whether you should build an app or a website first also changes the schedule, but I am careful with numbers here, because they vary widely with scope. In my experience, a focused single-surface MVP built with an AI-augmented workflow (Claude Code, Cursor and Figma MCP, with a senior engineer reviewing everything) typically lands in the 2–4 week range when scope and designs are settled, and 4–6 weeks for production-grade. Building a website and an app together is not a sum of the two; the shared work is in the product thinking, the backend and the design system, so it pays to plan them as one project even when you ship them in sequence.

The practical effect is that the "cheap website first" shortcut saves less than it looks like when the app is the real product, and the "app first" instinct costs more than it should when the product is a workflow. The shape of the product decides which of them is the economical option.

The Bottom Line

Treat "should I build an app or a website first" as a question about where your users will be when the product matters, not about which build is cheaper. Name the first ten users, name the moment of use, and choose the surface that can be present in it. If the website is a waiting room, build it fast and treat it as marketing. If the app is the product, ship the app and keep the site small. If you want a straight answer for your own idea, tell me about your project, or see the engagement model on the services page to understand how I work.