Wissen / Artikel

Was kostet es, eine eigene SaaS oder Web-App entwickeln zu lassen?

Die ehrliche Antwort vorweg: Es gibt keinen Pauschalpreis. Eine Web-App kann 6.000 Euro kosten oder 250.000 Euro - und beides kann fuer den jeweiligen Fall korrekt sein. Der Unterschied liegt nicht im Glueck, sondern im Umfang. Damit du nicht im Nebel stocherst, zerlegen wir hier die echten Kostenfaktoren und nennen realistische Spannen, statt dir eine Wunschzahl zu verkaufen.

Warum die Spanne so gross ist

Eine SaaS ist kein Produkt von der Stange, sondern eine Summe von Entscheidungen. Jede dieser Entscheidungen verschiebt den Preis - manchmal um Hunderte, manchmal um Zehntausende Euro. Die wichtigsten Treiber:

MVP statt Vollprodukt: der wichtigste Hebel

Der grobe Fehler vieler Erstgruender ist, von Tag eins an alles bauen zu wollen. Das verbrennt Budget fuer Funktionen, die am Ende kein Mensch nutzt. Klueger ist ein MVP (Minimum Viable Product): die kleinste Version, die ein echtes Problem loest und mit der du erste Nutzer oder erste Zahlungen gewinnst.

Ein MVP umfasst typischerweise den einen Kern-Workflow, Login und eine einfache Datenverwaltung - mehr nicht. Alles andere kommt spaeter, wenn echtes Nutzer-Feedback zeigt, wohin sich das Produkt wirklich entwickeln muss. Das spart nicht nur Geld, es verhindert auch, dass du Wochen in Features investierst, die du danach wieder loeschst.

Ein durchdachtes MVP startet bei uns im Bereich von rund 6.000 Euro. Ein vollwertiger SaaS- oder Tech-Build mit Nutzer-Teams, Abrechnung, mehreren Modulen und Schnittstellen bewegt sich realistisch zwischen 6.000 und 25.000 Euro, je nach Tiefe. Geht es um eine reine Webseite mit Inhalten statt einer App, bist du deutlich darunter: ein One-Pager liegt bei 2.000-3.000 Euro, eine mehrseitige Seite mit Redaktionssystem bei 4.500-8.000 Euro.

Womit wir hier sprechen koennen

Wir reden bei SaaS-Kosten nicht aus der Theorie. Wir betreiben sieben eigene Marken live in Produktion - darunter einen Barrierefreiheits-Scanner, ein Kosmetik-Produktportal mit rund 177.000 Produkten, ein Fahrzeug-Deal-Radar, eine Marine-SaaS und einen Industrie-Marktplatz. Jede dieser Anwendungen haben wir selbst gebaut, betrieben, skaliert und teils auch wieder verschlankt. Wir kennen also nicht nur die Bau-, sondern auch die laufenden Kosten - und genau die unterschaetzen die meisten.

Die Kosten, an die niemand denkt

Der Entwicklungspreis ist nur die erste Rechnung. Eine SaaS lebt weiter, und das verursacht laufende Ausgaben:

Plane fuer den Betrieb einen monatlichen Posten ein, statt ihn zu ignorieren. Eine App, die niemand pflegt, wird innerhalb von ein bis zwei Jahren zum Risiko.

Wann du gar keine eigene Entwicklung brauchst

Auch das gehoert zur ehrlichen Antwort: Nicht jede Idee braucht eine massgeschneiderte SaaS. Wenn ein bestehendes Tool oder eine Kombination aus Standard-Bausteinen deinen Bedarf deckt, ist Eigenentwicklung oft die teurere und langsamere Loesung. Erst wenn dein Workflow wirklich speziell ist, du Datenhoheit brauchst oder das Produkt selbst dein Geschaeftsmodell ist, lohnt sich der eigene Bau. Bevor du Geld in Code steckst, lohnt sich die nuechterne Frage, ob es einen fertigen Weg gibt.

Festpreis statt Stundenlotterie

Stundensaetze klingen flexibel, sind aber fuer dich ein unkalkulierbares Risiko - jede Verzoegerung zahlst du. Wir arbeiten deshalb mit klar definierten Festpreis-Stufen: Du weisst vorab, was du bekommst und was es kostet. Das setzt voraus, dass der Umfang sauber abgesteckt ist, und genau dieser erste Klaerungsschritt ist die beste Investition gegen boese Ueberraschungen.

Brauchst du selbst eine Website, ein Tool oder eine SaaS?

Wir bauen sie zum Festpreis - vom Team, das sieben eigene Marken live betreibt. Klarer Scope, klarer Preis, klarer Zeitrahmen.

Projekt startenLeistungen & Preise

Was in ein gutes Angebot gehört

Ein seriöses Angebot für eine SaaS- oder Web-App-Entwicklung listet nicht nur eine Gesamtsumme, sondern beschreibt den Funktionsumfang konkret genug, dass du ihn nachvollziehen kannst. Achte darauf, ob einzelne Funktionen benannt sind oder ob nur vage von individueller Software die Rede ist – Letzteres ist ein Warnsignal.

Genauso wichtig ist, was ausdrücklich nicht enthalten ist. Seriöse Anbieter grenzen den Umfang bewusst ab und benennen, was als Zusatzaufwand gilt, statt das im Nachhinein zu klären. Frag aktiv danach, wenn ein Angebot dazu schweigt.

Ein gutes Angebot nennt außerdem einen realistischen Zeitrahmen und beschreibt, in welcher Form du Zwischenstände zu sehen bekommst. Ohne Zwischenstände merkst du erst am Ende, ob die Entwicklung in die richtige Richtung läuft. Frag auch nach, wie mit Verzögerungen umgegangen wird, etwa wenn eine Rückmeldung von dir selbst auf sich warten lässt – auch das gehört in ein transparentes Angebot.

So bereitest du die Anfrage vor, damit die Schätzung stimmt

Je klarer du beschreibst, was deine Software tun soll, desto genauer kann ein Anbieter den Aufwand schätzen. Es reicht dabei nicht, das Endziel zu beschreiben – hilfreicher ist, den konkreten Ablauf aus Nutzersicht Schritt für Schritt aufzuschreiben, inklusive der Fälle, die vom Normalfall abweichen.

Überlege dir vorab auch, welche Nutzerrollen es gibt und welche Daten wirklich gespeichert werden müssen. Diese beiden Punkte beeinflussen den Aufwand stärker als das äußere Erscheinungsbild, werden aber in ersten Gesprächen oft übersehen, weil sie weniger sichtbar sind.

Wenn du bereits ähnliche Tools oder Wettbewerber kennst, die etwas Vergleichbares anbieten, nenne sie. Das gibt dem Anbieter einen schnellen Referenzpunkt und verhindert Missverständnisse darüber, wie umfangreich dein Produkt tatsächlich werden soll.

Typische Vertragsfallen bei der Beauftragung

Eine häufige Falle ist unklares geistiges Eigentum am Code. Kläre vor Vertragsbeginn schriftlich, dass die Rechte am fertigen Code nach vollständiger Bezahlung bei dir liegen, sonst bist du im schlimmsten Fall vom ursprünglichen Anbieter für jede Änderung abhängig.

Ebenso wichtig ist die Frage, wer Zugriff auf Quellcode, Server und Datenbank hat, während und nach dem Projekt. Bestehe darauf, dass du jederzeit Zugang zu allen Zugangsdaten und Repositories hast, nicht erst nach Abschluss oder auf Nachfrage.

Vorsicht auch bei sehr niedrigen Angeboten ohne klaren Leistungsumfang: Sie werden häufig über Nachträge nachträglich teuer, weil vieles, was du für selbstverständlich hältst, im Kleingedruckten als Zusatzleistung auftaucht. Ein etwas höherer, aber klar abgegrenzter Festpreis ist am Ende oft günstiger und planbarer. Hol dir im Zweifel eine zweite Einschätzung ein, bevor du unterschreibst, gerade bei größeren Summen.

Häufig gestellte Fragen

Wie lange dauert die Entwicklung eines MVP?

Das hängt stark vom Funktionsumfang ab; ein schlanker MVP mit einem klar definierten Kern-Workflow lässt sich deutlich schneller umsetzen als ein Produkt mit mehreren Modulen und Rollen.

Brauche ich vor der Beauftragung schon ein fertiges Konzept?

Nicht zwingend, aber je klarer du den gewünschten Ablauf beschreiben kannst, desto genauer wird die Schätzung, und desto weniger Missverständnisse entstehen während der Umsetzung.

Was passiert, wenn während der Entwicklung neue Anforderungen dazukommen?

Bei einem Festpreis-Modell werden zusätzliche Anforderungen als separater Nachtrag behandelt, damit der ursprüngliche Preis und Zeitrahmen für den vereinbarten Umfang verlässlich bleiben.

Gehören mir die Rechte am Code nach der Fertigstellung?

Das sollte vertraglich klar geregelt sein. Achte darauf, dass die Nutzungsrechte am Code nach vollständiger Bezahlung eindeutig auf dich übergehen.

Lohnt sich ein No-Code-Tool statt einer eigenen Entwicklung?

Für viele einfachere Anwendungsfälle ja. Eine eigene Entwicklung lohnt sich vor allem dann, wenn dein Workflow speziell ist oder ein No-Code-Tool erkennbar an seine Grenzen stößt.

Wie finde ich heraus, ob ein Angebot realistisch ist?

Vergleiche mehrere Angebote für denselben, klar beschriebenen Funktionsumfang und achte darauf, ob alle Anbieter über dieselben Punkte sprechen oder ob wichtige Aufwände in einem Angebot einfach fehlen.

Was kostet die Wartung nach dem Launch zusätzlich?

Das hängt vom Umfang und der Komplexität der Anwendung ab; plane dafür in jedem Fall einen laufenden monatlichen Posten ein, statt ihn erst nach dem Launch zu klären.