Die erste Frage in einem Gespräch über eine neue App lautet fast nie, was sie kostet, sondern wann sie im Store steht. Die übliche Antwort darauf, irgendwo zwischen drei und sechs Monaten, hilft niemandem weiter, weil sie genau den Teil verschweigt, der Termine in der Praxis kippt. Deshalb rechnen wir hier zuerst offen vor, wie viele Wochen drei realistische Größen von Apps wirklich brauchen, und danach sprechen wir über die Konten, Formulare, Rechtstexte und Prüfregeln, die Apple und Google verlangen, bevor auch nur ein einziger Mensch Ihre App herunterladen darf.
Die kurze Antwort, in Wochen
Eine kleine App mit fünf bis acht Bildschirmen, einer einzigen Anmeldung und ohne Bezahlung im Inneren ist nach fünf bis acht Wochen fertig. Eine normale Geschäfts-App mit Benutzerkonten, Zahlungen, Benachrichtigungen und einem Verwaltungsbereich für Ihr Team braucht zwölf bis sechzehn Wochen. Eine Plattform mit mehreren Rollen, Live-Verfolgung auf der Karte, Chat und Anbindungen an fremde Systeme liegt bei sechs bis neun Monaten. Das sind keine Verhandlungspositionen, sondern die Spannen, die wir aus abgeschlossenen Projekten kennen.
Wichtig ist dabei, woher diese Zahl kommt, denn sie entsteht durch den Umfang und nicht durch Fleiß. Ein Team, das doppelt so schnell tippt, gibt es nicht, und mehr Entwickler auf dasselbe Stück Arbeit zu setzen, macht es meistens langsamer statt schneller, weil sich alle abstimmen müssen. Der einzige Hebel, der den Termin wirklich bewegt, ist also der Inhalt der App selbst: Wenn Sie früher starten wollen, muss etwas aus der ersten Fassung heraus, und wenn nichts heraus darf, bleibt das Datum, wo es ist.
Ehrlich gesagt beschreiben die meisten Kunden, die mit den Worten „eigentlich nur eine einfache App“ zu uns kommen, die mittlere Klasse und nicht die kleine. Das liegt daran, dass Benutzerkonten, Zahlungen und Push-Benachrichtigungen im Kopf wie ein einziger Punkt klingen, in Wirklichkeit aber drei getrennte Arbeitspakete sind, von denen jedes eigene Bildschirme, eigene Sonderfälle und eigene Tests mitbringt. Ein vergessenes Passwort, eine fehlgeschlagene Kartenzahlung, eine Benachrichtigung an ein Telefon, das drei Wochen aus war: Das sind die Dinge, die aus einer Woche zwei machen.
Alle drei Spannen setzen außerdem voraus, dass Entscheidungen pünktlich fallen, und genau diese Annahme scheitert am häufigsten. Ein Bauplan, der auf eine Freigabe wartet, ist teurer als eine schwierige Programmieraufgabe, und weil das so oft unterschätzt wird, widmen wir dem später einen ganzen Abschnitt mit konkreten Tagen.
Was eine kleine, eine normale und eine große App unterscheidet
Sie brauchen kein technisches Wissen, um Ihre eigene Idee einzuordnen, sondern nur drei Zählungen. Zählen Sie erstens die Bildschirme, also jede Ansicht, die sich sichtbar von der vorherigen unterscheidet, vom Anmeldefenster über die Terminliste bis zur Bestätigungsseite. Zählen Sie zweitens die Arten von Menschen, die sich anmelden, denn ein Kunde, ein Mitarbeiter und ein Fahrer sind drei verschiedene Apps in einer Hülle. Zählen Sie drittens die fremden Systeme, an die Sie andocken müssen, also Zahlungsanbieter, Buchhaltung, Warenwirtschaft, Kartendienst oder Versanddienstleister.
Ein Beispiel, das wir oft rechnen: eine Praxis möchte eine Termin-App. Patienten sehen freie Zeiten, buchen, bekommen eine Erinnerung und zahlen online, während Ärzte ihren Kalender pflegen, Termine verschieben und Notizen sehen. Das sind zwei Rollen und, wenn man sie ehrlich aufzeichnet, achtzehn bis zweiundzwanzig Bildschirme, also eindeutig eine normale App und keine kleine. Wer sie als kleine plant, plant nicht falsch herum, sondern rechnet mit acht Wochen für eine Sache, die vierzehn braucht, und verliert die Differenz später als Ärger.
Dazu kommt ein Punkt, den fast jede Anfrage übersieht: Der Verwaltungsbereich, in dem Ihre Mitarbeiter Inhalte pflegen, Preise ändern, Buchungen sehen und Kunden beantworten, ist ein zweites Produkt, das im ersten steckt. Er hat eigene Bildschirme, eigene Rechte und eigene Tests, und deshalb schlägt er in der Regel mit zwei bis drei zusätzlichen Wochen zu Buche. Wenn Sie wissen möchten, was ein vollständiger Bau alles umfasst, haben wir das unter Entwicklung mobiler Apps Schritt für Schritt beschrieben, inklusive der Teile, die auf keinem Bildschirm sichtbar sind.
Die fünf Phasen eines Projekts und was jede wirklich an Zeit kostet
Ein Projekt von vierzehn Wochen, also genau die Mitte der normalen Klasse, teilt sich in fünf Abschnitte auf. Zwei Wochen gehen in die Klärung und das schriftliche Konzept, drei Wochen in das Design der Oberfläche, sechs Wochen in das eigentliche Programmieren, zwei Wochen in Tests und Korrekturen und eine Woche in die Vorbereitung des Store-Eintrags samt Prüfung. Diese Aufteilung verschiebt sich von Projekt zu Projekt um einige Tage, doch das Verhältnis bleibt bemerkenswert stabil.
In der Klärungsphase passiert nichts, was hübsch aussieht, und trotzdem ist sie die Phase, die den Termin rettet. Wir listen jeden Bildschirm auf, schreiben jede Regel hin, die später jemand programmieren muss, und beantworten die unangenehmen Fragen früh: Was passiert, wenn ein Patient zwei Minuten vor dem Termin absagt, wer darf einen Preis ändern, was sieht ein Nutzer ohne Konto. Wird das übersprungen, erfindet in Woche neun jemand mitten im Bau eine Entscheidung, und eine Entscheidung, die während des Programmierens fällt, kostet ungefähr das Fünffache derselben Entscheidung auf Papier.
Aus demselben Grund muss das Design fertig sein, bevor der Bau beginnt. Eine Zeichnung zu ändern kostet Stunden, denselben Bildschirm nach dem Programmieren umzubauen kostet grob das Dreifache, weil an ihm inzwischen Daten, Regeln und Nachbarbildschirme hängen. Wer also mitten in Woche acht sagt, dass die Startseite doch anders aussehen soll, zahlt nicht für eine Meinung, sondern für Abriss und Neubau.
Wohin die Stunden tatsächlich fließen, und warum das Programmieren nicht einmal die Hälfte ist
Wenn man den gesamten Aufwand eines solchen Projekts aufteilt, entfallen rund 45 Prozent auf das Programmieren, 18 Prozent auf Tests und Fehlerkorrekturen, 15 Prozent auf Design, 12 Prozent auf die Anbindung fremder Systeme wie Zahlungsanbieter oder Lieferdienste und 10 Prozent auf die Store-Vorschriften und den Papierkram bei der Einreichung. Anders gesagt: Mehr als die Hälfte der bezahlten Arbeit ist etwas anderes als Programmieren, und wer nur den Bau bezahlt, hat kein günstiges Angebot bekommen, sondern ein unvollständiges.
Was Tests in der Praxis bedeuten, lässt sich ohne Fachsprache erklären: Dieselbe App muss sich auf einem vier Jahre alten Android-Telefon mit gesprungenem Display genauso vernünftig verhalten wie auf dem neuesten iPhone. Zwischen diesen beiden Polen liegen Dutzende Kombinationen aus Bildschirmgröße, Systemversion, Speicherplatz und Verbindungsqualität, und jede davon kann eine eigene Macke haben. Ein Formular, das auf einem schmalen Display abgeschnitten wird, ist kein Schönheitsfehler, sondern ein verlorener Kunde.
Genau deshalb ist es eine Milchmädchenrechnung, die zwei Testwochen zu streichen, um vierzehn Tage früher zu starten. Ein Absturz am Starttag kostet Sie Bewertungen mit einem Stern, die monatelang oben stehen bleiben, dazu Rückerstattungen, Supportanrufe und eine Notfallkorrektur, die selbst wieder durch die Prüfung muss. Die gesparte Woche kommt also zurück, nur teurer und mit Publikum.
Was Apple und Google verlangen, bevor sie irgendetwas veröffentlichen
Am Anfang stehen zwei Konten, und beide sollten auf den Firmennamen laufen und nicht auf das private Konto einer Mitarbeiterin, die in zwei Jahren vielleicht nicht mehr da ist. Das Apple Developer Program kostet 99 US-Dollar im Jahr und muss jedes Jahr verlängert werden, sonst verschwindet Ihre App aus dem Store. Die Google Play Console kostet einmalig 25 US-Dollar und bleibt danach ohne Grundgebühr bestehen.
Ein Firmenkonto verlangt zusätzlich eine sogenannte D-U-N-S-Nummer, also eine internationale Kennnummer für Unternehmen, dazu Nachweise, dass Ihre Firma wirklich existiert und dass die anfragende Person für sie handeln darf. Diese Prüfung dauert nach unserer Erfahrung drei bis vierzehn Tage, läuft komplett außerhalb Ihres Einflusses und lässt sich am ersten Projekttag anstoßen. Wer sie auf die letzte Woche schiebt, wartet am Ende mit einer fertigen App auf ein Formular.
Dazu kommt Papierkram, auf dem beide Stores bestehen. Sie brauchen eine Datenschutzerklärung, die auf Ihrer eigenen Website öffentlich erreichbar ist, einen ausgefüllten Fragebogen zu den Daten, die Ihre App sammelt, eine Altersfreigabe und eine echte Kontaktmöglichkeit für Support. Der Fragebogen ist der Punkt, an dem gern geraten wird, und das ist gefährlich, weil die Antworten mit dem übereinstimmen müssen, was die App tatsächlich speichert und weitergibt. Wir gehen ihn deshalb gemeinsam mit dem Team durch, das die Datenwege kennt, und wenn dabei auffällt, dass mehr gespeichert wird als nötig, gehört das in die Arbeit, die wir unter Cybersicherheit beschreiben, und nicht in eine geschönte Antwort.
Zwei Regeln erwischen fast jeden beim ersten Mal. Wenn Nutzer in Ihrer App ein Konto anlegen können, müssen beide Stores auch einen Weg sehen, dieses Konto wieder zu löschen, und zwar aus der App heraus und nicht per Anruf im Büro. Und wenn Sie eine Anmeldung über Google oder Facebook anbieten, verlangt Apple in aller Regel zusätzlich die Anmeldung mit dem eigenen Apple-Konto. Beides sind kleine Bauteile, wenn man sie einplant, und teure Nachrüstungen, wenn sie erst in der Ablehnung auftauchen.
Für den europäischen Markt kommt noch die Pflicht hinzu, Ihre Händlerdaten anzugeben und veröffentlichen zu lassen, also Firmenname, Anschrift, Telefonnummer und E-Mail. Fehlt diese Angabe, wird die App nicht abgelehnt, sondern in den europäischen Ländern schlicht ausgeblendet, und das ist noch unangenehmer, weil alles funktioniert und trotzdem niemand Ihre App findet.
Der Store-Eintrag selbst, den niemand einplant
Der Eintrag ist kein Formular, das man in einer Stunde ausfüllt, sondern ein kleines Werbeprojekt mit festen Maßen. Sie brauchen ein quadratisches App-Symbol mit 1024 Pixeln Kantenlänge, Bildschirmfotos für jede verlangte Telefon- und Tabletgröße mit bis zu zehn Bildern je Größe, für Google Play zusätzlich eine Titelgrafik mit 1024 mal 500 Pixeln, einen Kurztext von etwa 80 Zeichen und eine ausführliche Beschreibung von bis zu 4000 Zeichen, dazu die bereits erwähnte Datenschutzerklärung auf Ihrer eigenen Website.
Das alles ordentlich zu schreiben, zu fotografieren und zuzuschneiden dauert drei bis fünf Arbeitstage, und ein guter Teil davon ist Ihre Arbeit und nicht unsere, weil Ihre Worte die App verkaufen und nicht unsere. Der erste Satz Ihres Kurztextes entscheidet in der Suche darüber, ob jemand überhaupt weiterliest, weshalb dieser Satz nicht am letzten Freitag vor dem Start zwischen Tür und Angel entstehen sollte.
Ein Detail, das erstaunlich viele Starts kostet, ist das Prüfkonto. Wenn Ihre App eine Anmeldung hat, müssen Sie Apple und Google funktionierende Zugangsdaten mitgeben, mit denen ein Prüfer alles sieht, auch die Bereiche hinter einer Bezahlung oder einer Freischaltung. Ein fehlendes, abgelaufenes oder unvollständig berechtigtes Prüfkonto ist einer der häufigsten Ablehnungsgründe überhaupt, und es ist zugleich der ärgerlichste, weil er nichts mit der Qualität Ihrer App zu tun hat.
Beruhigend ist immerhin, dass sich Texte und Bilder im Store später jederzeit ändern lassen, ohne dass die App neu geprüft wird. Ein guter Eintrag zum Start muss also nicht perfekt sein, sondern ehrlich, verständlich und vollständig, und die Feinarbeit an Formulierungen und Bildschirmfotos passiert danach ohnehin anhand echter Zahlen.
Wie lange die Prüfung dauert, und warum Apps abgelehnt werden
Die meisten Einreichungen bei Apple kommen innerhalb von 24 bis 48 Stunden zurück, was viele Menschen überrascht, die noch von wochenlangen Wartezeiten gehört haben. Eine brandneue App auf einem brandneuen Konto braucht allerdings öfter zwei bis fünf Tage, weil zusätzlich das Konto selbst betrachtet wird. Bei Google Play kann die erste Veröffentlichung eines neuen Kontos bis zu sieben Tage dauern, während spätere Aktualisierungen meist innerhalb weniger Stunden durchlaufen.
Eine Regel überrascht fast jeden, der zum ersten Mal veröffentlicht: Ein neu angelegtes persönliches Google-Play-Konto muss in der Regel zuerst einen geschlossenen Test fahren, an dem mindestens zwölf Tester durchgehend vierzehn Tage lang angemeldet sind, bevor die App öffentlich sichtbar werden darf. Das sind zwei zusätzliche Wochen, die in keinem Bauplan stehen, und sie sind der Grund, warum wir am ersten Projekttag nach den Namen und E-Mail-Adressen der Testpersonen fragen und nicht am Ende.
Ehrlich gesagt kommt nach unserer Erfahrung ungefähr jede dritte Ersteinreichung mit mindestens einer Anmerkung zurück. Das ist kein Drama und kein Zeichen für schlechte Arbeit, sondern der Normalfall, denn ein Prüfer sieht die App zum ersten Mal und ohne jede Vorgeschichte. Wichtiger als die Vermeidung ist der Umgang damit, und die Runde aus Korrektur und erneuter Einreichung dauert typischerweise zwei bis fünf Tage.
Die Anmerkungen wiederholen sich dabei erstaunlich oft, weshalb sie sich vorher abhaken lassen:
- Die App stürzt auf dem Gerät des Prüfers ab, häufig auf einer älteren Systemversion oder bei schlechter Verbindung.
- Das Prüfkonto fehlt, ist abgelaufen oder sieht nicht alle Bereiche der App.
- Die Antworten im Datenschutzfragebogen passen nicht zu dem, was die App tatsächlich sammelt.
- Es gibt keinen Weg, ein angelegtes Konto in der App wieder zu löschen.
- Digitale Inhalte werden am Store vorbei abgerechnet, obwohl beide Anbieter dafür ihre eigene Bezahlung verlangen.
Die Verzögerungen, die wir am häufigsten sehen, und was jede kostet
Ganz oben steht regelmäßig die Freigabe des Händler- und Zahlungskontos mit rund vierzehn Tagen, weil Ihre Bank oder Ihr Zahlungsanbieter Unterlagen prüft, die niemand im Projekt beschleunigen kann. Nachträglich hinzugefügte Funktionen kosten im Schnitt zwölf Tage, das Warten auf Fotos und Texte des Kunden etwa zehn, die Identitätsprüfung des Entwicklerkontos rund neun, und eine einzelne Ablehnung mit anschließender Neueinreichung schlägt mit ungefähr vier Tagen zu Buche. Auffällig ist, dass drei dieser fünf Punkte am ersten Projekttag erledigt werden könnten.
Damit klar wird, warum wir bei offenen Fragen so hartnäckig nachhaken, hier die Rechnung ohne Beschönigung: Ein Team aus drei Personen, das eine Woche auf eine Antwort wartet, verbraucht fünfzehn bezahlte Arbeitstage, an deren Ende nichts fertig ist. Eine unbeantwortete E-Mail kann also der teuerste Posten eines ganzen Projekts sein, und sie taucht in keinem Angebot auf.
Dazu kommt ein Effekt, der sich leise summiert. Jede kleine Zusatzfunktion mitten im Bau kostet ungefähr anderthalb bis drei Arbeitstage, sobald man Design, Programmierung, Tests und das erneute Prüfen der umliegenden Bildschirme zusammenrechnet, denn eine App ist ein Netz und kein Stapel. Fünf solcher „ist doch schnell gemacht“-Wünsche sind damit zwei Wochen, und weil sie einzeln nie nach zwei Wochen aussehen, merkt man es erst am Kalender.
Ein Code oder zwei, und was diese Wahl mit Ihrem Termin macht
Plattformübergreifende Entwicklung heißt schlicht, dass ein einziger Satz Programmcode geschrieben wird, aus dem sowohl die iPhone- als auch die Android-App entsteht. Das spart typischerweise 25 bis 35 Prozent der Bauwochen gegenüber dem Weg, beide Apps getrennt zu schreiben, und es spart später jedes Mal wieder etwas, wenn eine Änderung nur an einer Stelle gepflegt werden muss statt an zweien.
Es gibt Fälle, in denen der längere Weg richtig ist, und wir sagen das auch. Wenn Ihre App Video oder Kamera in großem Stil verarbeitet, wenn sie den Standort dauerhaft im Hintergrund verfolgen soll, wenn sie tief in die Hardware des Telefons greift oder wenn es sich um ein Spiel handelt, dann lohnt sich die getrennte Entwicklung, weil dort jedes Prozent Leistung sichtbar wird.
Für so gut wie alle Buchungs-, Bestell-, Mitglieder-, Liefer- und internen Betriebs-Apps ist der plattformübergreifende Weg dagegen die richtige Antwort, und bei Linkysoft sagen wir das auch dann, wenn der längere Weg für uns mehr Wochen und damit mehr Umsatz bedeuten würde. Ein Angebot, das Ihnen ohne besonderen Grund zwei getrennte Apps verkauft, verkauft Ihnen vor allem Zeit.
Eines ändert diese Entscheidung allerdings überhaupt nicht: Sämtliche Store-Anforderungen aus diesem Artikel gelten in beiden Fällen unverändert. Konten, Datenschutzfragebogen, Prüfkonto, Bildschirmfotos und Prüfzeiten kennen den Unterschied nicht, weshalb die Technikwahl den Papierkram niemals verkürzt.
Wann ein kleinerer Start wirklich die bessere Entscheidung ist
Manchmal lautet die ehrlichste Antwort, dass Sie noch gar keine App brauchen. Wenn Ihr Vorhaben im Kern darin besteht, Informationen zu zeigen und eine Buchung oder Anfrage entgegenzunehmen, dann erreicht eine schnelle, für Telefone gebaute Website jedes Gerät innerhalb von Tagen statt Monaten, kostet einen Bruchteil und braucht keine einzige Freigabe von Apple oder Google. Wie so etwas aussieht, zeigen wir unter Webdesign und Entwicklung, und in vielen Fällen ist es der Schritt, der zuerst Geld verdient.
Der zweite gangbare Weg ist ein kleinerer erster Start. Aus zweiundzwanzig geplanten Bildschirmen werden neun, aus fünfzehn Wochen werden sieben, und die übrigen Funktionen kommen dann, wenn echte Nutzer gezeigt haben, welche davon sie überhaupt anfassen. Wir haben schon Listen gesehen, in denen ein Drittel der aufwendig gebauten Funktionen nach drei Monaten praktisch ungenutzt war, und dieses Drittel war teuer.
Der eigentliche Gewinn einer ersten Ausbaustufe ist deshalb kein gesparter Betrag, sondern Wissen. Sie hören auf, aus Vermutungen zu bauen, und fangen an, echtes Verhalten zu beobachten: welche Bildschirme angesehen werden, wo Menschen abbrechen, welche Funktion in jedem zweiten Supportgespräch verlangt wird. Wie sich solche Entscheidungen in fertigen Projekten ausgezahlt haben, können Sie in unseren Fallstudien nachlesen.
Was Sie heute beginnen können, um Ihren Termin zu schützen
Einiges davon lässt sich anstoßen, bevor überhaupt eine Zeile Code existiert, und genau diese Punkte entscheiden später über Ihren Start:
- Legen Sie beide Store-Konten auf den Firmennamen an, heute und nicht in Woche zehn, damit die Identitätsprüfung im Hintergrund laufen kann.
- Stellen Sie eine Datenschutzerklärung und eine Supportseite auf Ihre eigene Website, denn beide Stores verlangen eine dauerhaft erreichbare Adresse dafür.
- Benennen Sie eine einzige Person, die eine Entscheidung innerhalb eines Arbeitstages verbindlich treffen darf, statt drei, die sich abstimmen müssen.
Parallel dazu sammeln Sie die Inhalte, und zwar früher, als es sich anfühlt. Gemeint sind echte Fotos statt Platzhalter, echte Produkt- oder Leistungsbeschreibungen, die genauen Formulierungen für Preise, Fristen, Stornoregeln und Geschäftsbedingungen. Diese Texte müssen ohnehin geschrieben werden, und ob das im ruhigen ersten Monat passiert oder unter Zeitdruck im letzten, ändert nichts am Aufwand, aber viel am Ergebnis.
Und starten Sie in der ersten Woche den Antrag beim Zahlungsanbieter samt aller Bankunterlagen. Diese Freigabe dauert üblicherweise ein bis drei Wochen, sie liegt vollständig außerhalb der Kontrolle aller Beteiligten, und sie ist erfahrungsgemäß der Punkt, an dem eine ansonsten fertige App auf ein Dokument wartet.
Nach dem Start: die ersten neunzig Tage und die jährlichen Fristen
Rechnen Sie im ersten Monat mit zwei bis vier kleinen Aktualisierungen, und werten Sie das bitte als gutes Zeichen. Echte Nutzer tun Dinge, auf die kein Testteam kommt: Sie drehen das Telefon mitten in einem Formular, tippen zweimal auf „Bezahlen“, verlieren im Aufzug die Verbindung. Eine App, die in den ersten dreißig Tagen kein einziges Mal angefasst wird, ist meistens keine perfekte App, sondern eine, die niemand benutzt.
Danach beginnt ein Rhythmus, der jedes Jahr gleich läuft. Im Herbst erscheinen die neuen Telefonsysteme, und in den Monaten darauf heben Apple und Google die Mindestversionen an, gegen die eine App gebaut sein muss. Eine App, die ein Jahr lang unberührt bleibt, kann dadurch an den Punkt kommen, an dem sich nicht einmal mehr eine kleine Korrektur einreichen lässt, ohne vorher technische Grundlagen nachzuziehen, und diese Nachrüstung kostet dann ein Vielfaches der laufenden Pflege.
Als Faustregel fürs Budget planen Sie pro Jahr etwa 15 bis 20 Prozent der Baukosten für Wartung, Hosting, Store-Gebühren und kleine Verbesserungen ein. Das ist keine Strafgebühr, sondern der Preis dafür, dass die App in zwei Jahren noch installierbar ist, und er ist deutlich niedriger als ein Neubau nach drei Jahren Stillstand.
Wenn Sie möchten, setzen wir uns Ihre konkrete Idee einmal durch: Bildschirme zählen, Rollen benennen, Anbindungen prüfen, daraus ein realistisches Startdatum ableiten und die Konten sowie Anträge markieren, die noch diese Woche beginnen sollten. Schreiben Sie uns dafür über die Kontaktseite, und egal, wer Ihre App am Ende baut: Lassen Sie sich den Terminplan mit den Store-Wochen darin zeigen und nicht nur die Bauwochen. Genau daran erkennt man, ob jemand schon einmal veröffentlicht hat, und deshalb steht bei Linkysoft die Prüfung mit im Plan und nicht dahinter.
