Da habe ich erstmal eine freche Frage zurück:

Was kostet ein Haus?

Ja, was kostet denn jetzt ein Haus?

Verstehe mich nicht falsch, ich will der Frage nicht ausweichen oder mich aus der Verantwortung ziehen. Ich will darauf aufmerksam machen, dass die Frage im ersten Moment noch nicht beantwortbar ist. Auch nach einem längeren Erstgespräch ist es höchstens möglich Kosten in „T-Shirt Größen“ S, M, L, XL zu geben. Sind es Größenordnungen von 5.000€ oder reden wir von 50.000€?

Nochmal zurück zum Haus. Nehmen wir mal an du hast dich zum ersten Mal mit einem Architekten getroffen und du willst eine Antwort auf die Kostenfrage haben, so wird dir der Architekt eine ähnliche Antwort geben. Bestenfalls ist eine Größenordnung schätzbar. Bei Häusern kann sich allerdings die „normale Person“ vorstellen was denn so Kostenpunkte sein können. Lage, Grundfläche, Isolation, Erdwärme, Fernwärme, Passiv-Haus, …

Mit den Innereien von Software hast du aber wahrscheinlich selten zu tun gehabt, daher ist es irgendwie unklar wie denn so Kosten zusammenkommen. Daher dieser Post mit den größten Fragen die die Kosten beeinflussen.

iOS? Android? Beides?

Im Artikel Nativ? Cross-Platform? Hybrid? habe ich es bereits angesprochen. Soll die App sowohl auf iOS als auch auf Android verfügbar sein, so reden wir eigentlich von zwei Projekten und nicht nur einem. Dieser Punkt alleine macht somit einen Faktor 2 bei den Kosten aus!

Werden Benutzerdaten zentral verwaltet?

Haben eure Benutzer ein Profil? Kann man sich registrieren? Oder kannst du (oder die Benutzer selber) Inhalte online verwalten, die dann in der App angezeigt werden? Falls ja, so ist in der App nicht nur ein Login-Mechanismus möglich, sondern es braucht auch ein Backend, bzw. einen Server, der Daten ausspielt. Dies ist ein weiteres eigenständiges Softwareprojekt. Je nach dem haben wir jetzt 2 oder sogar 3 Softwareprojekte. 1-2 App-Projekte und ein Backend, wobei die Apps jetzt auch noch eine Abhängigkeit zum Backend haben. Das bedeutet zusätzlich mehr Komplexität. Sowohl in Programmlogik als auch in der Projektplanung selber.

Qualität

Genau so wie man bei Handwerkern sparen kann und am Ende gestümpt wird, so kann man auch bei Software „Abkürzungen“ einlegen. Soll die App als Prototyp nur schnell auf den Markt geschmissen werden? Wenn ja, dann kann man sich Kosten sparen, weil die langfristige Entwicklung nicht bedenken muss. Je langfristiger das Projekt jedoch geplant ist umso mehr solltest du den Fokus auf Softwarequalität lenken. Genau wie bei einem Haus kann es dafür sorgen, dass du später viel, viel weniger Wartungs- und Reparaturkosten hast.

Design

Genügt es die iOS und Android Standardkomponenten zu benutzen ohne viel an Farben und Ausrichtung zu verändern? Oder soll hier und da schon Aufwand investiert werden um die App schön zu machen? Oder gibt es wirklich den Rundumschlag mit ausschließlich gestylten Elementen und animierten Übergängen bzw. Interaktionen? Eine weitere Frage ist wie sehr man auf unterschiedliche Konventionen zwischen Android und iOS eingehen will. Designs müssen ja erst erstellt werden bevor sie in Software gegossen werden können. Je mehr Unterschiede man zulässt umso zufriedener sind wahrscheinlich die Benutzer, nur müssen diese Unterschiede ja auch gebaut und bezahlt werden.

Mehrsprachigkeit

Ja, genau. Dies ist ein Thema, das gerne vergessen wird. Du hast dein Handy wahrscheinlich auf Deutsch eingestellt. Stellst du es auf Englisch um, so werden all die vorher deutschen Apps plötzlich auch englisch sein. Das zu bauen ist an sich nicht schwer, aber wo kommen die Übersetzungen her? Im besten Fall kann der Entwickler Deutsch und Englisch erledigen, aber der Rest muss wo anders her kommen. Ebenso muss mit jeder neu hinzugefügten Sprache ein Korrekturlauf durch die App erfolgen. Der Bildschirm hat nur begrenzt viel Platz und es passiert gerne, dass in anderen Sprachen plötzlich Texte deutlich länger sein können und das Layout kaputt geht. (Tipp: teste alle Features für jede Sprache auf mindestens zwei unterschiedlich großen Geräten. Meine Lieblingskombination um Fehler zu finden ist z.B. Französisch auf einem iPhone SE.) Jede Korrekturschleife kostet Zeit und somit Aufwand.

Wie ausgereift ist die Idee?

Mit dieser Frage will ich nochmal den Bogen zum Anfang des Artikels ziehen. Einerseits muss klar sein, dass eine unausgereifte Idee nicht nur einen Unsicherheitsfaktor darstellt, weil man nicht weiß wie viel noch „oben drauf“ gebaut werden muss“. Andererseits kann die Unsicherheit selber auch viele Kosten verursachen. Ist ein Feature erstmal gebaut, so wurde es gebaut. Der Aufwand wurde getätigt und bezahlt. Gibt es jetzt eine Planänderung, so muss entweder etwas umgebaut oder vielleicht sogar verworfen und anders neu gebaut werden. D.h. man hätte sich Aufwand sparen können wenn man das Konzept früher ausgereift hätte. Bedenke jedoch, dass selbst mit einer perfekt ausgereiften Idee Software nicht sicher geschätzt werden kann. Dies ist sogar ein Forschungsfeld von Universitäten und auch die haben noch keine Antworten wie man Software richtig schätzt.

Zusammenfassung

Ich hoffe ich konnte dir eine grobe Übersicht über die größten Fragen geben die Kosten eines App-Projektes bestimmen. Je weiter man versucht in die Zukunft zu schätzen umso schwieriger wird es. In einem anderen Artikel erwähnte ich bereits Agile Softwareentwicklung in diesem Kontext. Ist ein Projekt groß genug, dass es am Stück schwer einschätzbar ist, so kann es Sinn machen das Projekt in Teilabschnitte zu unterteilen. Diese kann man nacheinander angehen und so weit schätzen wie es im aktuellen Moment wirklich praktikabel ist. Hier ist, wie so oft, eine gute Kommunikation mit dem Entwickler nötig.

Artikel zum Anhören

Diesen Blogpost gibt es auch als Podcast zum hören:

Ja gut, wir setzen einfach einen Designer dran und gut ist… oder?

Wirklich? Kann der Designer deine Gedanken lesen? Er wird erstmal viele Fragen haben, genau so wie der Entwickler. Um die Zusammenarbeit mit dem Designer etwas zu vereinfachen habe ich eine Übung für dich, die dafür sorgt, dass du mit dem Designer konkrete Vorschläge zu besprechen hast.

Setze 4 Leute an einen Tisch und erzähle ihnen von deiner Idee bis alle ihre Fragen geklärt sind und gebe ihnen folgende Aufgabe:

• Malt die App auf ein Blatt Papier schematisch auf (grob, wirklich nur mit Strichen, nicht verkünsteln).
• Wie sieht die Startseite aus?
• Was passiert wenn ich auf folgenden Button drücke?
• Wie sieht die kommende Seite aus?
• Wie kann ich als Benutzer genau die Sache machen, die ich mit der App machen will?
• Wie sehen die Ansichten auf diesem Weg aus?

Wahrscheinlich hattest du einen Entwurf schon im Kopf wie du dir das Layout vorgestellt hast. Und wahrscheinlich ist dieser Entwurf höchstens Ansatzweise verstreut mal hier und mal da in Ansätzen der gezeichneten Layouts zu erkennen.

Meine Erfahrung sagt, dass keine einzelne Ansicht zwei mal gleich gezeichnet wird. Am Ende hat doch jeder eigene Vorstellungen und Ideen wie eine Sache am Besten dargestellt werden kann und das ist gut so. Das bedeutet nämlich, dass mehr Ideen auf dem Tisch sind und du aussortieren kannst.

Jetzt kannst du die besten Aspekte aus allen Entwürfen zu einem einzigen vereinen. Idealerweise solltest du jetzt noch einen oder mehrere potentielle Benutzer fragen wie sie die App benutzen würden, wenn sie den Entwurf vorgelegt bekommen. Das Feedback kannst du wieder in den Entwurf einfließen lassen.

Kommt ein simpler Entwurf raus, so kann es bereits genug für einen guten Entwickler mit einem Auge für Design sein um zumindest eine brauchbare App zu entwickeln. Ist es komplexer, so rate ich doch den Weg zum erfahrenen Designer. In beiden Fällen hast du konkrete Vorstellungen, die dir unnötiges vor und zurück mit vielen Vorschlägen und Gegenvorschlägen erspart.

Artikel zum Anhören

Diesen Blogpost gibt es auch als Podcast zum hören:

Ein Entwickler ist z.B. kein Designer. Ja das hört sich einleuchtend an, oder?

Interessanterweise kommt es trotzdem oft vor, dass Kunden davon ausgehen, dass der Entwickler das Design macht oder sogar auch Inhalte der App für Benutzer Europaweit in mehreren Sprachen erstellt und pflegt. Für einen Festpreis natürlich.

Aber wie? Mir wurde soeben zum ersten Mal von einem gewissen Problem einer bestimmten Zielgruppe erzählt und ich soll jetzt schon in der Lage sein das alles zu machen? Mal ganz vom Festpreis abgesehen.

Auf meine Rückfrage folgt immer eine kurze Stille am Telefon.

„Achso, stimmt, aber das ist ja ziemlich viel Aufwand, den ich dann habe.“

Ja eben. Darum geht es ja. Eine App ist ein Business, genau wie jedes andere auch. Es braucht für unterschiedliche Aufgaben unterschiedliche Leute und es kostet Aufwand.

Wie soll denn eine einzelne Person alle Bereiche gut abdecken können? Der Designer übernimmt den visuellen Part. Potentiell brauchst du wie bei einem großen Blog Leute, die den Inhalt für dich schreiben. Der Entwickler übernimmt den technischen Part für dich.

Mit technischem Part meine ich, dass er dafür sorgt, dass ein Design in Software gegossen wird. Dass die Benutzeroberfläche an Programmlogik geknüpft wird und in diesem Prozess auch beratend zur Seite steht. Er sorgt dafür, dass verfasst Inhalte in die App geladen werden. Er informiert dich, wenn er widersprüchliche Anforderungen gefunden hat (das passiert nicht selten, auch bei gut geplanten Projekten) oder sich Sachen vielleicht unerwartet als unklar herausstellen. Er wird dafür sorgen, dass die Software gut gebaut ist, d.h. dass sie möglichst leicht wartbar und erweiterbar ist. Er wird dich auch beraten können zu technischen Möglichkeiten, z.B. wenn ein Feature auf mehrere Arten und Weisen gebaut werden können mit unterschiedlichen Aufwänden und Vor- und Nachteilen. Auch ist er in der Regel ein Spezialist darin zu sehen ob eine Sache z.B. auf iOS oder Android gar nicht Konvention ist und ob man bei einer Platform doch lieber einen anderen Weg geht.

In anderen Worten: eine App ist in der Regel ein Geschäft, ein Business. In jedem Business ist es das gleiche: du brauchst jemanden, der dir Inhalte schreibt/aufnimmt/filmt. Du brauchst jemanden, der sich um das Marketing kümmert. Oder um Akquise. Oder, oder. oder. Die Aufgabenverteilung muss klar und sinnvoll sein.

Wir Entwickler mögen vielleicht Sachen bauen können, was sich für andere wie Magie anfühlen mag. Aber wir sind keine Zauberer und können somit auch vieles nicht so gut wie andere. Hier ist es für dich wichtig zu sehen wem du denn solche Aufgaben besser überlässt.

Artikel zum Anhören

Diesen Blogpost gibt es auch als Podcast zum hören:

Das ist wohl die Frage schlechthin, die aktuell bei jedem App-Projekt gefragt wird.

Aber erstmal ein Schritt zurück, damit wir alle verstehen was die Begriffe überhaupt genau bedeuten.

Android und iOS sind grundlegend andere Systeme, genau so wie macOS und Windows. Es ist irgendwie einleuchtend, dass eine iOS App nicht auf einem normalen Windows-PC installiert werden kann oder umgedreht. Ähnlich unterschiedlich sind iOS und Android in ihrer Funktionsweise und wie Apps für die beiden Platformen entwickelt werden. Das heißt, dass man für eine Smartphone-App erstmal zwei Apps entwickeln muss. Einmal die iOS Variante und einmal die für Android.

Da schluckt man, ja. Eine App ist nicht ein Projekt sondern eigentlich zwei. Doppelter Aufwand, doppelte Kosten.

Cross-Platform – Die Lösung?

Es gibt jedoch Ansätze die eine Lösung versprechen. Namentlich „Cross-Platform“ (Entwicklung über mehrere Platformen hinweg) und Hybrid (eine Webseite, die als App verpackt Zugriff auf Geräte-Funktionen wie GPS, Bluetooth etc. hat). Webseiten funktionieren offensichtlich sowohl auf iOS als auch auf Android ohne Unterschied, also ist dies eine beliebte Option eine einzelne App sowohl für iOS als auch für Android tauglich zu machen. Tools für diese zwei Optionen sind zum Beispiel Xamarin und Ionic.

„Ja wunderbar“, magst du dir denken, „das ist die Lösung!“

Der Haken an der Sache

Leider ist dies nicht so einfach. Hybrid-Apps fühlen sich oft nicht so wirklich wie Apps an. Irgendwas schwingt von Webseite im Benutzererlebnis mit. Ebenso sind meine persönlichen Erfahrungen mit Ionic zutiefst getrübt von Problemen mit Inkompatibilität, Unstabilität und mangelhafter Verlässlichkeit. Ein Gefühl, das mir bereits mehrere Male von Kollegen bestätigt wurde.

Ähnlich verhält es sich mit Cross-Platform Frameworks wie Xamarin. In der Theorie eine tolle Idee, in der Praxis stößt man jedoch oft auf Gegebenheiten, die man wieder für iOS auf die eine und für Android auf die andere Weise lösen muss… und schon hat man wieder an einer Stelle den Split. Dann kommt eine weitere Stelle hinzu und dann noch eine… Schnell wächst es zu einem Ungetüm, das wieder nichtmehr ganz so schön wartbar ist und doch wieder an vielen Stellen zwei Projekte verpackt in einem sind. Gewonnen hat man wenig, außer die Abhängigkeit zu einem Framework bei dem man wenig Einfluss hat, wenn mal Sachen nicht so funktionieren wie sie sollen.

Das ist meine Ansicht, die auch von mit mir befreundeten Entwicklern geteilt wird. Natürlich gibt es auch Entwickler die das anders sehen und ja da mag auch Geschmack mit reinspielen.

Unter‘m Strich bleiben folgende Fragen:

• Was ist das Ziel der App?
• Wie lange soll sie „leben“ und weiterentwickelt werden?
• Wie schnell muss sie auf den Markt geworfen werden?
• Kann danach mehr Zeit investiert werden um aus einem Prototypen eine saubere Version 2 zu entwickeln?

Ist der kurzfristige Zeitraum das entscheidende Kriterium so kann es trotz allen Nachteilen sinn machen sich für eine Cross-Platform- oder Hybrid-Lösung zu entscheiden. Aber bitte denke daran, dass, wie so oft, das dauerhafte Festhalten an kurzfristigen Lösungen dafür sorgt, dass nie langfristig geplant wird und man irgendwann in Schwierigkeiten rennt. In der Softwareentwicklung spricht man sogar von „technical debt“, also technischen Schulden, die irgendwann beglichen werden müssen. Irgendwann können diese Schulden so groß sein, dass sich wirtschaftlich eine komplette Neuentwicklung lohnt, selbst wenn die App „nur“ ein Jahr alt ist.

Ist der langfristige Zeitraum das entscheidende Kriterium so empfehle ich dringend eine native Lösung. Auf Dauer wird sich das rechnen und man ist flexibler und freier mit der Entwicklung, da man nicht von Limitierungen der Cross-Platform-Frameworks abhängig ist.

Artikel zum Anhören

Diesen Blogpost gibt es auch als Podcast zum hören:

Ja warum überhaupt?

Das frage ich dich als App-Entwickler. Ja, ich könnte froh sein, dass mehr Kunden mehr Apps wollen und jawohl das wäre mehr Geschäft Für mich.

Aber nein. Ein Entwickler ist eine Person die dich in der Umsetzung eines Software-Projektes berät. Und ein guter Entwickler denkt nach welche Technologie für den Einsatzzweck am meisten Sinn hat. Daher ist diese Frage wichtig.

Was willst du mit der App erreichen?

Gibt es Sachen, die die App können soll, die du mit einer Webseite nicht oder wenn überhaupt nur schwer erreichen kannst? Wenn Kernfunktionen der App einen dieser folgenden Punkte benötigt ist es ein gutes Zeichen, dass der Entwicklungsaufwand einer App gegenüber einer Webseite gerechtfertigt ist:

• Offline arbeiten
• App-Internes Speichern und verwalten von Daten
• Synchronisation der gespeicherten Daten in der App zwischen mehreren Geräten (z.B. iPhone und iPad)
• Empfangen von Push-Nachrichten
• Hintergrundaktivität wie z.B. Runter- & Hochladen von Dateien oder Abspielen von Musik wenn die App geschlossen ist
• Bluetooth
• GPS und Kompass
• Interaktion mit einer der Kameras
• Steuerung des Kamera-Blitzes
• Mikrofon
• Accelerometer (Beschleunigungsmessung, z.B. Schütteln des Smartphones) oder Gyroskop (Bestimmung des Neigungswinkels wie der Benutzer das Gerät hält)
• Zugriff auf Gesundheitsdaten (auf iOS: HealthKit)
• NFC
• Interaktion mit dem Sprachassistenten wie Hey Google und Siri

Ist deine App eine Ausnahme?

Es gibt jedoch auch viele Apps bei denen eigentlich, ganz nüchtern technisch betrachtet, auch keine App nötig gewesen wäre. In diesen Fällen hat man sich bewusst entschieden, dass sich der Entwicklungsaufwand rechnet oder lohnt. Z.B. News Apps fallen in diese Kategorie. Der Benutzer hat keine extra Personalisierung durch einen Login, alle Benutzer bekommen die gleichen Nachrichten angezeigt, die einfach aus dem Internet geladen werden. Keine spektakulären Funktionen, eigentlich würde eine Webseite vollkommen reichen. Hier ist die einzige Daseinsberechtigung der App der gewonnene Komfort. Bist du bereit Geld für diesen Komfort in die Hand zu nehmen?

Ist diese Frage beantwortet, so kann es weiter gehen. Ja, es wäre natürlich möglich eine App zu bauen in der letztendlich nur eine Webseite angezeigt wird. Dann hat der Benutzer ein App-Icon auf dem Homescreen und man hat kaum extra Entwicklungskosten. Jedoch lehnt Apple solche Apps ab und lässt sie (meiner Meinung nach zurecht) nicht in den App Store. Eine App soll sich wie eine App anfühlen. Das ist zumindest der Anspruch auf iOS. Google ist da sehr viel entspannter und auf Android kann man das machen. Die Frage ist natürlich ob eine solche App auch besonders gute Bewertungen bekommt und das ein gutes Licht auf das ganze Unterfangen wirft.

Der kühle Kopf sollte entscheiden

Oft sind Kunden mit einer App-Idee schon sehr darauf fokussiert, dass es eine App werden muss ohne sich um das „ja warum eigentlich?“ gekümmert zu haben. Mein Rat an jeden Kunden ist sich wirklich im gewissen zu sein warum das Investment eine gute Idee ist. Am Ende kostet die Entwicklung Geld. Würdest du gerne extra Geld ausgeben, wenn du wüsstest, dass du es hättest sparen können?

Artikel zum Anhören

Diesen Blogpost gibt es auch als Podcast zum hören: