Web-App entwickeln lassen.

Die Trennlinie verläuft nicht bei Optik oder Budget, sondern bei der Frage, was Ihre Nutzenden tun: lesen, arbeiten oder das Gerät nutzen. Wer liest, braucht eine Website. Wer arbeitet, braucht eine Web-App. Wer Kamera, Sensoren, zuverlässige Push-Nachrichten oder Offline-Betrieb braucht, kommt an einer nativen App nicht vorbei.

Website. Inhalte werden ausgeliefert, für alle Besucher gleich. Es gibt kein Login, keine Rollen, keinen Zustand, der über den Besuch hinaus bestehen bleibt. Kontaktformular, Newsletter-Anmeldung und ein einfacher Terminlink ändern daran nichts. Das ist der Bereich, den wir unter Webdesign-Preise mit CHF 3'000 bis CHF 25'000 beschreiben.

Web-App. Sobald es ein Login gibt, unterschiedliche Rollen mit unterschiedlichen Sichten, eine eigene Datenbank und Abläufe über mehrere Schritte, sprechen wir von einer Web-App. Typische Fälle in Schweizer KMU: ein Kundenportal, in dem Aufträge, Dokumente und Rechnungen einsehbar sind; ein internes Werkzeug, das eine gewachsene Excel-Landschaft ablöst; ein Buchungs- oder Reservationssystem mit eigenen Regeln; eine Plattform, auf der zwei Nutzergruppen aufeinandertreffen.

Native App. Eine Anwendung, die aus dem App Store oder Play Store installiert wird und in der Sprache der jeweiligen Plattform geschrieben ist. Sie bedeutet zwei Entwicklungsstränge, zwei Freigabeprozesse und laufende Anpassungen an neue Betriebssystemversionen — ein Vielfaches an Aufwand gegenüber einer Web-App, das sich nur mit einem konkreten Grund rechtfertigen lässt.

Ein Beispiel aus unserer eigenen Arbeit macht die Grenze greifbar: Für einen Anbieter von Steuererklärungen im Raum Zürich haben wir ein System als Web-App gebaut — Paketwahl, Login, Dokument-Upload und Terminbuchung in einem Ablauf. Als Website wäre das nicht möglich gewesen, eine native App hätte keinen Mehrwert gebracht, weil die Nutzung einmal jährlich am Laptop stattfindet. Weitere Projekte finden Sie in unseren Referenzen.

Sie brauchen eine Web-App, sobald Menschen regelmässig Daten übertragen, die eigentlich das System übernehmen sollte. Das zeigt sich fast immer an denselben fünf Mustern, und alle fünf sind messbar — Sie müssen dafür keine Technologiefrage beantworten, sondern nur einen Arbeitstag beobachten.

• Ein Postfach ist das Betriebssystem. Aufträge, Statusfragen und Dokumente laufen über E-Mail, und niemand weiss ohne Suche, wo ein Fall gerade steht.
• Dieselbe Information wird mehrfach erfasst. Einmal im Formular, einmal in der Tabelle, einmal im Buchhaltungssystem. Jede Doppelerfassung ist eine Fehlerquelle und eine Stelle, an der Zahlen auseinanderlaufen.
• Kunden fragen nach Dingen, die sie selbst sehen könnten. «Wie weit ist mein Auftrag?», «Können Sie mir die Rechnung nochmals schicken?» — jede dieser Anfragen kostet Ihre Zeit und ist ein Argument für ein Portal.
• Es gibt Regeln, die im Kopf einer Person leben. Wer welchen Rabatt geben darf, wann eine Freigabe nötig ist, in welcher Reihenfolge etwas passieren muss. Solches Wissen gehört in ein System, nicht in eine Zuständigkeit.
• Wachstum erzeugt lineare Mehrarbeit. Doppelt so viele Aufträge bedeuten doppelt so viel Administration. Genau hier zahlt sich Software aus, sonst nirgends.

Wenn keines dieser Muster zutrifft, brauchen Sie keine Web-App, sondern eine bessere Website — und dabei sind Sie mit unseren Premium-Webseiten günstiger und schneller bedient. Liegt der Engpass dagegen zwischen Website und Verkaufsgespräch, ist manchmal ein Rechner oder Konfigurator die deutlich kleinere Lösung mit dem grösseren Effekt.

Wir bauen Web-Apps mit React und Next.js im Frontend, Node.js im Backend und PostgreSQL als Datenbank — nicht weil es die neueste Kombination ist, sondern weil sie verbreitet, dokumentiert und von vielen Fachleuten beherrscht wird. Bei einer Anwendung, die Sie zehn Jahre begleiten soll, ist die Verfügbarkeit von Menschen, die daran weiterarbeiten können, das wichtigste technische Kriterium.

Die Begründung im Einzelnen, damit Sie die Wahl prüfen und nicht glauben müssen. Next.js rendert Seiten serverseitig — das ist der Grund, warum die öffentlich zugänglichen Teile einer Web-App auch in Suchmaschinen und in KI-Antworten auftauchen, während reine Browser-Anwendungen dort unsichtbar bleiben. Was dahintersteckt, erklären wir im Glossar unter Next.js und Server-Side Rendering. PostgreSQL ist eine relationale Datenbank ohne Lizenzkosten, mit strengen Konsistenzregeln — bei Geschäftsdaten, wo eine falsch verbuchte Zahl echten Schaden anrichtet, ist das der richtige Kompromiss. Node.js erlaubt es, Frontend und Backend in derselben Sprache zu schreiben, was in kleinen Teams Übergaben und Fehlerquellen reduziert.

Was wir bewusst nicht tun: eine Web-App auf einem Content-Management-System aufbauen. WordPress und ähnliche Systeme sind hervorragend darin, Inhalte zu verwalten, und schlecht darin, Fachlogik, Rollenmodelle und Transaktionen abzubilden. Was mit ein paar Erweiterungen beginnt, endet nach zwei Jahren als System, dessen Aktualisierung niemand mehr wagt. Wo die Grenze zwischen Inhaltsverwaltung und Anwendung sinnvoll verläuft, beschreiben wir im Beitrag Headless CMS gegen WordPress.

Eine Zwischenstufe verdient eine eigene Erwähnung: die Progressive Web App. Sie ist technisch eine Web-App, lässt sich aber auf dem Startbildschirm ablegen, startet ohne Browserleiste und kann in Grenzen offline arbeiten. Für viele Vorhaben, die zunächst nach einer nativen App klingen, ist das die passende Antwort — mit einer wichtigen Einschränkung, die im nächsten Abschnitt steht.

Eine native App lohnt sich, wenn Push-Nachrichten, Offline-Betrieb, Gerätefunktionen oder die Präsenz im App Store zum Kern Ihres Angebots gehören — in allen anderen Fällen kaufen Sie doppelten Aufwand ohne Gegenwert. Diese vier Gründe sind belastbar, alle anderen halten der Prüfung selten stand.

• Push-Nachrichten als zentraler Kanal. Der wichtigste Punkt und der am häufigsten übersehene: Auf dem iPhone funktioniert Web-Push nur, wenn die Anwendung zuvor über das Teilen-Menü von Safari auf den Startbildschirm gelegt und die Erlaubnis erteilt wurde. Es gibt dort keine automatische Installationsaufforderung; Sie müssen die Nutzenden anleiten. Wer diesen Schritt nicht macht, ist über Push nicht erreichbar. Bei einer nativen App ist der Kanal ab Installation zuverlässig da.
• Echter Offline-Betrieb. Eine Progressive Web App kann Inhalte zwischenspeichern, aber ein Aussendienst, der stundenlang ohne Empfang Daten erfasst und später abgleicht, ist mit einer nativen App verlässlicher bedient.
• Tiefer Gerätezugriff. Bluetooth-Geräte, Hintergrundortung, biometrische Entsperrung, kontinuierlicher Sensorzugriff: Hier stösst der Browser an Grenzen, die je nach Plattform unterschiedlich verlaufen.
• Der App Store ist Ihr Vertriebsweg. Wenn Ihre Kundschaft Ihr Angebot dort sucht oder Sie über die Store-Abrechnung verkaufen wollen, ist die Frage entschieden.

Gegen die native App sprechen die Folgekosten, die in der ersten Offerte selten stehen: zwei Plattformen, zwei Freigabeprozesse mit Wartezeiten, laufende Anpassungen an neue Betriebssystemversionen und Nutzende, die Aktualisierungen nicht installieren, sodass Sie alte Versionen jahrelang mitpflegen. Eine Web-App aktualisieren Sie einmal, und beim nächsten Aufruf arbeiten alle mit derselben Fassung.

Unser üblicher Rat: mit einer Web-App starten, die auf Mobilgeräten sauber bedienbar und als Progressive Web App installierbar ist. Wenn sich die Nutzung etabliert hat und einer der vier Gründe belegbar zutrifft, folgt die native App auf einem bereits erprobten Datenmodell — statt vor einer ungeprüften Annahme.

Den Aufwand treiben Rollen, Schnittstellen und Sonderfälle — nicht die Anzahl der Bildschirme und schon gar nicht die Gestaltung. Das ist die häufigste Fehleinschätzung in Erstgesprächen: Zwei Anwendungen mit derselben Anzahl Seiten können sich im Aufwand um den Faktor fünf unterscheiden.

Rollen und Berechtigungen. Eine Anwendung, in der alle dasselbe sehen, ist ein Bruchteil der Arbeit gegenüber einer mit Rollenmodell, Freigabestufen, Vertretungsregelungen und einer Nachvollziehbarkeit, wer wann welchen Wert geändert hat. Jede zusätzliche Rolle vervielfacht die Fälle, die gebaut und geprüft werden müssen.

Schnittstellen. Jede Verbindung zu einem Bestandssystem — ERP, Buchhaltung, Lager, Kasse, Zahlungsanbieter — ist ein eigenes kleines Projekt mit fremder Dokumentation, fremden Fehlermeldungen und fremden Wartungsfenstern. Bei zwei Systemen kommt die Frage dazu, welches im Konfliktfall recht hat.

Sonderfälle und Zustände. Der Hauptablauf ist schnell gebaut. Teilstornierungen, Rückerstattungen, Verlängerungen, gleichzeitige Bearbeitung durch zwei Personen und der Satz «das machen wir dann von Hand» kosten den grösseren Teil des Budgets.

Datenübernahme. Altdaten sind selten so sauber, wie sie in der Besprechung wirken. Bereinigung, Zuordnung und mehrere Testläufe brauchen regelmässig mehr Zeit, als eingeplant wird.

Rechtliche Anforderungen. Personendaten, Protokollierung, Aufbewahrungsfristen, Löschkonzept und ein Verzeichnis der Dienstleister nach revidiertem Datenschutzgesetz erzeugen Aufwand, der auf keinem Bildschirm sichtbar ist. Wer ihn erst nach dem Start einplant, zahlt ihn doppelt.

Was den Aufwand dagegen kaum treibt: die Anzahl der Nutzenden. Eine sauber gebaute Web-App für 20 Personen unterscheidet sich technisch wenig von einer für 2'000. Erst weit darüber und bei Echtzeit-Anforderungen wird Skalierung zu einem eigenen Thema — dann sprechen wir über komplexe Weblösungen.

Ein Prototyp kostet einen Bruchteil des Vollprojekts und beantwortet die teuerste Frage zuerst: ob das, was Sie sich vorstellen, im Alltag tatsächlich funktioniert. Wir empfehlen ihn auch dann, wenn ein Vollauftrag bereits auf dem Tisch liegt — der kurzfristig kleinere Auftrag führt erfahrungsgemäss zum besseren Projekt.

Der Grund liegt in der Natur von Softwareprojekten: Der grösste Kostentreiber ist nicht schlechte Programmierung, sondern gebaute Funktionalität, die später niemand benutzt. Ein Prototyp mit bedienbaren Bildschirmen, aber ohne vollständige Fachlogik dahinter, deckt Missverständnisse in Wochen auf statt in Monaten. Er zeigt, ob der gedachte Ablauf mit dem gelebten übereinstimmt, ob die Reihenfolge stimmt und welche Felder fehlen — und all das an etwas, das man anfassen kann, nicht in einem Konzeptdokument.

Bei uns beginnt ein Prototyp zur Ideenvalidierung bei CHF 10'000 und ist ein echter Ausstiegspunkt: Sie können danach mit uns weiterbauen, mit dem Ergebnis zu einem anderen Anbieter gehen oder das Vorhaben begraben — Letzteres ist der wertvollste Ausgang, wenn die Idee nicht trägt. Der ausführliche Hintergrund dazu steht in unserem Beitrag MVP-Entwicklung schnell und günstig.

Erst nach dem Prototyp lässt sich seriös offerieren. Wer vorher eine Festpreis-Zahl für ein umfangreiches System nennt, hat entweder grosszügig aufgerundet oder wird im dritten Monat nachverhandeln. Beides ist teurer als die zwei bis vier Wochen, die eine geprüfte Grundlage kostet.

Wir arbeiten in vier Etappen mit einem Ausstiegspunkt nach jeder: Anforderungsaufnahme, Prototyp, erste produktive Version, Ausbau in Zyklen. Nach jeder Etappe haben Sie ein Ergebnis in der Hand, das auch ohne die nächste Etappe einen Wert hat — das ist der Kern, alles andere ist Ausgestaltung.

In der Anforderungsaufnahme sprechen wir mit den Menschen, die später täglich damit arbeiten, nicht nur mit der Geschäftsleitung. Ergebnis ist eine geordnete Liste der Abläufe, ein grobes Datenmodell und eine ehrliche Trennung zwischen «muss zum Start da sein» und «kann später kommen». Der Prototyp macht das bedienbar. Die erste produktive Version enthält Login und Rollen, das Datenmodell, den Hauptablauf und eine Schnittstelle — mehr nicht, damit sie schnell im Einsatz ist. Der Ausbau folgt in zwei- bis dreiwöchigen Zyklen mit fester Kapazität, priorisiert nach dem, was der echte Betrieb zeigt.

Zwei Punkte regeln wir vor Vertragsbeginn schriftlich, weil sie später über Ihre Handlungsfreiheit entscheiden. Erstens die Rechte am eigens erstellten Quellcode, inklusive Bearbeitungsrecht — in der Schweiz gehen diese Rechte im Auftragsverhältnis nämlich nicht automatisch an den Auftraggeber über. Zweitens die Zugänge: Code-Repository, Datenbank, Hosting und Domain laufen auf Ihre Konten, wir arbeiten als eingeladene Mitglieder darauf. Beides ausführlich erklärt finden Sie auf unserer Seite zu Individualsoftware in der Schweiz.

Nach dem Start folgt der Betrieb: Überwachung, Backups mit geprüfter Wiederherstellung, Sicherheits- und Bibliotheks-Updates, Fehlerkorrekturen. Wir rechnen das nach Aufwand oder über ein monatliches Kontingent ab, das Sie frei zwischen Pflege und Weiterentwicklung aufteilen.

In vier Konstellationen raten wir von einer Web-App ab — und zwar bevor eine Offerte geschrieben wird, nicht danach. Ein Projekt, das aus den falschen Gründen startet, kostet beide Seiten mehr als ein abgesagtes Erstgespräch.

• Es existiert eine passende Standardlösung. Für Terminbuchung, Rechnungsstellung, Zeiterfassung, Projektverwaltung oder einen gewöhnlichen Onlineshop gibt es ausgereifte Produkte für wenige Franken pro Person und Monat. Wer das nachbaut, zahlt ein Vielfaches für weniger Funktionsumfang. Die Abwägung im Detail steht auf unserer Seite zu Individualsoftware.
• Der Prozess ist intern nicht geklärt. Wenn zwei Abteilungen unterschiedlich beschreiben, wie ein Vorgang durchs Haus läuft, entscheidet die Software diese Frage stillschweigend — und meist falsch. Erst klären, dann bauen.
• Niemand ist auf Ihrer Seite verantwortlich. Eine Web-App braucht eine Person mit Entscheidungsbefugnis und tatsächlich verfügbarer Zeit. Fehlt sie, versandet das Projekt zwischen den Zyklen, unabhängig von der Qualität der Entwicklung.
• Das Budget deckt nur die Entwicklung. Eine Anwendung ohne Mittel für Betrieb und Pflege ist nach zwei Jahren ein Sicherheitsrisiko und nach drei Jahren nicht mehr veränderbar. Dann ist ein Abo die vernünftigere Entscheidung.

Und eine Selbsteinschätzung, die dazugehört: Wir sind eine kleine Digitalagentur mit eigenem Entwicklungsteam. Unsere Stärke liegt bei Anwendungen mit klarem Zuschnitt — Kundenportalen, internen Werkzeugen, Buchungs- und Konfigurationssystemen, Plattformen für zwei Nutzergruppen. Bei Vorhaben, die ein Team von zwanzig Personen über zwei Jahre binden, zertifizierte Branchenstandards erfordern oder tief in ein bestehendes ERP eingreifen, sind wir nicht der richtige Partner. Das sagen wir im Erstgespräch, nicht im vierten Monat.