Individuelle Webanwendung entwickeln lassen

Du willst eine individuelle Webanwendung entwickeln lassen. Gute Entscheidung, wenn Standardsoftware nicht passt. Schlechte Entscheidung, wenn du eigentlich nur eine Datenbank mit ein paar Formularen brauchst.

Der Unterschied zwischen beiden Welten ist die häufigste Quelle für gescheiterte Projekte. Deshalb lohnt es sich, vor dem ersten Entwicklergespräch ein paar Dinge zu klären: Was genau soll die Anwendung tun, wer nutzt sie, und welche bestehenden Lösungen reichen nicht aus.

Wann sich Custom-Entwicklung wirklich lohnt

Eine individuelle Webanwendung ist sinnvoll, wenn deine Anforderungen so spezifisch sind, dass jede Standardlösung mehr Reibung erzeugt als sie Probleme löst. Das ist seltener der Fall, als viele denken.

Der ehrliche Test geht so: Notiere die fünf wichtigsten Funktionen, die deine Anwendung können muss. Wenn vier davon mit Notion, Airtable oder einem branchenüblichen SaaS-Tool abbildbar sind, brauchst du keine Custom-Entwicklung. Nur die eine Sonderfunktion könnte das Geld nicht wert sein.

Custom lohnt sich dann, wenn die Anwendung selbst der Wettbewerbsvorteil ist. Wenn ein interner Prozess so eigen ist, dass kein Tool ihn sauber abbildet. Wenn die Datenmenge oder Performance-Anforderungen über das hinausgehen, was Baukästen leisten. Oder wenn du ein eigenes Produkt verkaufen willst und nicht von der Roadmap eines Drittanbieters abhängig sein darfst.

Eine kurze Abgrenzung zu No-Code-Tools: Plattformen wie Bubble, Glide oder Softr sind beeindruckend leistungsfähig für Prototypen und kleinere Produkte. Sie skalieren technisch und kostenseitig aber irgendwann unangenehm. Wer 200 Nutzer hat, zahlt vielleicht 49 Euro im Monat. Bei 5.000 Nutzern wird die monatliche Rechnung schnell vierstellig, und ein Wechsel auf eigene Infrastruktur ist meist ein Komplett-Neubau. Mehr Hintergrund zum Einstieg findest du auch im Leitfaden zum Software-Nebenprojekt starten.

Anforderungsanalyse: die Phase, an der die meisten sparen

Die Anforderungsanalyse entscheidet über Erfolg und Budget eines Projekts mehr als jede Technologiewahl. Wer hier 2 Tage investiert, spart oft 2 Wochen Umsetzung.

Eine saubere Analyse beantwortet drei Fragen. Erstens: Welches Problem löst die Anwendung konkret, und wie messen wir, dass es gelöst ist. Zweitens: Wer sind die Nutzer, in welchem Kontext arbeiten sie, welche Geräte nutzen sie. Drittens: Welche Daten fließen rein, welche raus, und mit welchen anderen Systemen muss die Anwendung sprechen.

Bewährt haben sich dafür User-Storys, einfache Wireframes und eine Liste der externen Schnittstellen. Keine 80-seitigen Pflichtenhefte, die niemand liest. Aber genug Schriftliches, damit beide Seiten das gleiche Bild im Kopf haben. Unklare Anforderungen gelten in der Softwareentwicklung als häufigste Ursache für Budgetüberschreitungen.

Ein typisches Szenario zeigt den Hebel: Ein Betrieb wünscht sich eine Buchungsplattform für Coachings. In der Analyse zeigt sich oft, dass der Großteil der Buchungen über wenige Stammkunden läuft. Statt einer Plattform mit Login, Zahlungsanbindung und Kalender genügt dann häufig ein einfaches Formular mit Stripe-Anbindung. Das kann den Aufwand von rund 25 auf 4 Tage senken.

Technologiewahl: Frontend, Backend, API

Die richtige Technologie ist nicht die modernste, sondern die, die zum Problem, zum Team und zur Wartungssituation passt. Wer als kleines Unternehmen eine Anwendung mit Microservice-Architektur baut, schießt sich selbst ins Knie.

Für das Frontend ist React, eine der weltweit meistgenutzten JavaScript-Bibliotheken, eine sichere Wahl, ebenso Vue oder, bei serverseitigem Rendering, Next.js. TypeScript statt JavaScript ist heute Standard, weil es typische Fehler abfängt, bevor sie produktiv werden.

Im Backend hängt die Wahl stärker vom Kontext ab. Node.js mit TypeScript ist für viele Webanwendungen ein guter Default, weil Frontend und Backend dann die gleiche Sprache sprechen. Python mit Django oder FastAPI passt gut bei datenlastigen Anwendungen. PHP mit Laravel ist immer noch eine pragmatische Option, besonders wenn günstiges Hosting wichtig ist. Als Datenbank ist PostgreSQL für die meisten Fälle die richtige Antwort, MySQL bleibt die Alternative im klassischen Hosting-Umfeld.

Die API verbindet beides. REST ist der Standard, GraphQL die richtige Wahl, wenn das Frontend sehr unterschiedliche Datenzuschnitte braucht. Wichtig ist die Dokumentation, idealerweise als OpenAPI-Spezifikation. Wer später Mobile-Apps oder Drittanbieter anbinden will, wird dafür dankbar sein.

Projektbeispiele und realistische Budgets

Webanwendungen kosten zwischen 8.000 und 80.000 Euro, je nach Umfang, und alles darunter ist meistens unrealistisch. Wer Angebote unter 5.000 Euro für eine Custom-Lösung bekommt, sollte sehr genau hinschauen.

Drei typische Größenordnungen zur Orientierung:

Ein internes Verwaltungstool für ein Handwerksunternehmen, Login, drei Rollen, Auftragsverwaltung, PDF-Export: rund 12.000 Euro, 4 Wochen Umsetzung. Eine SaaS-Anwendung für Trainer mit Kundenkonten, Zahlungsabwicklung über Stripe, Terminkalender und E-Mail-Automation: rund 35.000 Euro, etwa 3 Monate. Eine Buchungsplattform mit zwei Marktseiten, Bewertungssystem und Reporting-Dashboard: rund 65.000 Euro, 5 Monate.

Diese Zahlen passen ungefähr zu den branchenüblichen Tagessätzen freier Entwickler in Deutschland, die typischerweise zwischen 800 und 1.200 Euro pro Tag liegen. Eine grobe Orientierung zu Web-Budgets allgemein findest du auch im Webdesign-Preisvergleich und unter Website erstellen lassen Kosten.

Wartung, Hosting und der Tag nach dem Launch

Eine Webanwendung ist mit dem Launch nicht fertig, sondern fängt erst an zu existieren. Wartung wird in 90 Prozent der Angebote unterschätzt oder gar nicht erwähnt.

Rechne mit 15 bis 20 Prozent der Initialkosten pro Jahr für laufenden Betrieb. Das deckt Sicherheitsupdates von Abhängigkeiten, Hosting-Kosten, kleine Anpassungen und Monitoring ab. Bei einer Anwendung für 30.000 Euro Erstellungskosten sind das realistisch 4.500 bis 6.000 Euro jährlich.

Beim Hosting ist die Frage nicht nur Preis, sondern Verantwortung. Plattformen wie Vercel oder Railway nehmen dir viel ab, kosten dafür mehr. Klassisches VPS-Hosting bei Hetzner ist günstiger, braucht aber jemanden, der sich um Server-Updates kümmert. Für die meisten kleineren Anwendungen ist die Managed-Variante das Geld wert, einfach weil dein Stundensatz höher ist als der Aufpreis.

Klär vor Projektstart, wer den Code besitzt, wo das Repository liegt, und wer in fünf Jahren noch Bescheid weiß. Wenn du mit einem Freelancer arbeitest, sollte der Code in deinem GitHub- oder GitLab-Account liegen, nicht im seinen. Mehr zu dieser Konstellation steht im Beitrag zum Freelance-Webdesigner beauftragen.

Die ehrlichste Empfehlung zum Schluss: Fang klein an. Bau die Version, die das Problem löst, nicht die Version, die jedes Problem lösen könnte. Erweitern kannst du immer.