«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 vor allem Entwicklerzeit: 2–3 Entwickler über 8–14 Wochen für ein schlankes erstes Release, 3–4 Entwickler plus Delivery-Lead über 12–20 Wochen für ein Produkt mit mehreren Rollen, echten Integrationen und dem Reporting, mit dem ein Unternehmen arbeitet. Den Preis bestimmen Rollen, Integrationen und wie aktuell die Daten sein müssen.
Richtwerte für 2026, kein Angebot. Ihr Angebot kommt schriftlich und mit Festpreis innert drei Arbeitstagen nach dem kostenlosen 4-Stunden-Workshop; nur wenn der Umfang noch offen ist, steht ein bezahlter Discovery-Sprint davor, voll angerechnet. Schweizer und EU-Kunden erhalten es in Franken oder Euro von ihrer Ansprechperson.
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 sein Rate-Limit. 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 |
|---|---|---|
| Schlankes MVP — ein Kern-Ablauf, wo möglich mit bewährten Fertigbausteinen | 2–3 Entwickler | 8–14 Wochen |
| Standard-Produkt — mehrere Rollen, echte Integrationen, Admin und Reporting | 3–4 Entwickler + Delivery-Lead | 12–20 Wochen |
| Komplexe Plattform — Multi-Tenant, regulierte Daten, Migration parallel zum Livesystem | 5+ Entwickler, multidisziplinär | 20+ Wochen |
Richtwerte für 2026, kein Angebot. Den Preis bestimmt die Komplexität — Integrationen, Compliance, Datenmigration und die Zuverlässigkeit, die Sie ab Tag eins brauchen. Nach einem kostenlosen 4-Stunden-Workshop erhalten Sie innert drei Arbeitstagen einen schriftlichen Projektumfang und ein Angebot, bei klar umrissenem Umfang mit Festpreis. Ist der Umfang noch offen, kommt zuerst ein kurzer, bezahlter Discovery-Sprint, der vollständig auf die Umsetzung angerechnet wird, und danach der Festpreis.
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 folgt ein Supportplan, bemessen in Stunden pro 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 dauert vier Stunden und kostet nichts; innert drei Arbeitstagen danach haben Sie Umfang und Angebot schriftlich. Dann:
- Discovery-Sprint, 1–2 Wochen, wenn der Umfang noch offen ist. 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.
Was wir in jedem dieser Schritte von Ihnen brauchen, damit der Zeitplan hält, hat Minakshi aus Sicht der Delivery aufgeschrieben: Software entwickeln lassen: Ablauf und Kosten.
Zwei kommerzielle Punkte noch. Arbeitsergebnis und Quellcode gehören mit der Zahlung Ihnen. 100% der Rechte gehen über — kein Lock-in, keine Lizenzgebühren pro Nutzer. Und ein Festpreis ist der Normalfall, aber erst nach dem Workshop: 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 Firmen, die solche Kühlschränke für ihre Mitarbeitenden aufstellen, hatten keine eigene Oberfläche. Für jedes Anliegen (Zusatzbestellung für einen Teamanlass, Büro nächste Woche geschlossen, ab Montag mehr Leute im Haus, was sich an Standort B verkauft hat) musste man FeelEat schreiben. Intern gab es Dashboards. Die Partner hatten E-Mail.
Wir haben ein mandantenfähiges Portal gebaut: React im Frontend, Node.js mit NestJS dahinter. Darin gibt eine Partnerfirma Sonderbestellungen auf, trägt ihre Betriebsferien ein, meldet mehr oder weniger Mitarbeitende, erstellt Gutscheine für ihr Personal, bucht die Degustation von FeelEat und sieht die Verkäufe ihrer eigenen Kühlschränke. Ein Detail daraus, weil es für Web-Apps typisch ist: Die Mandantentrennung liegt zusätzlich in der Datenbank. Row-Level-Security in MySQL sorgt dafür, dass 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.
Seither erledigen die Partner all das selbst im Portal. 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 Nutzer, pro Mandant und nach Verbrauch bedeuten drei verschiedene Formen von Mandantenfähigkeit und drei verschiedene Arten 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.
