«Wir brauchen eigentlich nur ein Dashboard.» So fängt fast jedes Gespräch an, in dem jemand eine Web-App programmieren lassen will. Der Satz ist fast immer falsch, und nicht aus Naivität: das Dashboard ist der einzige Teil, den man sehen kann. Darunter liegen Anmeldung, Rollen, Rechte, Mandanten, Abrechnung und die Frage, wer welche Zeile überhaupt sehen darf.
Bezahlt wird vor allem dieser unsichtbare Teil.
Web-App programmieren lassen: die kurze Antwort
Eine Web-App programmieren lassen kostet bei uns $30,000–55,000 für ein schlankes erstes Release in 8–14 Wochen und $55,000–110,000 für ein Produkt mit mehreren Rollen, echten Integrationen und dem Reporting, mit dem ein Unternehmen arbeitet, in 12–20 Wochen. Was die Zahl bewegt, sind Rollen, Integrationen und wie live die Daten sein müssen.
Indikatives Band, kein Angebot — die fixe Zahl kommt aus einem bezahlten Discovery-Sprint und wird auf die Umsetzung angerechnet. Die Zahlen hier sind in US-Dollar; Schweizer und EU-Kunden werden aus der Franken- und der Euro-Ausgabe derselben Preisliste 2026 bepreist, die Sie von Ihrer Ansprechperson erhalten.
Website oder Web-App? Diese Grenze entscheidet über den Preis
Eine Website zeigt Inhalte. Eine Web-App hält Zustand: Sie melden sich an, ändern etwas, und beim nächsten Aufruf ist die Änderung noch da, für Sie und für die richtigen Kollegen. Wer die richtigen Kollegen sind, ist das Berechtigungsmodell. Darin verbringe ich bei CODT Technologies die meiste Zeit, und in keiner Demo ist es zu sehen.
Wer eine Web-App entwickeln lassen will, sollte diese vier Treiber kennen; Design gehört nicht dazu:
- Rollen. Zwei Rollen sind eine Fallunterscheidung. Sechs Rollen mit Ausnahmen sind ein Berechtigungsmodell, das getestet werden muss, weil ein Fehler darin einem Kunden die Daten eines anderen zeigt.
- Integrationen. Jedes Fremdsystem bringt seine eigene Authentifizierung mit, seine Ausfälle und seine Grenze pro Minute. Die Integration ist selten schwierig. Der Umgang mit ihren schlechten Tagen ist es.
- Echtzeit. «Live» kostet ein Vielfaches von «beim Neuladen aktuell», und es sind laufende Kosten, die nie wieder verschwinden.
- Regulierte Daten. Gesundheits-, Zahlungs- oder Personaldaten bringen Audit-Protokollierung, Aufbewahrungsfristen und ein Löschkonzept mit. Im Klickprototyp tauchen sie nie auf.
Wenn Ihr Vorhaben im Kern ein Formular ist, das drei Leute pro Woche ausfüllen, und eine Tabelle dahinter, dann nehmen Sie ein No-Code-Werkzeug und behalten Sie Ihr Geld. Geben Sie es nicht uns. Für so einen Fall ist ein Eigenbau die teuerste Variante, die es gibt. Wann sich Bauen gegen Kaufen rechnet, steht hier ausführlich.
Was kostet eine Web-App?
| Projektform | Team | Dauer | Indikatives Band |
|---|---|---|---|
| Schlankes MVP — ein Kern-Ablauf, wo möglich mit bewährten Fertigbausteinen | 2–3 Entwickler | 8–14 Wochen | $30,000–55,000 |
| Standard-Produkt — mehrere Rollen, echte Integrationen, Admin und Reporting | 3–4 Entwickler + Delivery-Lead | 12–20 Wochen | $55,000–110,000 |
| Komplexe Plattform — Multi-Tenant, regulierte Daten, Migration parallel zum Livesystem | 5+ Entwickler, multidisziplinär | 20+ Wochen | $120,000–250,000+ |
Indikative Bänder für 2026, kein Angebot. Was die Zahl bewegt, ist Komplexität — Integrationen, Compliance, Datenmigration und die Zuverlässigkeit, die Sie ab Tag eins brauchen. Jedes Projekt wird nach einem bezahlten Discovery-Sprint fix und schriftlich bepreist, und der Sprint wird vollständig auf die Umsetzung angerechnet.
Dazu der Betrieb, den das erste Budget fast immer vergisst. Der jährliche Support liegt typischerweise bei 15–20% der ursprünglichen Umsetzungskosten. Bei uns sind die ersten 30 Tage nach dem Launch Gewährleistung, danach beginnt ein Supportplan bei $550 im Monat. Unser Kostenrechner rechnet Ihren Zuschnitt in zwei Minuten durch; soll die Web-App im Abo verkauft werden, ist der Leitfaden zu SaaS-Kosten die genauere Adresse. Für native Apps gilt eine andere Rechnung, die wir dort aufgeschrieben haben.
Der Ablauf, Schritt für Schritt
Der erste Workshop und eine grobe Einschätzung sind kostenlos — in der Regel innerhalb von drei Arbeitstagen. Danach:
- Discovery-Sprint, 1–2 Wochen, $2,900–4,900. Ergebnis: ein schriftlicher Umfang, eine Systemarchitektur, eine kalkulierte Roadmap und eine ausdrückliche «Bauen wir nicht»-Liste — Ihr Eigentum, und das Dokument, aus dem das Festangebot geschrieben wird. Der Sprint wird vollständig auf die Umsetzung angerechnet.
- Fundament. Mandanten, Anmeldung, Rollen, Deployment-Pipeline, Staging. Für den Auftraggeber ist das die langweiligste Phase, weil kaum etwas zu sehen ist. Sie entscheidet trotzdem über die nächsten Jahre.
- Kern-Abläufe. Alle zwei Wochen ein lauffähiger Stand auf Staging, an dem Ihre Leute wirklich arbeiten können.
- Härten. Lasttests, Berechtigungstests, Fehlerfälle, Wiederherstellung aus dem Backup. Diese Phase wird als erste gekürzt, wenn ein Termin rutscht.
- Go-live, dann 30 Tage Gewährleistung.
Zwei kommerzielle Punkte noch. Arbeitsergebnis und Quellcode gehören mit der Zahlung Ihnen. 100% der Rechte gehen über — kein Lock-in, keine Lizenz pro Sitzplatz. Und ein Festpreis ist möglich, aber nur nach dem bezahlten Discovery-Sprint: ein Festpreis auf eine Anfrage-E-Mail ist geraten und nicht gerechnet, egal wer ihn unterschreibt.
Ein Partnerportal, an dem man das nachrechnen kann
FeelEat betreibt in der Schweiz vernetzte Kühlschränke und beliefert sie aus der eigenen Küche. Die B2B-Partner, die solche Flotten betreiben, hatten keine eigene Sicht auf ihre Daten. Jede Frage (warum ist dieser Kühlschrank leer, was verkauft sich an Standort B, wann muss ich nachfüllen) war ein Anruf beim Support. Intern gab es Dashboards. Die Partner hatten E-Mail.
Wir haben ein mandantenfähiges Portal gebaut: React im Frontend, Node.js mit NestJS dahinter, Bestände pro Kühlschrank in Echtzeit, Bedarfsprognose, Umsatzauswertung pro Kühlschrank und Produkt. Zwei Details daraus, weil sie für Web-Apps typisch sind. Hunderte Kühlschränke pro Partner, die alle 30 Sekunden abfragen, hätten die API erledigt; also kam eine Redis-Leseschicht davor, und per WebSocket gehen nur die aktiv beobachteten Kühlschränke. Die Mandantentrennung liegt zusätzlich in der Datenbank: Row-Level-Security in MySQL, damit selbst eine Abfrage ohne WHERE-Klausel keine Zeilen eines anderen Partners zurückgibt. Plattform-Fundamente sind meine Arbeit bei CODT Technologies, und diese doppelte Trennung ist das Einzige, was ich nicht gegen Liefergeschwindigkeit tausche.
Die erste Version der Bedarfsprognose war schlechter als die erfahrenen Disponenten. Erst mit Saisonalität, Wochentag und Bedarfssignalen pro Standort kam sie auf 94% Nachschub-Genauigkeit.
Messbar danach: Supportanrufe −68%, rund 320 abgefangene Anrufe pro Monat, über 180 täglich aktive Partner-Nutzer, NPS von +38 auf +71. Die ganze Fallstudie steht hier.
Drei Entscheidungen, die in Woche eins fallen
- Mandantenfähigkeit. «Machen wir später» sind hier die teuersten drei Worte des Projekts, weil die Annahme «es gibt genau eine Organisation» in Abfragen, Caches, Hintergrundjobs und Dateipfade wandert. Warum das später ein Neubau und kein Refactoring ist.
- Identität und Rollen. Eigene Nutzerverwaltung oder der Firmen-Login Ihrer Kunden. Das Zweite später nachzuziehen ist machbar, aber es berührt jede Berechtigungsprüfung, die Sie bis dahin geschrieben haben.
- Abrechnung. Wenn Geld den Besitzer wechselt, gehört das Modell vor die erste Zeile Code. Pro Sitzplatz, pro Mandant und nach Verbrauch bedeuten drei verschiedene Formen von Mandantenfähigkeit und drei verschiedene Sätze von Berechtigungsprüfungen; eines nachträglich auf das andere zu legen heisst, sie alle wieder aufzumachen.
Wie wir anfangen
Sie beschreiben, wer mit der Web-App arbeiten soll und was diese Leute heute stattdessen tun. Im ersten Gespräch sagen wir Ihnen, welchen Teil davon Sie besser kaufen als bauen. Vor jedem technischen Gespräch steht ein NDA. Ein Auftragsverarbeitungsvertrag und Standardvertragsklauseln werden standardmässig unterzeichnet. Wie wir solche Anwendungen bauen, steht auf unserer Seite zur Web-App-Entwicklung.
