8 teure App-Entwicklungsfehler, die KMU immer wieder machen

Hier ist die unbequeme Wahrheit über App-Projekte, die aus dem Ruder laufen: Wenn der Code falsch aussieht, war das Projekt schon Wochen früher verloren. Die teuren Fehler in der App-Entwicklung kleiner Unternehmen passieren fast nie an der Tastatur. Sie passieren in beiläufigen Gesprächen — das Briefing, das nie aufgeschrieben wurde, die Funktion, die jemand 'wenn wir schon dabei sind' hinzufügte, der Entwickler, den ein Freund empfohlen hat. Im Moment fühlt sich nichts davon wie eine Entscheidung an. Alles davon kostet Sie später.

Ich habe viele kleine Unternehmen ihre erste App in Auftrag geben sehen, und ich wurde oft im Nachhinein zur Rettung gerufen. Die Inhaber sind selten sorglose Menschen. Sie sind klug, sorgfältig, gut darin, ein Unternehmen zu führen. Aber Software hat ihre eigenen Fallen, die es sonst nirgendwo in ihrem Arbeitsleben gibt, und niemand hat sie gewarnt. Also laufen sie geradewegs in dieselben acht Fallstricke, in ungefähr derselben Reihenfolge, jedes Mal.

Das ist die Liste, die ich jedem Inhaber gewünscht hätte, bevor er einen Cent ausgibt. Keine Theorie — die tatsächlichen, immer wiederkehrenden Fehler und die kleinen Kurskorrekturen, die jedes Projekt gerettet hätten. Wenn Sie kurz davor sind, eine App zu bauen, oder schon mittendrin sind und sich etwas falsch anfühlt, lesen Sie zuerst dies. Die meisten davon lassen sich noch beheben, wenn Sie sie früh erkennen.

Fehler 1: Bauen, bevor Sie bewiesen haben, dass es jemand will

Der teuerste Fehler ist zugleich der häufigste: sich auf eine vollständige Entwicklung festzulegen, bevor es echte Belege dafür gibt, dass die App ein Problem löst, für das Menschen zahlen oder das sie nutzen würden. Dem Inhaber erscheint die Idee offensichtlich — natürlich wollen Kunden das — und genau diese Gewissheit ist gefährlich. Gewissheit fühlt sich wie Validierung an. Ist sie aber nicht.

Validierung bedeutet nicht, zehn Freunde zu fragen, ob ihnen die Idee gefällt; aus Höflichkeit sagen alle ja. Es bedeutet, die kleinstmögliche Version echten Nutzern in einer echten Situation vorzulegen und zu beobachten, was sie tatsächlich tun. Ein klickbarer Prototyp, eine Landingpage, die Anmeldungen misst, eine manuelle 'Concierge'-Version, in der Sie die Automatisierung von Hand vortäuschen — jede davon sagt Ihnen mehr als eine fertige App, die auf einem Bauchgefühl beruht. Die Reihenfolge zählt: belegen Sie die Nachfrage günstig, dann bauen Sie teuer. Kehren Sie das um, und Sie können Ihr ganzes Budget dafür ausgeben, etwas zu polieren, das niemand ein zweites Mal öffnet.

Fehler 2: Ausufernder Umfang, als Ehrgeiz verkleidet

Jede App beginnt schlank und aufgeräumt. Dann fängt das 'wenn wir schon dabei sind' an. Wenn wir schon den Buchungsbildschirm bauen, könnte er auch Geschenkgutscheine verwalten? Und Treuepunkte? Und ein Empfehlungssystem? Jede Ergänzung klingt für sich genommen vernünftig. Zusammen verdreifachen sie still und leise Zeitplan und Rechnung — und schieben den Start so weit hinaus, dass der ursprüngliche Schwung erstirbt.

Die Lösung besteht nicht darin, gute Ideen abzulehnen. Es geht darum, sie zu parken. Führen Sie eine sichtbare 'Version-zwei'-Liste, auf der jede glänzende Idee auf ihren Einsatz wartet. Das bewirkt etwas Psychologisches und zugleich Praktisches: Menschen hören auf, darum zu kämpfen, Funktionen in die erste Version zu quetschen, sobald sie darauf vertrauen, dass es später einen echten Platz für ihre Idee gibt. Ihre erste Version sollte eine Sache wirklich gut machen, nicht zehn Sachen ausreichend. Eine App, die einen einzigen Arbeitsablauf perfekt beherrscht, wird genutzt. Eine App, die alles halbherzig macht, wird aufgegeben.

Fehler 3: Kein schriftliches Briefing — nur ein geteiltes Bild im Kopf

Dieser Fehler bleibt unsichtbar, bis er zubeißt. Der Inhaber hat eine klare App im Kopf. Der Entwickler hat eine klare App im Kopf. Alle nicken im Auftaktmeeting. Niemand schreibt es richtig auf — und die beiden Bilder waren, wie sich herausstellt, nie dasselbe Bild. Sie merken das auf halbem Weg, wenn das, was gebaut wird, nicht das ist, was Sie sich vorgestellt haben, und nun gibt es Streit darüber, wer was gesagt hat.

Sie brauchen keine hundertseitige Spezifikation. Sie brauchen ein paar Seiten, die jeder Neuling lesen und verstehen könnte: Wer nutzt diese App, was sind die drei oder vier Dinge, die sie damit tun müssen, wie sieht ein erfolgreiches Ergebnis aus. Fügen Sie eine grobe Skizze der wichtigsten Bildschirme hinzu. Das war's. Der Sinn des Briefings ist nicht Bürokratie — es ist eine gemeinsame Referenz, auf die Sie beide zeigen können, wenn Erinnerung und Wirklichkeit auseinanderdriften, was sie immer tun.

Fehler 4: Den Entwickler auf die falsche Art auswählen

Die meisten Inhaber wählen ihren ersten Entwickler nach einem von zwei dürftigen Signalen: dem niedrigsten Angebot oder einer persönlichen Empfehlung von jemandem aus einer anderen Branche. Beides kann durch Glück funktionieren. Keines ist eine verlässliche Methode, jemanden auszuwählen, dem Sie einen erheblichen Teil Ihres Geldes und mehrere Monate der Zukunft Ihres Unternehmens anvertrauen werden.

Das niedrigste Angebot ist in der Software besonders tückisch, denn die Kluft zwischen einem Angebot und den fertigen Kosten ist riesig und unsichtbar. Ein günstiger Entwickler, der drei Runden Nacharbeit braucht, für zwei Wochen verschwindet und Ihnen Code hinterlässt, den niemand sonst pflegen kann, ist weitaus teurer als ein etwas kostspieligerer, der es richtig macht. Der Preis ist das, was Sie sehen; die Gesamtkosten sind das, was Sie zahlen.

Was Sie tatsächlich prüfen sollten

Bitten Sie darum, Dinge zu sehen, die sie ausgeliefert haben und die noch laufen, und sprechen Sie, wenn möglich, mit diesen Kunden ohne den Entwickler im Raum. Fragen Sie, wie sie mit Änderungen mitten im Projekt umgehen, denn es wird Änderungen geben. Fragen Sie, wem der Code und die Konten gehören, wenn es fertig ist — die Antwort sollte immer Ihnen lauten. Und achten Sie darauf, ob sie gute Gegenfragen stellen. Ein Entwickler, der nur Befehle entgegennimmt, baut sehr effizient genau das Falsche. Die guten widersprechen, weisen auf Lücken in Ihrem Denken hin und behandeln das Briefing als Ausgangspunkt für ein Gespräch, nicht als feste Einkaufsliste.

Fehler 5: Die Entwicklung einplanen, den Rest vergessen

Eine App ist kein einmaliger Kauf wie eine gedruckte Broschüre. Sie ist ein lebendiges Ding, das gefüttert werden muss. Inhaber budgetieren regelmäßig nur die Entwicklung und nichts weiter, dann werden sie von den Kosten überrumpelt, die danach kommen: Hosting, App-Store-Gebühren, die Wartung, um mit den Updates der Handy-Betriebssysteme Schritt zu halten, und die unvermeidliche Runde an Korrekturen und kleinen Verbesserungen, sobald echte Menschen sie nutzen.

Eine vernünftige Faustregel: Was auch immer die Entwicklung kostet, legen Sie einen erheblichen Teil davon noch einmal für das erste Betriebsjahr zurück. Die genaue Zahl variiert, aber der Fehler ist universell — den Starttag als Ziellinie zu behandeln, obwohl er in Wirklichkeit die Startlinie ist. Die App, die startet und dann still und leise aufgegeben wird, weil kein Budget zur Wartung da ist, ist eines der traurigsten und häufigsten Ergebnisse in diesem ganzen Feld, und es lässt sich mit ehrlicher Planung im Vorfeld völlig vermeiden.

Fehler 6: Für sich selbst statt für Ihren Nutzer gestalten

Sie kennen Ihr Unternehmen in- und auswendig, was Sie zum denkbar schlechtesten Richter darüber macht, ob Ihre App leicht zu bedienen ist. Dinge, die für Sie offensichtlich sind — der Fachjargon, die Reihenfolge, in der Sie Aufgaben erledigen, die Abkürzungen, die Sie ohne nachzudenken nehmen — sind für einen Erstnutzer verwirrend. Eine App, die für den Inhaber vollkommen Sinn ergibt und alle anderen verwirrt, ist gescheitert, ganz gleich, wie clever sie ist.

Die Abhilfe ist günstig und ein wenig demütigend: Beobachten Sie echte Menschen bei der Nutzung, bevor Sie starten. Nicht Ihr Team, das schon weiß, wie es funktionieren soll — echte Kunden oder Mitarbeitende, die sie nie zuvor gesehen haben. Geben Sie ihnen die App, stellen Sie eine Aufgabe und sagen Sie nichts. Wo sie zögern, das Falsche antippen oder seufzen, das ist Ihr Design-Feedback. Fünf Personen reichen aus, um die schlimmsten Probleme ans Licht zu bringen. Diesen Schritt zu überspringen ist der Grund, warum Apps mit einem 'Senden'-Knopf ausgeliefert werden, den niemand findet, und einem Anmeldeablauf, der die Hälfte der Menschen verliert, die es versuchen.

• Geben Sie der Testperson eine echte Aufgabe, keine Führung — 'buchen Sie einen Termin für nächsten Dienstag', und bleiben Sie dann still.
• Beobachten Sie ihre Hände und ihr Gesicht, nicht nur, ob sie es am Ende schafft.
• Notieren Sie jedes Zögern; eine Pause ist ein Design-Problem, das Sie von innen nicht sehen können.
• Widerstehen Sie dem Drang zu erklären — wenn Sie es erklären müssen, hätte es die App tun sollen.
• Testen Sie mit fünf Personen, beheben Sie die offensichtlichen Fehler, dann testen Sie erneut.

Fehler 7: Native iOS- und Android-Apps bauen, obwohl es nicht nötig war

Es gibt einen Reflex, von Tag eins an eine 'richtige' App für iPhone und Android zu bauen, vollständig nativ, so wie es die großen Marken tun. Für die meisten kleinen Unternehmen bedeutet das das Zwei- bis Dreifache an Kosten und Komplexität für einen Nutzen, den Ihre Nutzer nie bemerken werden. Schlimmer noch, Sie pflegen nun für immer zwei getrennte Codebasen und verdoppeln jede künftige Korrektur.

Oft ist der richtige erste Schritt überhaupt keine native App. Eine gut gebaute Web-App, die im Browser jedes Handys funktioniert, oder ein plattformübergreifender Ansatz, der beide App-Store-Versionen aus einer Codebasis erzeugt, bringt Sie schneller und günstiger auf den Markt — und Sie können später jederzeit vollständig nativ gehen, wenn die echte Nutzung beweist, dass es sich lohnt. Die Frage lautet nie abstrakt 'nativ oder Web'. Sie lautet: Was ist das kleinste, günstigste Ding, mit dem echte Nutzer die Kernaufgabe erledigen können? Bauen Sie das, lernen Sie daraus, und geben Sie das große Geld dann mit Belegen statt mit Annahmen aus.

Fehler 8: Den Start als Ende der Arbeit behandeln

Der achte Fehler ist der Glaube, das Projekt sei fertig, wenn die App live geht. Ist es nicht — dann beginnt das eigentliche Projekt. Eine App ohne Plan, wie sie in die Hände der Nutzer gelangt, ohne Möglichkeit zu hören, was sie denken, und ohne Absicht, sie auf Basis der Erkenntnisse zu verbessern, ist eine App, die binnen Monaten verblasst. Die Entwicklung war der einfache Teil. Die Akzeptanz ist der schwierige Teil, und fast niemand plant dafür.

Bevor Sie starten, wissen Sie drei Dinge: Wie die Menschen erfahren, dass die App existiert, wie Sie messen, ob sie sie tatsächlich nutzen, und wie Sie das sammeln, was sie Ihnen sagen, damit die nächste Arbeitsrunde von der Wirklichkeit geleitet wird statt von Vermutungen. Nichts davon ist teuer. Es ist einfach eine andere Denkweise — die App ist kein Ding, das Sie fertigstellen und dann verlassen, sie ist eine Beziehung, die Sie pflegen. Die Inhaber, die das verstehen, bekommen Apps, die mit der Zeit nützlicher werden. Die, die es nicht verstehen, bekommen einen Spitzenwert am Starttag und einen langen, stillen Niedergang.

Wie Sie allen acht zugleich aus dem Weg gehen

Zusammen gelesen teilen diese Fehler eine einzige Wurzel: schnell auf Annahmen voranzugehen, statt langsam auf Belegen. Jeder von ihnen ist eine Stelle, an der es günstiger schien, den sorgfältigen Schritt zu überspringen. Und jeder von ihnen ist vor der Entwicklung weitaus günstiger zu handhaben als danach. Hier ist die Abfolge, die allen acht still und leise ausweicht.

1. 1
   Belegen Sie die Nachfrage, bevor Sie bauen

   Ein Prototyp, eine Landingpage oder eine manuelle Version. Beschaffen Sie sich echte Belege, dass jemand das will, bevor Sie das Budget festlegen.
2. 2
   Schreiben Sie das Briefing und die Version-zwei-Liste

   Ein paar klare Seiten, die jeder verstehen kann, plus ein Parkplatz für jede 'wenn wir schon dabei sind'-Idee, damit sie v1 nicht entgleisen lässt.
3. 3
   Wählen Sie den Entwickler nach Erfolgsbilanz, nicht nach Preis

   Ausgelieferte Arbeit, Referenzgespräche, klares Eigentum an Code und Konten, und jemand, der gute Gegenfragen stellt.
4. 4
   Budgetieren Sie das ganze erste Jahr, nicht nur die Entwicklung

   Hosting, Wartung, Korrekturen und Support. Der Starttag ist die Startlinie, finanzieren Sie also den Betrieb des Ganzen.
5. 5
   Wählen Sie die kleinste Plattform, die die Aufgabe erfüllt

   In den meisten Fällen zuerst Web oder plattformübergreifend. Gehen Sie später vollständig nativ, mit Belegen, nur wenn die Nutzung es verlangt.
6. 6
   Testen Sie mit echten Nutzern, dann planen Sie den Start

   Beobachten Sie fünf Fremde bei der Nutzung, beheben Sie die offensichtlichen Fehler und entscheiden Sie im Vorfeld, wie die Menschen sie finden und wie Sie die Nutzung messen.

Häufige Fragen