7 Min. Lesezeit
Sébastien Nobour
Gründer von DEVEDANOS
Sie bereiten eine Finanzierungsrunde oder einen Finanzierungsantrag vor, um Ihre App entwickeln zu lassen. Sie brauchen eine Zahl. Ihre Investoren fragen danach, Ihr Finanzplan ebenso.
Die Frage „Wie viel?“ ist berechtigt. Sie ist aber nur ein Teil der Antwort. Mit demselben Betrag lässt sich eine App finanzieren, die niemand nutzt, oder eine App, mit der Ihre Kunden seit Monaten arbeiten. Den Unterschied macht nicht die Summe. Entscheidend ist, wie die App mit dieser Summe gebaut wird.
Die Ratgeber, die beantworten, „was die Entwicklung einer App kostet“, folgen fast alle derselben Methode. Man listet die Funktionen auf. Man ordnet jeder eine Anzahl von Tagen zu, je nachdem, ob sie einfach, mittel oder komplex ist. Man schlägt einen Puffer für Unvorhergesehenes auf, dann die Wartung im ersten Jahr. Heraus kommt eine Spanne.
Diese Methode stützt sich auf zwei Säulen: eine Schätzung und eine Funktionsliste. Wir stützen uns auf keine von beiden.
Warum eine Schätzung eine Vermutung bleibt, erklären wir ausführlich in unserem Artikel über Budgetüberschreitungen. Hier geht es uns um die Liste. Ihre Schwäche ist weniger offensichtlich. Sie verschiebt die Aufmerksamkeit.
Martin Fowler hat dieser Verschiebung einen Namen gegeben: FeatureDevotion. Gemeint ist der Zustand, in dem das Abhaken von Funktionen mehr zählt als das, was das Projekt tatsächlich bewirkt. Ein Budget, das Zeile für Zeile auf einer Liste aufgebaut wird, führt fast wie von selbst dorthin, denn jede abgehakte Zeile wird zum Beweis, dass das Geld gut ausgegeben wurde.
Hier liegt der häufigste Fehler. Man verwechselt das Ziel, das man erreichen will, mit den Dingen, die zu bauen sind. Man glaubt, mit der Lieferung der geplanten Funktionen sei das Ziel erreicht.
Doch eine Funktionsliste ist nur eine Hypothese über den Weg dorthin. Dave Farley erinnert daran, was die Daten der Branche zeigen: Selbst bei den besten Softwareunternehmen der Welt bringen zwei von drei Ideen keinen oder einen negativen Nutzen (Modern Software Engineering, S. 51). Niemand weiß im Voraus, welche. Bei Microsoft kommen Ronny Kohavi und seine Kollegen zum selben Befund („Online Experimentation at Microsoft“, 2009): Nur etwa ein Drittel der Ideen, die eine Kennzahl verbessern sollen, verbessert sie auch.
Allen Holub bringt es in einem Satz auf den Punkt: „Building the wrong thing on time and in budget doesn’t buy you much.“ Das Falsche termingerecht und im Budget zu bauen, bringt nicht viel.
Entscheidend ist also zu wissen, ob das Ziel erreicht ist. Nicht, welche Funktionen geliefert wurden.
Das Wenige, das man baut, muss sitzen. Ab dem ersten Entwicklungsmonat funktioniert die App. Sie kann wenig. Aber was sie kann, schafft Wert dort, wo es zählt: in den Augen der Menschen, an die Sie sie verkaufen wollen.
Danach funktioniert sie weiter, jederzeit. Genau dafür gibt es Continuous Delivery: Jede Änderung wird geprüft, bevor sie in die App gelangt, damit das, was gestern funktioniert hat, auch heute noch funktioniert.
Es geht nicht darum, viel zu schaffen. Jeden Tag stellt sich dieselbe Frage: Was ist heute das Nützlichste? Das ermöglicht der adaptive Ansatz. Er kommt schnell zum Wesentlichen. Und richtet die Aufmerksamkeit dann jeden Tag auf den Wert, der an diesem Tag erwartet wird.
Die Menschen, an die Sie die App verkaufen wollen, wissen, was wesentlich ist. Fragt man sie vorab, können sie es nicht immer sagen. Auch Farley stellt das fest: Selbst wenn man Nutzer fragt, was sie wollen, wissen sie es nicht (S. 51). Halten sie dagegen eine funktionierende App in der Hand, reagieren sie.
Die Feedbackschleife beginnt also so früh wie möglich. Die App kommt in ihre Hände. Man hört sich an, was sie dazu sagen. Man passt an. Und beginnt von Neuem.
Schon bevor man etwas baut, lässt sich eine Idee übrigens testen: Dafür gibt es das MVP.
Angenommen, die Schleife beginnt erst nach sechs Monaten Entwicklung. Dann ist es keine Schleife mehr. Dann sind es mehrere Schleifen auf einmal.
Das Feedback kommt gebündelt: was fehlt, was stört, was niemandem nützt. Jeder Punkt verlangt eine Änderung. Man weiß nicht mehr, womit man anfangen soll. Und sechs Monate Entwicklung auf Grundlage einer zu Beginn festgelegten Liste haben einen guten Teil des Budgets verbraucht.
Geldmangel ist übrigens fast nie die eigentliche Ursache. CB Insights hat 385 wagniskapitalfinanzierte Start-ups untersucht, die seit 2023 geschlossen wurden. 70 % von ihnen ging das Geld aus. Der Bericht betont, dass dies fast immer der letzte Grund für das Aus ist, nicht das Ausgangsproblem. Bei 43 % fand das Produkt keinen Markt (CB Insights, März 2026).
Wer monatelang Dinge gebaut hat, die niemand brauchte, bleibt mit einer Lehre zurück, die niemand gezogen hat. Das finden wir am bedauerlichsten. Niemand hat erklärt, was guter Code ist und was er wert ist.
Guter Code ist Code, den man leicht ändern kann.
Farley sagt es auf seine Weise: Ob ein Design gut oder schlecht ist, merkt man oft erst, wenn man versucht, es zu ändern (S. 108). Er erinnert auch an den Untertitel, den Kent Beck für sein Buch über Extreme Programming gewählt hat: Embrace Change, Veränderung annehmen. Laut Farley folgt alles andere aus diesem Gedanken: sich die Fähigkeit bewahren, seine Meinung, seinen Code, seine Technologie zu ändern, während man dazulernt (S. 155).
Bei einer App, die anhand des Feedbacks ihrer Nutzer gebaut wird, entscheidet diese Fähigkeit über alles. Jedes Feedback verlangt eine Änderung. Ist jede Änderung teuer oder macht sie etwas anderes kaputt, wird die Schleife langsamer, und das Budget fließt in Reparaturen. Farley fasst es so zusammen: Auf Dauer wählt man nicht zwischen besserer Software und Software, die schneller fertig ist, sondern zwischen „better software faster“ und „worse software slower“ (S. 154).
Für eine Finanzierungsrunde brauchen Sie trotzdem einen Betrag. Diesen Betrag erhalten Sie nicht, indem Sie Funktionen addieren. Sie erhalten ihn, indem Sie entscheiden, was Sie jeden Monat investieren und wie viele Monate Sie von Ihren Nutzern lernen wollen, bevor die nächste Entscheidung ansteht.
Holub argumentiert genauso. Gibt das Team jeden Monat denselben Betrag aus, fallen Budget und Termin zusammen. Ist das Budget festgelegt, bleibt als einzige Variable der Umfang. Martin Fowler kommt zum selben Ergebnis: Ein Festpreis ist möglich, ein fester Umfang nicht. Die nützlichsten Funktionen wählen wir gemeinsam im Laufe des Projekts aus.
Der adaptive Ansatz sagt voraus, was vorhersehbar ist: das Monatsbudget und die Entwicklungstage pro Monat. Er versucht nicht vorherzusagen, was sich nicht vorhersagen lässt: was Ihre Nutzer mit einer Funktion machen, bevor sie sie in den Händen haben.
So arbeiten wir. Wir entwickeln Ihre individuelle App zu einem festen Budget, abgerechnet am Ende jedes Monats für die geleistete Arbeit. Sie ist innerhalb eines Monats nutzbar. Nutzbar heißt nicht fertig: Ihre Teams arbeiten ab dem ersten Monat damit. Was wir aus der Nutzung über eine Funktion lernen, setzen wir noch am selben Tag um.
Fest stehen das Budget und das zu lösende Problem. Mit Ihrem Budget kaufen Sie Arbeit, die dieses Problem vom ersten Entwicklungstag an laufend abmildert. Wir streben an, es vollständig zu lösen, können das aber weder garantieren noch terminieren. Damit das Problem kleiner wird, müssen Sie nicht auf diesen Tag warten. Jeden Monat sehen Sie, was dabei herauskommt, und Sie entscheiden, ob Sie weitermachen.
Preis und Funktionsliste zugleich festschreiben oder nach Aufwand bezahlen: Wer das Risiko trägt, wenn sich der Bedarf ändert, darum geht es in unserem Artikel über Festpreis und Abrechnung nach Aufwand.
Sie nehmen Kapital auf, um Ihre App entwickeln zu lassen, oder suchen das richtige Budget? Sprechen wir darüber?
Was ist ein Feature Flag? Vier Arten von Toggles, was Sie versuchen sollten, bevor Sie einen hinzufügen, und sieben Anti-Patterns, durch die nie getesteter Code läuft.
Prädiktiver oder adaptiver Ansatz? Die eigentliche Trennlinie verläuft nicht zwischen V-Modell und agilem Vorgehen, sondern zwischen Vorhersagen und Anpassen. Was das für Software bedeutet.
Was ist ein MVP in der Softwareentwicklung? Nicht die Version 1 einer Software, sondern der kleinste Test, der zeigt, ob sich die Entwicklung einer Idee lohnt. Und was danach kommt.