Im Artikel Was kostet eine App? habe ich die größten Kostenfaktoren erklärt. Dieser Artikel geht einen Schritt weiter: Welchen Aufwand kannst du selbst beeinflussen – und wie sparst du Kosten, ohne an der falschen Stelle zu kürzen?
Die falsche Sparstrategie: am Entwickler sparen
Die offensichtliche Idee: ein günstiger Entwickler, niedrige Stundensätze, mehr Flexibilität bei Mehraufwand.
Das Problem: Gute Entwickler kennen ihren Wert. Günstige Entwickler sind es aus einem Grund. Oder um es direkt zu sagen:
Wer denkt, dass es teuer ist, mit einem Profi zu arbeiten, der hat noch nie mit einem Amateur gearbeitet.
Kurzfristig eingesparte Entwicklungskosten können sich schon nach wenigen Monaten in deutlich höheren Wartungs- und Umbaukosten niederschlagen. Schlecht strukturierter Code verlangsamt jede Erweiterung, erzeugt neue Bugs beim Beheben alter und macht das gesamte Projekt fragil. Ich habe mehrere Projekte übernommen und gerettet – ein Unterfangen, das für die Kunden alles andere als günstig war.
Feature Creep: die häufigste versteckte Kostenquelle
Feature Creep – auch Scope Creep – ist das schleichende Einschleichen neuer Features in den Projektumfang, oft als scheinbare Kleinigkeiten getarnt.
So beginnt es: Während der Entwicklung fällt dir eine neue Idee auf, die eigentlich nur eine kleine Verbesserung ist. Du fragst den Entwickler. Es ist doch nur eine Kleinigkeit. Und das Ergebnis ist schöner als vorher.
Dann passiert es wieder. Und wieder. Jedes Mal ist es eine Kleinigkeit. Aber die Kleinigkeiten summieren sich – und plötzlich kostet das Projekt mehr als ursprünglich veranschlagt. Manchmal mehr als das ursprünglich geplante Gesamtprojekt.
Das Phänomen tritt so häufig auf, dass es einen eigenen Namen hat – und so gut wie jeder erfahrene Entwickler hat schon erlebt, wie es zu Knatsch zwischen Auftraggeber und Entwickler geführt hat.
Woran erkennst du Feature Creep bei dir selbst? Wenn dir immer wieder neue Ansätze einfallen, wie das Kernproblem deiner Kunden gelöst werden könnte, und du zwischen diesen Ansätzen hin- und herjagst, anstatt dich für einen zu entscheiden. Das ist ein Zeichen dafür, dass das Konzept noch nicht ausgereift genug ist.
Gut vorbereiten spart Geld
Eine gute Vorbereitung ist eine direkte Investition in niedrigere Entwicklungskosten. Konkret:
Rede mit deinen Kunden. Verstehe das Problem, das du lösen willst, wirklich gut. Probiere Lösungsansätze auf Papier und analog aus, bevor du in technische Umsetzung investierst. Teste unterschiedliche Ideen. Fixiere dich nicht auf deinen eigenen Lieblingsansatz – schau, was bei den Nutzern ankommt.
Definiere Regeln. Programmieren bedeutet Regeln erstellen: Wenn X passiert, dann Y. Regeln sind nur Regeln, wenn sie immer gelten. Definiere also, wie deine Prozesse funktionieren – einheitlich und vollständig. Jeder Sonderfall bedeutet extra Aufwand. Hinterfrage, ob der Sonderfall wirklich notwendig ist, oder ob er durch eine andere Lösung vermieden werden kann.
Teile dein Domänenwissen. Du kennst deine Kunden, dein Geschäftsfeld und die Zusammenhänge hinter deinem Produkt. Der Entwickler nicht. Je besser du ihm das vermittelst, desto weniger Fragen, Wartezeiten und Missverständnisse entstehen – und desto weniger Nacharbeit ist nötig.
Klein anfangen: MVP zuerst
Ein MVP (Minimum Viable Product) ist die kleinste sinnvoll nutzbare Version deiner App. Starte damit – und nicht mit allem auf einmal.
Das hat zwei Vorteile:
- Du sparst initialen Aufwand. Du entwickelst nur, was für den ersten Schritt wirklich nötig ist.
- Du bekommst früh echtes Feedback. Wenn du nach dem MVP feststellst, dass die Idee in dieser Form nicht funktioniert, hast du deutlich weniger Geld investiert als in ein voll ausgebautes Produkt.
Danach gilt: Nutzer beobachten, Feedback einholen, gezielt ausbauen – statt vorab alles einzuplanen.
Erst eine Plattform, dann die zweite
Muss die App auf iOS und Android verfügbar sein? Dann überlege, ob beide Plattformen wirklich gleichzeitig entwickelt werden müssen.
Wenn zuerst nur iOS entwickelt wird, klären sich in dieser Phase alle Unklarheiten, die sowieso auftauchen. Die zweite Plattform (Android) profitiert davon: Sie wird auf einem geebnetem Weg entwickelt, mit weniger Überraschungen, in kürzerer Zeit – und damit günstiger.
Den Entwickler arbeiten lassen: eine Lektion von Astronauten
Der kanadische Astronaut Chris Hadfield beschreibt in seinem Buch ein Prinzip, das direkt auf App-Projekte übertragbar ist: Sei eine Null – keine Plus Eins.
Wir Menschen wollen helfen und einen Beitrag leisten. Manchmal passiert dabei das Gegenteil: Wir blockieren die Leute, die ihren Job gerade machen. Wir sind nicht hilfreich, sondern eine Bürde.
Besonders wenn du keine Erfahrung mit Softwareentwicklung hast, gilt: Mache dich erst mit der Situation vertraut. Frage den Entwickler, was er braucht, um weiterzumachen – und liefere genau das. Wenn er keine Rückfrage hat, lass ihn arbeiten. Du musst nichts beweisen. Der Übereifer eines neuen Auftraggebers, der überall mitredet und Prozesse hinterfragt, kostet Zeit und Fokus.
Helfen, wenn es sinnvoll ist. Aus dem Weg gehen, wenn es besser ist.
Zusammenfassung
| Maßnahme | Wirkung |
|---|---|
| Guten Entwickler wählen | Spart langfristige Wartungs- und Reparaturkosten |
| Feature Creep vermeiden | Verhindert unkontrollierte Kostensteigerungen |
| Konzept gut ausarbeiten | Verhindert teure Richtungswechsel während der Entwicklung |
| Domänenwissen klar kommunizieren | Spart Wartezeiten und Nacharbeit |
| MVP zuerst | Reduziert initialen Aufwand, ermöglicht frühes Feedback |
| Erst eine Plattform | Zweite Plattform wird günstiger durch geklärten Weg |
| Entwickler nicht blockieren | Spart Zeit und erhält Fokus |
Häufig gestellte Fragen
Warum ist es riskant, den günstigsten Entwickler zu wählen? Günstige Entwickler liefern oft Code, der kurzfristig funktioniert, aber langfristig teuer wird: durch schwerer erweiterbare Strukturen, häufigere Bugs und aufwendigere Wartung. In manchen Fällen ist eine komplette Neuentwicklung günstiger als das Weiterflicken.
Was ist Feature Creep? Feature Creep bezeichnet das schleichende Einschleichen neuer Features in einen laufenden Projektplan, oft als scheinbare Kleinigkeiten. Die Summe dieser Kleinigkeiten kann die ursprünglichen Projektkosten erheblich übersteigen.
Was ist ein MVP? Ein Minimum Viable Product (MVP) ist die kleinste sinnvoll nutzbare Version einer App. Statt alles sofort zu entwickeln, startet man mit dem Kern – und baut auf Basis echten Nutzerfeedbacks gezielt aus.
Muss ich iOS und Android gleichzeitig entwickeln? Nein. Es kann sinnvoll sein, zuerst eine Plattform zu entwickeln und die zweite nachzuziehen. Die zweite Plattform profitiert von allen Erkenntnissen der ersten – und wird dadurch schneller und günstiger entwickelt.