Product choices
Web app, PWA or mobile: which solution fits your project?
Compare web apps, PWAs, hybrid and native mobile against usage, devices and what already exists. A practical framework for defining a first version.
The short answer
The right model depends on the actions to complete, devices used and distribution constraints. Define these needs before choosing between a browser, an installable app and mobile app stores.
- A web app suits journeys available in a browser, on desktop and mobile depending on its design.
- A PWA can add an installable experience; offline workflows and notifications need their own scope.
- Hybrid and native mobile have different scopes: examine existing assets, target platforms and required capabilities.
- WebAccess through a browser
- PWAAn installable application
- MobilePhone-based usage
Start with three concrete actions
“We need an app” does not yet say what to build. Does a customer need to book a service from a link? Does an employee need to enter data in the field? Does an administrator spend all day on a computer? Describe the main actions, their frequency and usage context before choosing a platform.
For a first version, distinguish what the service needs now from what could come later. Logged-in areas, roles and a back-office describe features, not an obligation to publish in app stores. Conversely, a hardware constraint or field use may require technical checks before approving a web solution.
- What are the three actions the user must be able to complete?
- On which devices and in what context do they do them?
- Do they have a connection while carrying out these actions?
- How do they find the service: a link, web search, internal tool or app store?
- Is there already a reusable design, application or API?
Web, PWA, hybrid and native: the useful differences
A web app runs in a browser. A PWA remains a web app, with added capabilities such as installation on compatible devices. A hybrid mobile app shares a development codebase across several platforms; native is designed specifically for the target platform. These models alone do not determine the quality of the experience.
| Model | A useful starting point | What to check when defining scope |
|---|---|---|
| Web application | A service accessible from a browser link | Journeys at each screen size, permissions and data exchanges. |
| PWA | Web usage with an installable experience | Browsers, installation, caching and behaviour without a network. |
| Hybrid mobile | Mobile usage covered with a shared codebase | Reusable elements, required capabilities and iOS/Android testing. |
| Native mobile | A need designed for a specific platform | Chosen platform, available API and device-specific features. |
An installable PWA does not mean an offline business workflow
Installing a web app depends on the browser and platform. Agree which devices to support and check the experience on them. Caching can make some resources accessible without a network; it does not automatically turn booking, payment or business data entry into an offline operation.
The standard CUB3 PWA offer covers installation, icons, static-resource caching and an offline screen. Offline data entry and later synchronisation need dedicated design: what does the device retain, when does it send changes back, and what happens if information has changed in the meantime?
Notifications also need clarification. On compatible versions of iOS and iPadOS, Web Push applies to web apps added to the Home Screen and remains subject to user permission. Check the conditions on the target devices. A technically possible feature is not automatically included in a starting offer.
For mobile, have existing assets assessed
Taking over a mobile app and creating one from scratch do not require the same work. The design, available modules and APIs determine what can be reused. An API is the interface that lets the app exchange with its data and services: its actual capabilities must be understood before pricing the screens that depend on it.
CUB3’s starting hybrid offer covers an agreed takeover of an existing app, with retained design and reusable modules. The starting native offer targets an MVP for one platform, iOS or Android, with an existing usable API. An entirely new hybrid app, a backend to build or a second native platform need a tailored estimate. The offers detail these assumptions.
Mobile distribution adds steps too: preparing store requirements, submission and external approvals. Distinguish these from the end of development. The schedule should explain what the team controls and what depends on distribution.
Promo.dev: a web and mobile product with separate deliveries
For Promo.dev, CUB3 built a React web app and React Native mobile apps with a shared component system. Shopify handled the catalogue, payments and inventory; an API layer covered business logic and integrations. The technical choice considered what could be entrusted to an existing service and which experience needed custom development.
The web app was ready for production in twenty-eight days. The mobile apps were developed, with additional time linked to app-store approvals. This case shows why shared scope, interfaces and distribution should be distinguished. It does not mean every project should start on three platforms or use this architecture.
Prepare a budget from the required features
First choose a plausible model, then list the required features: accounts and login, role management, administration, search, payment or notifications. Add presentation pages separately from the screens needed for those features. The CUB3 simulator provides an initial reference; the quote confirms scope, integrations and constraints after discussion.
When comparing proposals, look beyond screens at what is included: design, testing, production release, possible store submission and follow-up. Separate third-party service fees and maintenance from the delivery budget. If a capability remains uncertain, ask for it to be checked before choosing the model.
In the field
A real project
A custom web frontend, React Native apps and an existing commerce engine, with a clear distinction between development and app-store approval.
Promo.dev’s web and mobile product