«Wir brauchen eine App» ist einer der häufigsten Sätze, mit denen ein Erstgespräch beginnt — und einer der ungenauesten. Gemeint ist fast immer etwas Konkretes: Kunden sollen Termine buchen, Aussendienstmitarbeitende Daten erfassen, Mitglieder Inhalte abrufen, Patienten Werte protokollieren. Ob dafür eine Anwendung im App Store nötig ist oder eine Web-App, die sich auf dem Startbildschirm installieren lässt, ist eine technische Folgefrage. Wir klären sie am Anfang, weil sie über Budget, Zeitplan und Betriebskosten der nächsten Jahre entscheidet.
Was wir unter App-Entwicklung verstehen
Unser Schwerpunkt sind Web-Applikationen und Progressive Web Apps. Eine Web-App läuft im Browser und passt sich vom Smartphone bis zum grossen Bildschirm an. Eine PWA geht einen Schritt weiter: Sie lässt sich wie eine App auf dem Gerät installieren, startet ohne Browserleiste, funktioniert mit einem Service Worker auch bei schlechter oder fehlender Verbindung und kann Push-Benachrichtigungen senden. Für die grosse Mehrheit der Geschäftsanwendungen — Portale, Buchungen, Erfassung, Self-Service, interne Werkzeuge — ist das die passende Bauform.
Native Store-Apps in Swift oder Kotlin bauen wir nicht selbst, und wir behaupten es auch nicht. Wenn eine Anforderung tatsächlich eine Store-App verlangt, übernehmen wir die Teile, in denen ein Vorhaben am häufigsten scheitert: die Entscheidung selbst, die Anforderungsanalyse nach IREB-Standard, das Konzept, die Ausschreibung oder Auswahl des Umsetzungspartners und die Projektleitung. Ein Store-App-Projekt mit sauberem Anforderungskatalog und unabhängiger Steuerung ist ein anderes Projekt als eines, das direkt mit einem Agenturangebot startet.
Wann eine PWA reicht — und wann nicht
Eine PWA reicht, wenn die Anwendung vor allem Daten anzeigt, erfasst und synchronisiert, Formulare und Workflows abbildet, Benachrichtigungen braucht und auf Kamera, Standort oder Dateien zugreift. Sie reicht nicht, wenn das Produkt tief in die Gerätefunktionen eingreift: dauerhafte Hintergrundprozesse, Bluetooth-Geräte wie Messgeräte oder Wearables, NFC, systemnahe Widgets oder aufwendige Echtzeit-Grafik. Der Browser stellt diese Schnittstellen nur eingeschränkt bereit, auf iOS spürbar enger als auf Android.
Dazu kommen nicht-technische Gründe. Manche Zielgruppen suchen eine Anwendung ausschliesslich im Store, manche Branchen erwarten eine Store-Präsenz als Vertrauenssignal, und manche Geschäftsmodelle hängen an In-App-Käufen. Umgekehrt spricht vieles gegen den Store, wenn die Nutzer ohnehin über die Website, einen Link oder einen QR-Code kommen: Jeder zusätzliche Installationsschritt kostet Nutzer, jedes Update muss eine Prüfung passieren, und auf digitale Käufe im Store fällt eine Provision an. Unsere Empfehlung wägt beides ab, schriftlich und mit Begründung.
Der Stack: warum Next.js und Supabase
Wir bauen auf Next.js mit App Router, TypeScript durchgehend, Supabase als Datenbank-, Auth- und Storage-Schicht in der Region Zürich oder Frankfurt und Vercel oder einer EU-Infrastruktur für das Hosting. Diese Kombination ist nicht die exotischste, sondern die wartbarste: grosse Entwickler-Community, langfristig gepflegte Werkzeuge, und ein Datenmodell auf PostgreSQL, das Ihnen gehört und sich exportieren lässt. Mandantentrennung setzen wir mit Row-Level-Security direkt in der Datenbank durch, nicht nur im Frontend.
Für eine PWA kommen ein Web-App-Manifest, ein Service Worker mit einer klaren Caching-Strategie und — wo nötig — eine lokale Datenhaltung im Browser dazu, die sich beim nächsten Kontakt mit dem Server abgleicht. Offline-Fähigkeit ist dabei keine Ja-Nein-Eigenschaft: Wir legen pro Funktion fest, was ohne Verbindung lesbar, was erfassbar und was gesperrt sein soll, und wie Konflikte beim Abgleich aufgelöst werden. Diese Entscheidungen sind fachlich, nicht technisch, und gehören deshalb ins Konzept.
Datenschutz von der ersten Tabelle an
Anwendungen für Schweizer und DACH-Kunden verarbeiten fast immer Personendaten. Wir planen Datenminimierung, Speicherort, Löschkonzept und Auftragsverarbeitung mit, bevor die erste Tabelle entsteht — nach revDSG und, wo EU-Nutzer betroffen sind, nach DSGVO. Bei einer PWA gehört dazu auch die Frage, welche Daten auf dem Gerät zwischengespeichert werden dürfen und wie lange. Nachträglich eingebauter Datenschutz ist teurer und lückenhafter als von Beginn an mitgedachter.
Vom Prototyp zur produktiven Anwendung
Ein wachsender Teil der Anfragen beginnt mit einem Prototyp, der mit einem KI-Baukasten oder No-Code-Werkzeug entstanden ist. Das ist ein guter Start: Die Idee ist greifbar, erste Nutzer haben reagiert. Für den produktiven Betrieb fehlen solchen Prototypen aber typischerweise saubere Berechtigungen, Tests, ein belastbares Datenmodell und ein nachvollziehbarer Code. Wir übernehmen den Prototyp als Spezifikation, nicht als Codebasis, und bauen die Anwendung auf einem Stack, den Sie langfristig betreiben können.
Wie ein Vorhaben abläuft
Am Anfang steht ein kurzes Scoping: Wer nutzt die Anwendung, auf welchen Geräten, in welcher Situation, mit welchen Daten? Daraus entsteht die Entscheidung Web-App, PWA oder Store-App und ein klar umrissener erster Funktionsumfang. Danach liefern wir iterativ in kurzen Zyklen mit lauffähigen Zwischenständen auf einer Testumgebung, damit echte Nutzer früh testen können. Zum Abschluss übergeben wir Code, Zugänge und Dokumentation — Sie bleiben unabhängig, auch von uns.
Warum Innopulse
Wir sind eine Engineering- und Beratungsfirma in Zug, die eigene Produkte auf genau diesem Stack betreibt. Das heisst: Die Architektur, die wir Ihnen vorschlagen, ist keine Folie, sondern Alltag im eigenen Betrieb — inklusive Billing, Auth, Datenschutz und Suchmaschinen-Sichtbarkeit. Und weil wir native Apps nicht selbst verkaufen, ist unsere Empfehlung PWA oder Store-App nicht von einem Auslastungsinteresse geprägt.
Wenn Sie eine Anwendung planen und wissen wollen, welche Bauform passt, ist ein Erstgespräch der günstigste Schritt. Die ersten 30 Minuten kosten nichts, und danach wissen Sie, ob eine PWA reicht.