# Should an AI-built app ship as an installed app or a web page? Decide by trust and reach

> Users are wary of installing apps built fast with AI. Decide between an installed app and a web page by trust, reach and update needs, then choose what to ship first.
> By Dave · 2026-11-03
> Source: https://otf-kit.dev/blog/why-install-ai-built-app-instead-of-web

Should an AI-built app ship as an installed mobile app, or as a web page? Choose by what users must trust before they install, how far they need to reach, and how often you must update. Trust is the constraint most builders underweight, because a web page asks for less of it.

A Hacker News thread asked whether people hesitate to install apps built with AI tools. The comments split. Some people never install them, or only in an isolated environment. Others say the bigger concern is quality: that such apps are often quickly abandoned and full of bugs. This is one discussion, with opinions, not a measurement, but it names the two worries a buyer brings to an install: security and whether the app will be maintained.

## Trust is the first question

An install asks for more than a page view. The user grants a device-level permission set, keeps a copy of the code on their phone, and accepts an update path you control. A web page asks for a visit and sometimes a sign-in. If your audience is careful, start with the web, and add an installed app only when a clear feature needs it. Review the AI-called routes too: [the spend-leak check for AI routes](/blog/vibe-coded-ai-route-spend-leak-check) covers the server side that a web page also exposes.

Trust is not only about the code. Users judge a product by its visible care: a working sign-in, a clear privacy note, a support address, and a changelog that shows the app is maintained. Those signals matter more than the tool that produced the first version.

## Reach and updates decide the second question

A web page reaches anyone with a link. It updates the moment you deploy, and nobody has to approve a store review. An installed app reaches people who open it often, can send notifications, and can work offline, but each release travels through a store or a distribution channel, and an old version can stay on a device for weeks.

If your product is used daily from a phone, such as a workout log or a habit tracker, the installed app earns its cost. If people use it once a week, or only on a laptop, a responsive web page is often the better first release.

![Diagram of a codebase branching to an installed-app phone and a web link, beside the current Fitness Kit Workout screen in DevicePhone; sample UI and demo data.](https://cdn.otf-kit.dev/blog/why-install-ai-built-app-instead-of-web/inbody1-20261103-8fbee38b-v1.png?v=20261103-8fbee38b)

*Install versus web is a delivery choice. The Fitness Kit Workout screen and demo values are shown as sample UI; the browser-link symbol is illustrative.*

## A decision table you can fill in

Use four rows to choose the first release. Fill each with evidence you already have, not a guess.

| Question | Points toward the web | Points toward an installed app |
| --- | --- | --- |
| How often do users return? | Occasional use | Daily or near-daily use |
| Do they need offline or device features? | No | Yes, such as local storage or notifications |
| How fast must fixes reach users? | Same day | Store review is acceptable |
| How much trust does the first visit need? | Low to moderate | High, with a visible track record |

If most rows point one way, follow them. If they split, ship the web version first and test whether the native features are needed before building the store release.

## Build one shared codebase when you can

A common middle path is one codebase that produces a web version and native apps. That reduces duplicate work, but it does not remove the trust question. A web version can be the first thing a careful visitor sees, and it gives you a place to show the app's behaviour before they install anything.

The OTF Fitness Kit is one example. Its page describes a mobile template for iOS, Android and web, built from one Expo codebase with a real database. It gives you a starting point that targets all three. It does not make your app trustworthy by itself, and it does not audit the code for security. Those checks are yours before you ask anyone to install.

You can click through the running app at the [live demo](https://fitness-preview.otf-kit.dev) to see the screens before you decide which release to ship first.

## Make the install decision easier to trust

Whatever you ship, make the next step explicit. A web visitor should see what the app does on the first screen, with no sign-in wall until the value is clear. An installer should see a short description of what the app asks permission for, and why.

Publish a changelog and a support address before the first install. A visible record of fixes is the simplest answer to the "abandoned slop" worry in the thread. It shows that someone reads reports and ships corrections.

Test with people who are sceptical of installs, not only with people who already like them. Ask them what would stop them, then fix that before the store listing.

## What the first release should show

Whichever channel you pick, the first release should answer three questions before anyone is asked to commit. What does the app do in the first minute? What data does it keep, and where? How do I reach a person if something breaks?

Keep the first minute free of walls. Show a real example of the main task, with sample content clearly marked as sample, so a visitor understands the value before creating an account. A visitor who sees a working example is more willing to trust the app than one who sees a sign-up form on an empty page.

Be specific about data. Name what the app stores, where it lives, and how a user removes it. A sentence such as "your workouts are stored on our server and you can delete them from settings" is more useful to a careful user than a general promise about security. Only write the sentence once the deletion path works.

Answer the support question with a real address and a response time you can keep. A reachable person is the strongest counter to the worry that a fast-built app will be left to rot.

![Luna and Byte inspect the current Fitness Kit Nutrition screen inside DevicePhone; nutrition values are sample data.](https://cdn.otf-kit.dev/blog/why-install-ai-built-app-instead-of-web/inbody2-20261103-7b4ab327-v1.png?v=20261103-7b4ab327)

*Fitness Kit demo screen; nutrition values are sample UI.*

## What to avoid promising

Do not promise that the app is secure, audited, or free of bugs unless you have done that work and can show the evidence. A sentence such as "fully secure" invites the exact scrutiny the thread describes, and it is easy to disprove.

Do not describe a starter kit as a security review. A kit gives you a structure and a set of screens. The checks that decide whether an installed app is safe to run are still yours: dependency review, permission scope, data handling, and the code paths that touch the network. For the bugs a dev client hides, walk the release build by hand; the [Expo pre-launch checklist](/blog/expo-prelaunch-silent-ui-gaps) lists the common ones.

Avoid comparing your app with a store app on features you have not built. A careful buyer will test the claim, and a single gap undoes the rest of the page.

## A short checklist before you choose

1. Write down how often a target user needs the app in a typical week.
2. List the device features you truly need. If the list is empty, start with the web.
3. Decide how fast a bug fix must reach users.
4. Publish a support address and a changelog before asking for an install.
5. Ship the web version first if the evidence is mixed, then test the native need.
6. Review security and data handling yourself before any release, whichever channel you choose.

## Sources

- Hacker News, "Ask HN: Are you hesitant to install vibe-coded apps?", posted 14 Oct 2026: https://news.ycombinator.com/item?id=50090796 (a discussion thread, opinions only; not a survey).
- OTF Fitness Kit page, checked 3 Nov 2026 (HTTP 200): https://otf-kit.dev/templates/fitness-kit