Free tool · No email required
Do I need an app or a website?
Tick what the product genuinely has to do. The verdict appears as you tick, and it names the one requirement that forced it. There is no email gate, no signup and no score, because a score would let us hide the reasoning. Nothing you enter leaves your browser, since nothing is sent anywhere.
This decision is more determinate than the search results suggest. A handful of device capabilities have no browser equivalent, and if you need one of them you need an app regardless of what any retention chart says. If you need none of them, you don’t. We quote mobile from $20,000 and marketing sites from $7,500, so returning “you do not need an app” costs us money. It is still usually the right answer. The reasoning is written out at length in does your product actually need a mobile app.
Verdict for your product
One codebase, one release, no store, no install.
What forced it
Nothing. Not one requirement you gave has a floor above the open web, so there is no gate to clear and no case to make. Build a responsive web app. If someone in the room still wants an app, that is a business argument rather than a technical one, and it should be made as one.
Every rule, and whether it fired
There is no score and no weighting. Each rule sets a floor when it fires, and the verdict is the highest floor set. The last column is the running answer after each row, which is the entire arithmetic of this tool.
| Rule | Fired | Running |
|---|---|---|
| Background locationFloor: native | No | no floor |
| Bluetooth LE or NFCFloor: native | No | no floor |
| Offline writes that flush themselvesFloor: native | No | no floor |
| Push notifications on iOSFloor: installable web | No | no floor |
| Biometric-gated data held on the deviceFloor: native | No | no floor |
| Health or wearable dataFloor: native | No | no floor |
| Camera or scanning pipelineFloor: no floor | No | no floor |
| Augmented realityFloor: native | No | no floor |
| Contacts or the device calendarFloor: native | No | no floor |
| Files on the deviceFloor: installable web | No | no floor |
| Push on iOS is the daily loop for a consumer productFloor: native | No | no floor |
| Two or more platform subsystems on the critical pathFloor: fully native | No | no floor |
| Opened a few times a yearFloor: no floor | No | no floor |
| Sells digital goods or subscriptions consumed in the productFloor: no floor | No | no floor |
What this verdict costs you
Every answer here has a price that is not money. This is the one attached to yours.
- No push on iOS, and no background anything
- You can reach an Android user in a browser. You cannot reach an iPhone user unless they add the site to their Home Screen first, and almost nobody does that unprompted. Nothing runs while the tab is closed on either platform.
- No store listing
- That is a cost only if people search a store for products like yours. For most business software they do not, and the cost is zero. For a consumer category with an established app habit it is real.
- You own the whole surface, which cuts both ways
- No review queue, no forced update, no commission, no platform policy change landing in your quarter. Also nobody else driving discovery, and no icon sitting on the home screen reminding anyone you exist.
Indicative band
From $7,500 for a marketing site, from $28,000 for a platform
An MVP-scope build starts at $24,000 on the same posted list. Which of the three you are looking at depends on how much of the product is behind a login, not on the medium.
An estimate in US dollars, not a quotation; the quote you get after scoping is fixed in writing before kickoff.
This tool did not calculate that band and could not, because a medium is not a scope. For arithmetic with line items in it, use the MVP cost estimator.
When this answer changes
Not if. The gates are browser API availability and platform policy, and both move. Put these on a list somewhere.
- The day a requirement on the capability list stops being a nice-to-have and becomes a commitment to a customer. That is the trigger, not a quarter on a roadmap.
- The day reaching a closed iPhone becomes load-bearing rather than convenient. Today that means asking for a Home Screen install; if WebKit ever ships push without one, this row disappears.
- The day someone has to record work with no connection and walk away without reopening the tab. If WebKit ships Background Sync, that gate stops being a gate and this verdict gets stronger rather than weaker.
- If your device split moves decisively toward iOS. Several of the softened rows on this page are softened because Chromium implements something WebKit does not.
- When the answer changes, only the client changes. The backend, the data model and the auth work carry over, which is why building the web surface first is rarely wasted money.
This decides the medium, not the stack
“You need an app” is not the same sentence as “you need React Native” or “you need Swift”. This tool answers the first and refuses the second, because the second depends on your team, your hiring plan and which native subsystems sit on the hot path. That argument is a different one and we have written it out in React Native vs native iOS and Android.
How to read the verdict
The verdict is a floor, not a recommendation. It says the least expensive medium your requirements permit. It does not say that medium is the one you should build, and it never says an app is a good idea. If it comes back “responsive web app”, that means nothing on your list needs a phone. You’re still free to build an app. You’ll just be choosing to pay for one rather than being forced into one, and that’s a much better position to be in when the quotes arrive.
Read the non-binding list before you read the verdict. That list is where the argument in your own building usually lives, because it names the things somebody was sure would settle it and didn’t. Then read the counterfactual line. If dropping one requirement moves the answer from a native app to a web app, you now know the price of that requirement, and you can go and ask whether anybody would actually miss it.
The four mistakes
Treating a checkbox as a specification. “We need offline” means a read-only cache to one person and a conflict-resolving sync engine to another. The first is a week. The second is the product. Before you spend anything on the back of a gate, write the user story that fails without it, in one sentence, with a real person in it. Requirements that survive that test are requirements. The rest are preferences that borrowed the word.
Reading the retention statistics backwards.Nearly every article on this question opens with a chart showing that app users are more engaged than web users. The number is real and the causation runs the other way. Your most committed customers install the app because they were already your most committed customers. Installing didn’t create the commitment, it revealed it. Ship an app to an audience that has none and you get the install rate, not the engagement.
Buying an app to fix distribution.Store search works for categories people browse and for products they already know by name. It does not work as a discovery channel for software nobody is looking for yet. If growth is the problem, an app moves you from a surface that search engines index to one they mostly don’t, which is the opposite of the intended effect. That is why the tool flags a second web surface every time discovery and a native verdict appear together.
Deciding the medium and the stack in one meeting. They are different decisions with different inputs, and merging them is how a conversation about user needs becomes a conversation about frameworks in under ten minutes. Settle the medium first, with a gate list. Then argue about the stack, which depends on who you can hire and how much native code sits on the hot path.
When the answer is no and somebody senior wants an app
Don’t argue with the preference. Ask what the app is for. If the answer is push notifications, an installable web app delivers them and costs a slice of a web build. If it is the icon on the home screen, an installable web app puts one there. If it is looking credible next to a competitor, that is a real thing to want and it has cheaper cures than $20,000 and two release trains. If it is one of the gates, the tool already said so and named it, and you have the sentence you need.
The useful output of this exercise is rarely the verdict. It is the list of things that turned out not to matter, and the one thing that did.
Keep reading
- Does your product actually need a mobile appEvery gate in this tool, written out with the reasoning behind it.
- React Native vs native iOS and AndroidThe next decision, once the medium is settled. Stack, not medium.
- Cross-platform mobile app developmentWhat we build when a gate genuinely fires, and what it costs.
- Next.js web application developmentThe answer this tool returns most often, and the cheaper one.
- MVP cost estimatorOnce the medium is settled, the line-item arithmetic for the build.
- All free toolsEvery one of them ungated, and every one of them shows its working.
Pressure-test the gate.
Send us the requirement this tool says forced your answer, and the user story behind it. We’ll tell you whether it holds, even when the answer costs us the more expensive project.