Was eine individuelle App wirklich kostet: eine ehrliche, transparente Aufschlüsselung

Fragen Sie drei Agenturen, was eine individuelle App kostet, und Sie erhalten drei Zahlen, die nicht einmal eine Ziffer gemeinsam haben. Die eine sagt viertausend, die andere vierzig, die dritte sagt leise „kommt darauf an“ und vereinbart einen zweiten Termin. Keine von ihnen lügt wirklich — aber keine sagt Ihnen das, was Sie eigentlich wissen müssten: wohin das Geld fließt und warum genau Ihre App dort landet, wo sie landet. Öffnen wir also die Motorhaube.

Ich habe mehr App-Angebote geschrieben, als ich zählen kann — für Betriebe von der Ein-Personen-Handwerksfirma bis zur regionalen Kette. Die mit Abstand häufigste Reaktion auf einen Preis ist nicht der Schock über die Summe, sondern die Verwirrung über die Spanne. Wie kann derselbe Drei-Wort-Auftrag („eine Buchungs-App“) Schätzungen hervorbringen, die um das Zehnfache auseinanderliegen? Die ehrliche Antwort: „eine Buchungs-App“ ist kein Auftrag. Es ist ein Wunsch. Der Preis steckt in den hundert kleinen Entscheidungen, die sich darunter verbergen.

Dieser Beitrag ist die Aufschlüsselung, die ich jedem Unternehmer vor seinem ersten Gespräch mit einem Entwickler an die Hand geben würde. Kein Füllmaterial, keine Angstmacherei, kein Upselling. Nur die echten Kostenbestandteile, die Dinge, die ein Budget heimlich verdoppeln, und ein paar ehrliche Wege, weniger auszugeben, ohne am Ende etwas zu bereuen.

Warum zwei Angebote für „dieselbe App“ um das Zehnfache abweichen

Software ist kein Produkt, das Sie aus dem Regal nehmen — sie ist Arbeit, gemessen in den Stunden qualifizierter Menschen. Der Preis einer individuellen App ist daher im Kern schlicht Umfang × Stundensatz × Risiko. Alles andere ist eine Fußnote zu diesen drei Größen. Wenn zwei Angebote stark auseinandergehen, wird eine dieser drei Zahlen sehr unterschiedlich gelesen — und meist hat das niemand laut ausgesprochen.

Der Umfang ist der offensichtliche Faktor. „Eine Buchungs-App“ kann ein einziger Bildschirm sein, auf dem Kunden einen Termin wählen — oder sie umfasst Mitarbeiterkalender, Zahlungen, Erinnerungen, einen Kundenlogin, ein Admin-Dashboard, Rückerstattungen und einen Bericht, den der Chef montags liest. Dieselben drei Wörter, zehnfacher Aufwand. Das günstige Angebot unterstellt oft die kleine Variante, das teure stillschweigend die große. Keiner hat Sie gefragt, was Sie meinten.

Dann ist da das Risiko, der Teil, den niemand gern einpreist. Ein vager Auftrag, ein Kunde, der noch nicht entschieden hat, was er will, eine Anbindung an ein altersschwaches Altsystem — das fügt nicht nur Stunden hinzu, sondern Unsicherheit. Erfahrene Teams kalkulieren Unsicherheit ein, weil sie sich daran schon die Finger verbrannt haben. Ein günstigeres Angebot hat das Risiko oft überhaupt nicht eingepreist — und genau deshalb explodiert es manchmal auf halber Strecke.

Wohin das Geld wirklich fließt

Wenn Menschen sich App-Entwicklung vorstellen, denken sie ans Programmieren. Programmieren ist real, aber es macht selten auch nur die Hälfte der Rechnung aus. Eine individuelle App gleicht eher dem Bau eines kleinen Hauses als dem Schreiben eines Dokuments — rund um den sichtbaren Teil gibt es Planung, Leitungen, Abnahme und Papierkram. So verteilt sich ein typisches Budget, wenn man alles berücksichtigt.

Zwei Dinge überraschen die meisten an dieser Tabelle. Erstens, wie viel des Budgets anfällt, bevor eine einzige Zeile Funktionscode geschrieben ist — Konzept und Design sind kein Luxus, sondern der günstigste Ort, um einen Fehler zu korrigieren. Einen Bildschirm in einer Skizze zu ändern kostet Minuten; ihn nach dem Bau zu ändern kostet Tage. Zweitens, wie real die Testzeile ist. Sie zu überspringen spart kein Geld, es verschiebt die Kosten nur in Ihre Launch-Woche — mit Zinsen.

Konzept und Design: der Teil, den alle überspringen wollen

In der Konzeptphase machen Sie aus „einer Buchungs-App“ eine präzise Liste aus Bildschirmen und Regeln. Es fühlt sich wie Mehraufwand an, weil noch nichts gebaut wird. Doch jede Stunde hier spart mehrere im weiteren Verlauf, denn hier wird Mehrdeutigkeit beseitigt, solange sie noch billig ist. Ein Team, das Ihnen einen Preis ohne Konzeptphase nennt, rät entweder — oder plant, Ihnen das Konzept später unter einem anderen Namen in Rechnung zu stellen.

Kernentwicklung: der sichtbare Motor

Das ist der Code, der Ihre Idee zum Laufen bringt — die Bildschirme, die Menschen antippen, die Logik dahinter und die Datenbank, die sich still alles merkt. Es ist der größte Einzelposten, und er skaliert nahezu direkt mit dem Umfang. Jede Funktion, die Sie hinzufügen, bedeutet mehr zu bauen, mehr zu testen und für immer mehr zu pflegen. Hier wird „wäre doch schön, wenn“ schnell teuer.

Integrationen: der trügerisch teure Teil

Ihre App mit anderen Systemen zu verbinden — eine Kartenzahlung entgegennehmen, eine SMS-Erinnerung senden, einen Kalender synchronisieren, Daten aus Ihrer vorhandenen Buchhaltungssoftware ziehen — sieht auf einer Funktionsliste klein aus und schlägt auf der Rechnung überraschend schwer zu Buche. Jede Verbindung ist ein eigenes kleines Projekt mit eigenen Eigenheiten und Fehlerquellen. Eine brave Zahlungsintegration ist kein Problem. Fünf verworrene Integrationen mit einem betagten hauseigenen System sind der Ort, an dem Budgets sterben.

Die Kosten, die niemand ins Angebot schreibt

Hier erleben viele Unternehmer nach zwölf Monaten eine böse Überraschung. Der Bau ist eine einmalige Zahl; eine App ist keine einmalige Sache. Software lebt — Telefone aktualisieren sich, Regeln ändern sich, Ihr Geschäft wächst — und etwas Lebendiges will gefüttert werden. Das Angebot, das Sie unterschreiben, ist der Preis der Geburt, nicht der Preis des Besitzes.

Nichts davon ist Betrug oder eine versteckte Falle — es ist nur der Teil, der nicht sauber auf ein einseitiges Angebot passt, weshalb schwächere Partner ihn weglassen, um günstiger zu wirken. Ein guter Partner spricht es vorab an, auch wenn seine erste Zahl dadurch größer aussieht. Fragen Sie ausdrücklich: Was kostet mich der Betrieb für ein Jahr nach dem Launch? Die Qualität der Antwort verrät Ihnen viel über Ihr Gegenüber.

Was den Preis heimlich verdoppelt

Manche Dinge verursachen Kosten im Verhältnis zum Nutzen, den sie bringen — fair genug. Andere verursachen Kosten völlig außer Verhältnis, meist wegen der Art, wie die Arbeit strukturiert ist, und nicht wegen dessen, was die App leistet. Diese Hebel lohnt es zu verstehen, denn einige liegen ganz in Ihrer Hand.

• Zwei Plattformen statt einer. Eine native iPhone-App und eine native Android-App sind grob gesagt zwei Builds. Plattformübergreifende Werkzeuge oder eine Web-App führen das wieder Richtung eins zusammen. Diese eine Entscheidung kann die Gesamtsumme stärker bewegen als jede Funktion.
• Individuelles Design statt sinnvoller Standards. Eine pixelgenaue, vollständig maßgeschneiderte Oberfläche kostet echtes Geld in Design und Umsetzung. Eine saubere, konventionelle Lösung mit bewährten Mustern ist schneller, günstiger und für Kunden oft einfacher zu bedienen.
• Meinungsänderungen nach Baubeginn. Entscheidungen sind auf dem Whiteboard billig und im Code teuer. Die häufigste Budgetüberschreitung beruht nicht auf schlechtem Schätzen — sondern auf einem Umfang, der immer weiter wuchs, weil nichts festgezurrt war.
• Echtzeit, Offline-Betrieb oder große Datenmengen. „Es soll ohne Empfang funktionieren“ oder „Aktualisierungen müssen für alle sofort erscheinen“ sind vernünftige Wünsche, die die Technik dahinter still vervielfachen.
• Anbindung an etwas Altes und Undokumentiertes. Die Verbindung zu einem modernen, gut gebauten System ist Routine. Die Verbindung zu einem fünfzehn Jahre alten hauseigenen Werkzeug ohne Dokumentation ist Archäologie — und wird nach Stunden abgerechnet.

Ein echtes Beispiel: aus dem 60.000-€-Angebot wurde eine 14.000-€-App

Einige Details wurden zum Schutz der Privatsphäre geändert, aber das Muster ist wahr und absolut typisch. Ein regionaler Dienstleister — denken Sie an ein Dutzend Außendienstmitarbeiter und ein geschäftiges Büro — kam frustriert zu uns. Sie wollten eine individuelle App, über die ihre Kunden Aufträge buchen, den Fortschritt verfolgen und bezahlen können. Sie hatten anderswo bereits ein Angebot über rund 60.000 € plus eine saftige monatliche Gebühr erhalten — und das hatte ihnen die ganze Idee fast ein Jahr lang verleidet.

Als wir tatsächlich kartierten, was sie brauchten — nicht das, was ihnen angeboten worden war — sah das Bild ganz anders aus. Das erste Angebot hatte zwei vollständig native Apps unterstellt, ein von Grund auf maßgeschneidertes Design, ein Echtzeit-Dispositionssystem und eine individuelle Admin-Plattform, um Werkzeuge zu ersetzen, die sie bereits besaßen und mit denen sie still zufrieden waren. Es war, technisch gesehen, eine völlig gute App. Es war auch die Antwort auf eine Frage, die sie nie gestellt hatten.

Was wir tatsächlich getan haben

Wir verbrachten die ersten Sitzungen ausschließlich mit Konzeptarbeit — wir zerlegten den Wunsch in „ohne das geht der Betrieb kaputt“ versus „das wäre irgendwann nett“. Die Must-haves waren enger, als alle erwartet hatten: ein sauberer Weg für Kunden, einen Auftrag anzufragen und zu verfolgen, automatische Erinnerungen und Online-Zahlung. Die Echtzeit-Disposition und das individuelle Backoffice entpuppten sich als Lösungen für Probleme, die ihre bestehende Software bereits bestens abdeckte.

1. 1
   Den Umfang auf die echte Aufgabe gekürzt

   Wir strichen die Funktionen, die Probleme lösten, die sie gar nicht hatten, und behielten eine knappe Liste, ohne die der Betrieb wirklich nicht laufen konnte.
2. 2
   Einen plattformübergreifenden Build gewählt

   Statt zweier separater nativer Apps deckte eine einzige plattformübergreifende App iPhone und Android ab — was die Kernentwicklung grob halbierte.
3. 3
   Bewährte Design-Muster genutzt

   Eine saubere, konventionelle Oberfläche statt einer maßgeschneiderten. Kunden fanden sie einfacher zu bedienen, und sie sparte Wochen im Zeitplan.
4. 4
   Verbunden, nicht ersetzt

   Wir koppelten die App an die Bürosoftware, für die sie ohnehin bezahlten, statt sie nachzubauen. Die teure „individuelle Admin-Plattform“ verschwand schlicht aus dem Umfang.

Das Ergebnis war ein Bau von rund 14.000 €, in wenigen Monaten live, mit kalkulierbaren laufenden Kosten. Sie ist nicht so ausufernd wie die 60.000-€-Variante — und das muss sie auch nicht sein. Sie erledigt die Aufgabe, die der Betrieb tatsächlich hatte. Ein Jahr später haben sie zwei kleine Funktionen ergänzt, bezahlt aus dem Geld, das die erste Version ihnen gespart hat. Das ist das ganze Muster: mit der echten Aufgabe beginnen, die Extras mit Ergebnissen verdienen.

Wie Sie die Kosten im Rahmen halten, ohne zu schludern

Bei einer individuellen App weniger auszugeben heißt nicht, den Stundensatz herunterzuhandeln oder das billigste Team zu suchen. So zahlt man am Ende doppelt. Es heißt, bewusst mit Umfang, Reihenfolge und Entscheidungen umzugehen — den drei Dingen, die die Zahl wirklich bewegen. Hier liegen die echten Einsparungen.

Erstens: bauen Sie die kleinste Version, die tatsächlich nützlich ist, und lassen Sie sie dann wachsen. Eine fokussierte erste Veröffentlichung, die eine Sache gut erledigt, bringt Sie schneller live, kostet einen Bruchteil des Alles-in-einem-Traums und — entscheidend — lehrt Sie aus echten Kunden statt aus Vermutungen, was als Nächstes zu bauen ist. Zweitens: treffen Sie Ihre Entscheidungen vor Baubeginn; Unentschlossenheit ist das Teuerste, das Sie in ein Projekt einbringen können. Drittens: binden Sie an, was Sie bereits besitzen, statt funktionierende Werkzeuge zu ersetzen, und bauen Sie etwas nur dann neu, wenn es Sie wirklich ausbremst.

Häufige Fragen