Bei Webseiten nimmt man ein Theme, passt es an, befüllt es mit Inhalt, fertig. Themes für Apps gibt es nicht. Und weil es in der Regel nicht um das reine Anzeigen von Inhalten geht, sondern darum, dass der Benutzer etwas tut, steht zuerst eine entscheidende Frage: Was genau soll er mit der App tun? Wirklich genau.
Konzeption
Was nach einer selbstverständlichen Phase klingt, wird erstaunlich oft übersprungen oder nur oberflächlich behandelt. Nur weil eine Person die Idee versteht, heißt das nicht, dass sie sie einem Entwickler so klar erklären kann, dass er sie danach umsetzen kann.
Ein Entwickler wird jede Funktion einzeln bauen, in Logik gießen und mit einer Benutzeroberfläche überziehen. Das funktioniert nur, wenn er wirklich versteht, was gebaut wird, wie die Teile verzahnt sind und warum es so sein muss und nicht anders.
Das erfordert Arbeit. Im Gegenzug sparst du dir lange Diskussionen während der Entwicklung. Und es verhindert, dass der Entwickler Lücken im Konzept nach seiner Auffassung füllt anstatt nach deiner. Passiert das, entstehen Richtungswechsel mitten im Projekt, Umbauten, unnötige Kosten. Der Grund ist fast immer derselbe: das Konzept stand auf wackeligen Beinen.
Bonus: ein guter Entwickler merkt, wenn du vorbereitet bist. Er sucht sich Projekte mit ernstem Hintergrund und eine gute Vorbereitung ist ein klares Signal.
Planung: Wasserfall vs. iterativ
Früher hat man versucht Softwareprojekte von Anfang bis Ende durchzuplanen. Anforderungen, Entwurf, Entwicklung, Prüfung, Wartung. Nach vielen gescheiterten Großprojekten musste die Branche zugeben: Das funktioniert nicht. (Z.B. die LKW-Maut war so ein Projekt.)
Keine komplexe Software kann am Anfang fertig definiert werden. Unsicherheiten multiplizieren sich mit der Zeit, Deadlines verschieben sich, Kosten explodieren.
Der bessere Ansatz ist iterativ, oder auch agil. Das Endkonzept muss stehen, aber man startet mit dem kleinsten sinnvollen Teil: einem MVP. Man baut einen kleinen Abschnitt, findet früh heraus was unklar ist, baut den nächsten. Viele Entwickler arbeiten in sogenannten Sprints, zum Beispiel in 2-Wochen-Abschnitten. So weiß der Kunde was passiert, bekommt regelmäßig Testversionen und Probleme werden nicht aufgeschoben.
Design
Design und Entwicklungsplanung sollten ungefähr gleichzeitig starten, aber es sind zwei paar Schuhe. Ein Entwickler ist in den seltensten Fällen auch ein Designer. Es gibt keine Templates, keine Themes. Du hast als Kunde wahrscheinlich eine Vorstellung im Kopf, wie es aussehen soll. Diese Vorstellung muss konkret werden.
Erst mit einem Konzept und einem UI-Layout wird ein erfahrener Entwickler eine realistische Aussage über Aufwände und Kosten machen. Selbst vermeintliche Kleinigkeiten können plötzlich mehrere Tage Arbeitszeit kosten.
Entwicklung
Jetzt geht es los. Am Anfang kann sich der Fortschritt langsam anfühlen. Das ist normal. Ein guter Entwickler nimmt sich zuerst Zeit für technische Entscheidungen, die nach außen wenig sichtbar sind, aber langfristig viele Probleme vermeiden.
Ein wichtiger Punkt: Je öfter du mitten in der Entwicklung Feedback gibst, desto mehr wirst du den Entwickler von seiner eigentlichen Arbeit abhalten. Die kritische Frage ist immer, ob das Feedback jetzt sofort dringend ist, oder ob es wichtiger wäre zuerst die geplanten Aufgaben abzuschließen. Fokus ist das A und O.
Release
Kurz vor der Veröffentlichung noch einmal alles durchchecken: Bugs, Design, Texte, Funktionen. Dann geht es zu Apple oder Google.
Wichtig für iOS: Apple hat einen Review-Prozess. Eine eingereichte App landet nicht sofort im App Store, sondern braucht 1–3 Tage. Das gilt auch für Updates. Und: über die Weihnachts- und Neujahrszeit ist Apples Verwaltungsplattform geschlossen. Schafft man den Release nicht bis Anfang Dezember, dann lieber die Zeit zum Polieren nutzen und danach ohne Risiko live gehen.
Wartung
Keine App ist von Anfang an fertig. Fehler werden gefunden, Funktionen weiterentwickelt. Das ist die Regel, nicht die Ausnahme und diese Phase dauert meist deutlich länger als die eigentliche Entwicklung.
Ein guter Entwickler baut Software so, dass sie möglichst leicht wartbar ist. Wer beim Fundament gespart hat um schnell releasen zu können, zahlt das später. Neue Features werden schwieriger, alte Features brechen, jeder Bugfix kann neue Bugs erzeugen. Ich habe bereits Projekte von anderen Entwicklern übernommen, die nicht mehr zu retten waren. In solchen Fällen musste Version 2 von Grund auf neu gebaut werden.
Sieh so ein Projekt wie ein Puzzle: nur du kannst die Teile sehen, nur der Entwickler kann sie bewegen. Je besser ihr euch versteht, desto zügiger geht es voran.