happycoding – Webapp-Entwicklung

1. NextJS als Fundament: schnell, flexibel, bewährt

NextJS ist das Framework, das wir für die meisten unserer Kundenprojekte einsetzen – nicht weil es gerade modern ist, sondern weil es die richtigen Eigenschaften für langlebige Anwendungen mitbringt. Serverseitiges Rendering, saubere API-Architektur, modulare Komponentenstruktur. Das Ergebnis sind Anwendungen, die schnell laden, gut skalieren und sich von verschiedenen Teams weiterentwickeln lassen.

2. Supabase als Datenschicht: PostgreSQL ohne Overhead

Supabase liefert eine vollständige Backend-Infrastruktur auf Basis von PostgreSQL – Datenbankzugriff, Authentifizierung, Echtzeit-Funktionen, Datei-Storage. Was früher Wochen in der Konfiguration bedeutete, lässt sich damit in Tagen produktionsreif aufsetzen. Und weil Supabase Open Source ist und sich selbst hosten lässt, bleibt die volle Kontrolle beim Betreiber.

3. Keycloak für Identität und Zugriff: Enterprise-Standard, kein Aufpreis

Authentifizierung ist der Teil einer Webanwendung, bei dem Fehler am teuersten sind. Keycloak ist der De-facto-Standard für Identity & Access Management im Open-Source-Bereich, wird von Red Hat aktiv weiterentwickelt und bietet alles, was komplexe Benutzer- und Rechteverwaltung erfordert: SSO, MFA, Rollenmanagement, LDAP-Anbindung. Die Lizenz kostet nichts. Die Einrichtung erfordert Erfahrung – die wir mitbringen.

4. Self-Hosting wo sinnvoll, Managed Services wo praktisch

Wir betreiben unsere Projekte bevorzugt auf eigener Infrastruktur – bei Hetzner in Deutschland, über unsere eigene Deployment-Plattform. Das senkt laufende Kosten und stärkt die Datensouveränität. Für Projekte, bei denen der Betriebsaufwand geringer priorisiert wird, setzen wir auf Supabase Cloud und vergleichbare Managed-Angebote. Beides ist möglich, beides hat seinen Platz.

5. Offene Architektur statt proprietärer Systeme

Wir bauen keine Anwendungen, die nur mit einem bestimmten Anbieter oder einem bestimmten Team funktionieren. Unsere Projekte folgen klaren Architekturprinzipien, sind dokumentiert und so aufgebaut, dass andere Entwickler sie weiterführen können. Das ist kein Selbstverständnis – das ist eine bewusste Entscheidung.

6. Erfahrung aus realen Projekten

Wir haben Webapps für interne Verwaltungsprozesse, Kundenportale, API-getriebene Plattformen und SaaS-Produkte gebaut – für Startups, Mittelständler und Unternehmen, die mit etablierten Agenturen zusammenarbeiten. Diese Erfahrung fließt in jede technische Entscheidung ein.

Make or Buy: Eine Entscheidung, die sich neu stellt

Lange galt die Faustregel: Standardsoftware kaufen, was geht – und nur dann selbst entwickeln, wenn es wirklich keinen Markt für die eigene Anforderung gibt. Diese Regel hatte ihre Logik. Individualsoftware war teuer, langsam und riskant. Für viele Anwendungsfälle stimmte das.

Diese Logik gilt heute nur noch eingeschränkt.

KI-gestützte Entwicklung verändert die Kalkulation grundlegend

Der Aufwand für Individualsoftware ist in den letzten Jahren erheblich gesunken. Nicht weil Entwickler billiger geworden wären, sondern weil sie produktiver arbeiten als je zuvor. KI-gestützte Entwicklungswerkzeuge – von Code-Assistenten bis zu vollständigen Entwicklungsumgebungen, die auf natürlichsprachliche Anforderungen reagieren – haben die Entwicklungsgeschwindigkeit in vielen Bereichen verdoppelt oder verdreifacht.

Was das konkret bedeutet: Anwendungsfälle, die vor drei Jahren noch einen sechsstelligen Entwicklungsaufwand bedeutet hätten, lassen sich heute in einem Bruchteil der Zeit umsetzen. Die Schwelle, ab der eine Individualentwicklung wirtschaftlich Sinn ergibt, hat sich deutlich nach unten verschoben.

Das bedeutet nicht, dass jede Standardsoftware durch eine Eigenentwicklung ersetzt werden sollte. Es bedeutet, dass die Rechnung neu aufgemacht werden muss – ehrlich, ohne die alten Annahmen einfach fortzuschreiben.

Was Standardsoftware kostet, wird oft unterschätzt

Der Listenpreis einer SaaS-Lösung ist selten das, was sie am Ende kostet. Hinzu kommen Anpassungen für den eigenen Prozess, Schulungen, Integrationsaufwände mit bestehenden Systemen, Lizenzerhöhungen bei wachsender Nutzerzahl und – nicht zu unterschätzen – die kontinuierliche Reibung, die entsteht, wenn ein Werkzeug nicht genau das tut, was ein Team braucht. Viele Unternehmen zahlen für Software, die zu 60 Prozent passt, und kompensieren die restlichen 40 Prozent mit manuellen Workarounds. Diese Workarounds erscheinen in keiner Kostenaufstellung, kosten aber täglich Arbeitszeit.

Was Individualentwicklung heute leisten kann

Eine maßgeschneiderte Webanwendung bildet genau den Prozess ab, den Ihr Unternehmen tatsächlich hat – nicht einen generischen Prozess, den ein Softwareanbieter für eine möglichst breite Zielgruppe entworfen hat. Das klingt selbstverständlich, ist es in der Praxis aber selten. Wer einmal erlebt hat, wie ein Team aufhört, Tabellenkalkulationen als Datenbankersatz zu verwenden, weil es endlich eine Anwendung gibt, die ihren Ablauf versteht, kennt den Unterschied.

Mit modernen Entwicklungsstacks und KI-gestützter Entwicklung ist dieser Zustand heute schneller und zu geringeren Kosten erreichbar als noch vor wenigen Jahren. Das ist der entscheidende Wandel.

DSGVO und digitale Souveränität: Kein Beiwerk, sondern Architekturentscheidung

Datenschutz wird in vielen Projekten als Checkliste behandelt: Am Ende wird geprüft, ob die nötigen Einwilligungen eingeholt werden und ob ein Datenschutzbeauftragter das Konzept abgenickt hat. Das greift zu kurz.

Die eigentliche Frage: Wo liegen Ihre Daten?

Wer eine Webanwendung auf Basis von US-amerikanischen Cloud-Diensten betreibt, hat ein grundsätzliches Problem – unabhängig davon, wie sorgfältig die Datenschutzerklärung formuliert ist. Der Cloud Act verpflichtet US-Anbieter unter bestimmten Umständen zur Herausgabe von Daten an US-Behörden, auch wenn die Daten auf europäischen Servern liegen. Das ist kein theoretisches Risiko, sondern eine strukturelle Schwäche, auf die Datenschutzbehörden in Deutschland und der EU seit Jahren hinweisen.

Die saubere Lösung ist keine komplizierte: Infrastruktur in Deutschland, betrieben von Anbietern, die dem deutschen und europäischen Recht unterliegen. Wir setzen dafür auf Hetzner – ein deutsches Unternehmen mit Rechenzentren in Deutschland und Finnland. Kein Umweg über Irland, kein Privacy-Shield-Nachfolger, der beim nächsten EuGH-Urteil wieder in Frage steht.

Datenminimierung und Zugriffskontrolle als Designprinzip

DSGVO-konformes Bauen bedeutet nicht nur, keine Daten zu speichern, die nicht gebraucht werden. Es bedeutet auch, dass Zugriff auf Daten technisch so geregelt ist, dass nur die Personen Zugang haben, die ihn tatsächlich benötigen. Mit Keycloak lässt sich das auf eine Weise umsetzen, die in proprietären Standardlösungen selten so präzise möglich ist: Rollen, Berechtigungen und Zugriffsregeln werden explizit modelliert, nachvollziehbar dokumentiert und technisch durchgesetzt – nicht als Konfigurationsoption, sondern als Kernelement der Architektur.

Digitale Souveränität als strategisches Argument

Unabhängigkeit von einzelnen Technologieanbietern ist nicht nur ein Datenschutzthema. Es ist eine strategische Frage: Was passiert, wenn ein Anbieter seine Preise erhöht, sein Produkt einstellt oder von einem Wettbewerber übernommen wird? Wer seine Kernanwendungen auf Open-Source-Technologien aufbaut und die Infrastruktur kontrolliert, hat eine Antwort auf diese Frage. Wer es nicht tut, vertraut darauf, dass externe Anbieter keine Entscheidungen treffen, die das eigene Geschäft belasten.

Diese Abhängigkeit wächst mit der Zeit still – und fällt oft erst auf, wenn ein Anbieterwechsel notwendig wird und der Aufwand dafür viel größer ist als erwartet.

Prozessindividualisierung: Warum der Unterschied entscheidend ist

Kein Unternehmen funktioniert so, wie es ein Softwarehersteller auf einer Produktmesse beschreibt. Die Art, wie Aufträge erfasst werden, wie Informationen zwischen Abteilungen fließen, wie Kunden betreut werden oder wie interne Freigaben organisiert sind – das ist in jedem Unternehmen anders. Manchmal nur in Details, manchmal grundlegend.

Standardsoftware löst dieses Problem auf zwei Weisen: entweder durch breite Konfigurierbarkeit, die zu einem komplexen System führt, das kaum jemand vollständig versteht – oder durch die implizite Erwartung, dass das Unternehmen seinen Prozess an die Software anpasst. Beides hat seinen Preis.

Was maßgeschneiderte Anwendungen anders machen

Eine individuell entwickelte Webanwendung bildet den tatsächlichen Prozess ab – nicht einen idealisierten Prozess, nicht den Prozess eines anonymen Durchschnittskunden, sondern den Prozess, der in Ihrem Unternehmen real existiert. Das beginnt bei der Terminologie: Ein Werkzeug, das dieselben Begriffe verwendet wie Ihr Team, wird schneller akzeptiert und seltener umgangen. Es setzt sich fort in der Logik: Genehmigungsschritte, Statusübergänge, Ausnahmeregeln – all das lässt sich exakt so umsetzen, wie es gebraucht wird.

Das klingt nach einem Nice-to-have. In der Praxis ist es oft der Unterschied zwischen einer Anwendung, die das Team täglich nutzt, und einer, die nach sechs Monaten stillschweigend durch eine Excel-Tabelle ersetzt wurde.

Prozessindividualisierung zahlt sich über Zeit aus

Eine maßgeschneiderte Anwendung wird mit dem Unternehmen weiterentwickelt. Wenn sich Prozesse ändern – durch Wachstum, durch neue Regularien, durch veränderte Kundenanforderungen –, kann die Anwendung angepasst werden. Bei Standardsoftware ist man auf den Entwicklungsrhythmus des Anbieters angewiesen. Features kommen, wenn der Anbieter sie priorisiert. Workarounds entstehen, wenn sie nicht kommen.

Die Frage ist letztlich: Wer kontrolliert die Weiterentwicklung des Werkzeugs, auf das sich Ihr Unternehmen täglich verlässt?

Was kostet das wirklich?

Lizenzkosten

Beide Tools sind Open Source. Die Lizenzkosten betragen null.

Infrastruktur

Für eine Anwendung mit einigen Hundert bis einigen Tausend aktiven Nutzern genügt zu Beginn ein Server mit 4–8 GB RAM. Bei Hetzner – für DSGVO-konforme Deployments in Deutschland eine naheliegende Wahl – sind das etwa 20–50 Euro pro Monat. Wer Hochverfügbarkeit mit redundanten Instanzen und separater Datenbankschicht benötigt, rechnet realistisch mit 150–400 Euro monatlich, abhängig vom Lastprofil.

Implementierung

Das ist der Kostenblock, der am häufigsten unterschätzt wird. Eine saubere Erstimplementierung – Keycloak-Setup, Supabase-Integration, Sicherheitskonfiguration, Testing – liegt je nach Projektumfang erfahrungsgemäß zwischen 5.000 und 20.000 Euro Entwicklungsaufwand. Das ist eine Einmalinvestition.

Wer diesen Aufwand umgehen will und stattdessen auf Managed Services setzt, zahlt dauerhaft. Bei einem mittelgroßen Projekt summiert sich das über drei bis fünf Jahre auf ein Vielfaches.

Betrieb

Bei vernünftiger Automatisierung und stabiler Architektur rechne ich mit 2–5 Stunden monatlichem Wartungsaufwand für Updates, Monitoring und Backups. Das ist planbar – im Gegensatz zu den variablen Kosten nutzungsbasierter Dienste.

Gesamtbild über drei Jahre

Eine typische mittelständische Webanwendung mit diesem Stack kostet über drei Jahre – inklusive Infrastruktur, Implementierung und Wartung – in der Regel zwischen 40.000 und 80.000 Euro, je nach Komplexität. Ein vergleichbares Setup mit proprietären Managed-Services kommt im selben Zeitraum erfahrungsgemäß auf das Doppelte, häufig mehr. Und das ohne die Flexibilität und Datenkontrolle, die dieser Stack mitbringt.

Der wesentliche Unterschied: Die Kosten dieses Stacks sinken über die Zeit. Die Kosten von Managed Services steigen mit dem Projekterfolg.