'We need an app' is one of the most common opening lines of a first call — and one of the least precise. What people mean is almost always something concrete: customers should book appointments, field staff should capture data, members should access content, patients should log readings. Whether that requires an app-store listing or a web app that installs to the home screen is a technical follow-up question. We settle it first, because it drives budget, timeline and running costs for years.
What we mean by app development
Our focus is web applications and Progressive Web Apps. A web app runs in the browser and adapts from phone to large screen. A PWA goes further: it installs on the device like an app, launches without browser chrome, keeps working on poor or missing connections thanks to a service worker, and can send push notifications. For the large majority of business software — portals, bookings, data capture, self-service, internal tools — that is the right form.
We do not build native store apps in Swift or Kotlin ourselves, and we don't pretend to. When a requirement genuinely calls for a store app, we take on the parts where such projects most often fail: the decision itself, requirements analysis to the IREB standard, the concept, selecting or tendering the delivery partner, and project management. A store-app project with a clean requirements catalogue and independent steering is a different project from one that starts with an agency quote.
When a PWA is enough — and when it isn't
A PWA is enough when the application mainly displays, captures and syncs data, models forms and workflows, needs notifications, and uses the camera, location or files. It is not enough when the product reaches deep into device capabilities: persistent background processing, Bluetooth peripherals such as measuring devices or wearables, NFC, system-level widgets or demanding real-time graphics. Browsers expose these interfaces only partially, and noticeably less on iOS than on Android.
There are non-technical reasons too. Some audiences only look for software in the store, some industries treat a store listing as a trust signal, and some business models depend on in-app purchases. Conversely, a lot speaks against the store when users already arrive via the website, a link or a QR code: every extra install step loses users, every update has to pass review, and the stores take a commission on digital purchases. Our recommendation weighs both, in writing and with reasons.
The stack: why Next.js and Supabase
We build on Next.js with the App Router, TypeScript throughout, Supabase as database, auth and storage layer in the Zurich or Frankfurt region, and Vercel or EU infrastructure for hosting. The combination is not the most exotic but the most maintainable: a large developer community, long-term maintained tooling, and a PostgreSQL data model that belongs to you and can be exported. Tenant isolation is enforced with row-level security in the database itself, not just in the frontend.
A PWA adds a web app manifest, a service worker with a deliberate caching strategy and, where needed, local storage in the browser that reconciles with the server on the next connection. Offline capability is not a yes-or-no property: per feature we define what stays readable, what can be captured and what is locked without a connection, and how sync conflicts are resolved. Those are business decisions, not technical ones, so they belong in the concept.
Data protection from the first table
Software for Swiss and DACH customers almost always processes personal data. We plan data minimisation, storage location, deletion and processor agreements before the first table exists — under the Swiss revFADP and, where EU users are involved, the GDPR. For a PWA this includes which data may be cached on the device and for how long. Data protection added afterwards is more expensive and leakier than protection designed in from the start.
From prototype to production
A growing share of enquiries starts with a prototype built with an AI app builder or no-code tool. That is a good start: the idea is tangible, first users have reacted. For production, however, such prototypes typically lack proper permissions, tests, a robust data model and maintainable code. We treat the prototype as a specification, not as the codebase, and build the application on a stack you can run long-term.
How a project runs
It starts with short scoping: who uses the application, on which devices, in which situation, with which data? That yields the decision between web app, PWA or store app and a clearly bounded first scope. We then deliver iteratively in short cycles with working builds on a staging environment so real users can test early. At the end we hand over code, access and documentation — you stay independent, including from us.
Why Innopulse
We are an engineering and advisory firm in Zug that runs its own products on exactly this stack. The architecture we propose is not a slide but everyday operations — billing, auth, data protection and search visibility included. And because we don't sell native apps ourselves, our PWA-or-store-app recommendation is not shaped by a utilisation interest.
If you are planning an application and want to know which form fits, a first call is the cheapest step. The first 30 minutes are free, and afterwards you will know whether a PWA is enough.