"We need an app" is usually the first sentence in the meeting, and it is usually not the question. An app is one of three ways to deliver a product to a user, and each has cases where it is the right choice and cases where it is a waste. This guide does not recommend a tool or a platform; it gives the questions that decide between the three — and the conditions under which you move from one to another. Choosing the app technology itself (React Native, Flutter, native) happens only after it is decided that an app is needed at all, and that is a subject for a different guide.
What does the user have to do? Action, frequency and device
Before comparing options, describe the use in three variables. That description — not someone's preference in the room — is what decides in most cases:
| Variable | The question | Where it points |
|---|---|---|
| Action | What does the user actually do — read, fill in, photograph, pay, navigate, communicate? | Actions needing hardware (continuous camera, background location, Bluetooth, scanning) point to an app; reading, filling in and paying work in a browser |
| Frequency | How many times a day / week / year does the same user come back? | Several times a day — an icon on the screen is worth the install; a few times a year — nobody will install |
| Device and conditions | A personal phone, a tablet in a warehouse, an office PC? Is there always a network? Who decides what gets installed? | Offline work and managed devices point to an app; an office PC and external users point to the browser |
Three options: capabilities and limits by use
A store app
An installed app gives the fullest access to the device: sensors, background location, notifications that arrive even when the app is closed, offline work with later sync, and an icon on the screen reminding the user the product exists. The price is not only development for two platforms — it is also a process: the stores review every version, and an update reaches the user only when they update. Apple also sets a content bar: the App Store Review Guidelines (section 4.2, "Minimum Functionality") require an app to offer features and an experience beyond a repackaged website, and may reject an app that is mainly marketing content or a website inside a wrapper. In other words, an app that is just your website with an icon is not only unnecessary — it may not be accepted.
- Fits when: the action repeats a lot; sensors or background work are needed; it must work offline; notifications are part of the service, not a marketing reminder.
- The limit in context: two platforms to maintain, a release cycle through the stores, and users on old versions. For a product that changes weekly this is heavy; for a stable product it is reasonable.
What our app development service includes — the situations where it is right, the deliverables and what happens after launch — on the service page. App development — the situations where it is right
A browser product: responsive web or PWA
A browser product is one version that runs on every device, updates without asking the user for anything, and opens from a link — a message, an email, a search result. No store, no review process, no install. A PWA (Progressive Web App) is the same version with extras: it can be added to the home screen as an icon, it can partly work offline, and on current operating systems it can also send notifications — Apple added Web Push support for web apps added to the Home Screen in iOS and iPadOS 16.4 (per the WebKit team's announcement). Hardware access is still set by what the browser and OS allow, and it is narrower than an installed app's — mainly for background work.
- Fits when: use is occasional or the user arrives from a link; there are external users who will not install anything; the product changes often; it has to work on a desktop too.
- The limit in context: no store presence (relevant if your users search there), and device capabilities depend on the browser. If the core action is continuous scanning or background location — this is not the place.
When the browser product is a system — roles, data and processes rather than content screens — the web systems service page lists which kinds of systems we build and what is included. Web systems and portals development
No-Code / Low-Code
No-Code and Low-Code tools let you assemble a working product — forms, tables, processes, sometimes an app too — without writing code, or with little of it. The real advantage is not only set-up speed: it is that whoever operates the product can also change it, without opening a task for a developer. For a first version that tests whether anyone wants the product at all, or for an internal process with a few dozen users, it is often the right choice — and whoever recommends custom development instead, without a measurable reason, is recommending waste.
- Fits when: it is not yet clear what the product should be; the users are internal and few; the operator is not a developer; time to launch matters more than future flexibility.
- The limit in context: the tool defines what is possible. As long as the need stays inside the boundary — excellent; the problem is that the boundary is usually discovered once there are already users and data. That is why the exit conditions (below) are set on day one, not on the day you get stuck.
Who will operate and change the product? Team, vendors and usage costs
This is the question that gets skipped, and it decides more than the technology does. A live product needs someone who adds a field, changes a process, handles a stuck user and ships an update. The answer differs per option:
| App | Web / PWA | No-Code | |
|---|---|---|---|
| Who changes it | Developers; every change goes through a build and a store release | Developers; a change goes live immediately for every user | The operator, inside the tool's limits; beyond them — a developer or the tool vendor |
| Usage cost structure | Store developer accounts, servers, third-party services — mostly not tied to user count | Hosting and services — grows with load, not with seat count | A platform subscription usually measured in seats, records or runs — grows with success |
| Vendor dependency | On the stores (rules, review, fees) and on the development team | On the development team; the code and data are yours | On the platform: if it changes price, capability or export terms, it affects you directly |
| The question to ask first | Who holds the developer accounts, and who ships releases after the project ends? | Who holds the domain, the hosting and the source code? | How is all the data exported, in what format, and can the logic be reproduced outside the tool? |
When do you move to custom development? Measurable constraints and data hand-over
Moving from No-Code (or from a simple website) to custom development is not a failure — it is the next stage, if you planned it. The problem is when the move happens under pressure, because the tool got stuck the day the big customer signed. So define three or four measurable exit conditions in advance, and check them every quarter:
- Usage cost: the platform subscription crossed a figure you set — or the estimated yearly cost of building and maintaining the same thing. (Your number, not ours.)
- Performance: a core action exceeds a response time you set, or the tool caps record / call volume and you are approaching it.
- Capability: an action the tool does not support is needed — a calculation, an integration, a permission — and the workaround is more complex than the problem.
- Customer requirements: a business customer demands an availability, security or data-residency commitment the platform will not put in writing.
The condition that decides whether the move will be an orderly project or a rescue is data hand-over. Before choosing a tool, confirm: that all the data (not only the main table) can be exported in an open format; that the relationships between records survive the export; and that the logic — processes, calculations, permissions — is documented somewhere that does not depend on the tool. If any of the three fails, the future move will cost more than everything that was saved.
A related but different situation: a product built quickly in AI-generated code that now has to become a production system. The difference between the two, and what is checked in the move — in a separate comparison. Vibe coding vs production engineering — what is checked in the move
Decision map — a non-binding aid
The map below condenses the guide into an order of questions. It rests on two assumptions to check first: that the answers about action, frequency and device are known (not guessed), and that someone will operate the product after launch. If either assumption fails — that is the first question, not the map.
- Does the core action need sensors, background work or offline work? Yes → an app (then choose the technology). No → continue.
- Is it still unclear what the product should be, or are the users internal and few, and is the operator not a developer? Yes → No-Code for a first version, with exit conditions and a data-export check before starting. No → continue.
- Are the users external, arriving from a link, or does the product need to work on a desktop too? Yes → a browser product; if a home-screen icon or notifications matter — a PWA.
- Does the action repeat several times a day with no hardware constraint? → Both options are possible; the decider is who changes the product and how fast. Weekly change points to the browser.
- Are there two user types with different answers? → Two front-ends on the same backend, not one compromise that fits nobody.
What we do at this stage
In a first meeting we go through the three variables with you — action, frequency, device — and who will operate the product, and reach a recommendation on the product type before talking about development. Sometimes the recommendation is No-Code for a first version, and then our offer is defining the exit conditions and checking the export, not development. When the recommendation is a first version in code — the MVP — this is how we define and build it. MVP development — how a first version is defined and built
And if it is already clear that the product is a first version in code, the next question is what goes into it and what does not — a separate guide to MVP scope. How to define the scope of an MVP