Website or app first? How to pick the shape of your MVP.

The order that works for most startups: a landing page that says what the product is, a web app that proves someone will use it, and a native app only once the product has earned a place on the home screen.

Skipping the first step costs a few weeks of confused users. Skipping the second costs the app store review cycle every single time you learn something, which is the expensive one.

Where the product is used decides almost everything

Web app

Desk, browser, deliberate sessions.

• -Ships in minutes, changes the same afternoon
• -No review queue, no version fragmentation
• -One codebase, one URL you can put in an email
• -Fine for AI features, file handling and long sessions
• -Weak at: notifications, camera, offline, being remembered

Native app

Pocket, camera, sensors, interruptions.

• -Earns a home-screen slot and a notification channel
• -Real access to hardware and background work
• -Waits for review, and for users to update
• -Two platforms unless you pick a cross-platform stack
• -Weak at: iterating daily, which is what early products do

The honest test is whether the product is used at a desk or on the move during the first hundred users. Founders answer for the eventual product, which is how a team ends up in a review queue while still trying to work out what the product is.

How often will this change

Early products change daily. A web app deploys in minutes; a native app waits for review and then waits again for users to update, which means you are supporting several versions of a thing you are still designing.

That gap compounds. Six weeks into a native build you are making decisions to avoid another submission, and avoiding submissions is not a product strategy.

The landing page is not a brochure

It is the cheapest experiment available. Does the sentence at the top make the right people click the one button?

A landing page with a waitlist has killed more bad ideas than any MVP, at a fraction of the cost, and the ones it does not kill arrive at the build with a list of people to talk to. Building the product first inverts that: you learn who wanted it after you have already decided what it is.

Practical version: one page, one claim, one action, and a way to reach whoever signs up. If it does not convert, the problem is the claim, and no amount of app solves a claim problem.

Who is building it

One senior engineer can carry a web app and add a thin native shell later. Two separate teams from day one doubles the cost of every change, because every change is now a negotiation.

This matters more than it sounds. A small product with two platform teams spends most of its early velocity on keeping the two in sync, and that spend is invisible on any roadmap.

AI features push you toward web or desktop

Transcription, generation and agent workflows live comfortably in a web app or a desktop app and are painful to ship natively on day one. Model access, long-running jobs and large files all fight the mobile sandbox.

Vanpelt Studio, this studio's own product, is a desktop app for exactly that reason: it indexes whole memory cards locally, which is not a thing a phone should be asked to do.

What to prepare before you write to anyone

• The one action a user takes that means the product worked.
• Whether that action happens at a desk or on the move.
• How you will get the first fifty users, in a sentence.
• What you already have: designs, a prototype, a repo, a spreadsheet of users.
• The date something has to be in someone's hands, and what happens if it is not.

What this studio does

A one-week discovery turns the idea into a scoped build and settles the shape, whether that is a landing page, a web app, native or desktop, before any code is written. Then weekly demos on a live preview until launch.

See Apps and Websites, and the shipped work on the Work page.

Sources and further reading

• tvcast: a small open-source tool

  Vanpelt VenturesA worked example of picking desktop over web because the product needed the local network and the screen, not a browser tab.

• Vanpelt Studio case study

  Vanpelt VenturesWhy a video tool that indexes footage locally had to be a desktop app rather than a web one.

• ScreenCaptureKit

  Apple Developer DocumentationAn example of the platform capability that decides the question: some things simply cannot be done in a browser tab.