Was kostet eine App? Teil 2: Kostenoptimierung & Einflussfaktoren

Übersicht über App-Entwicklungsphasen

Ein kompletter App-Entwicklungsprozess umfasst mehr als nur Design und dessen Umsetzung in Code. Er umfasst verschiedene Phasen und Iterationen, die sich jeweils untereinander beeinflussen. In unserer Betrachtung konzentrieren wir uns auf die Entwicklungsphase selbst als Einflussfaktor auf das Gesamtbudget (siehe Markierung im Bild). Eine klare Übersicht über diesen Teilbereich erlaubt es, die Mittel für jede Phase besser zuzuordnen.

Entwicklungsphasen und ihr Einfluss auf das App-Budget. Beispielprojekt aus Teil 1: Was kostet eine Appentwicklung

Unsere App-Kostenbeispiele aus Teil I verdeutlichen, dass der Preis selbst bei gleichbleibenden Stundensätzen von Projekt zu Projekt sehr unterschiedlich ausfallen kann. Gerade in der ersten Phase des Projektentwicklungszyklus machen die Arbeitsstunden den Hauptteil des Gesamtpreises aus. Die tatsächlich verbrauchte Stundenanzahl der Entwickler:innen wird multipliziert mit einem vorab vereinbarten Stundensatz. Hinzu kommen etwa Maintenance-Kosten, externe Dienste wie Datenspeicherung, Hosting und Wartung.

Hourly-Rate-Rechnung

Ist nun der Stundensatz der beteiligten Vendors (z.B. Projektmanagement, UX/UI Design und IT) das entscheidende Stellrädchen? Ja und nein: Ließe man ein und dieselbe App unter ansonsten gleichen Bedingungen einmal durch einen Konzern mit Sitz im Silicon Valley und einmal mit einen lokalen Mittelständler in Schwaben umsetzen, so ließe sich durchaus einen Preisunterschied feststellen. Doch der Stundensatz ist nicht alles. Die folgenden Variablen nehmen ebenso Einfluss darauf, wie agil und produktiv ein Entwicklungsteam in der Zusammenarbeit sein wird:

• Teamzusammensetzung und -Dynamik (Teamgröße, Aufstellung Inhouse-Entwicklungsteam, Freelancer, IT-Dienstleister...)
• Erfahrung der beteiligten Stakeholder:innen, Designer:innen und Entwickler:innen
• Bestehende agile Workflows im Team (Vertrautheit mit SCRUM-Methoden, Rollenaufteilung, gute Besetzung des:r Product-Owner:in, Stakeholder-Integration)
• Bestehende Entwicklungsumgebung und -Stand (z.B. muss eine bestehende (Backend-)Infrastruktur integriert oder angepasst werden? Wie ausgereift ist das bestehende Testing-Environment? Wie viel Code muss gerefactored werden?)
• Bestehendes UX/UI (wie konkret ist das Konzept? Gibt es Wireframes oder fertige UI-Designentwürfe? Soll das Design maßgefertigt sein oder können Templates verwendet werden?
• Geplanter Funktionsumfang und Featurereichtum
• Plattformanforderungen (iOS, Android) und Benutzeroberflächen (speziell im Bereich IoT), vereinbarte Anforderungen wie Geräte-, Browser-, Accessibilityvorgaben

Diese Variablen beeinflussen die Produktivität bisweilen enorm. Daher ist es sinnvoll, an erster Stelle diese Faktoren unter die Lupe zu nehmen, sie kritisch zu prüfen und immer wieder zu optimieren – vor und während der Entwicklungsphase.

Wie kann man die Entwicklung nun erleichtern und beschleunigen? Wie erreicht man es, schnell in der Lage zu sein, ein nutzungsorientiertes Produkt zu bauen? An dieser Stelle gibt das agile Dreieck einen guten Überblick. Es ist wertvolles Planungsinstrument und visualisiert die Zielvorgaben bei Softwareprojekten.

Das Modell des agilen Dreiecks zeigt die drei Parameter auf, die ein Softwareprojekt und dessen Erfolg bestimmen. Das Projekt wird aufgespannt in ein "Dreieck" zwischen den drei Polen Budget, Terminierung und Featurereichtum/Solidität. Alle drei Größen sind im Softwareprojekt von Interesse. Sie stehen miteinander in einem Zusammenhang und beeinflussen sich durch gegenseitige Trade-Offs. In der agilen Softwareentwicklung werden meist die ersten beiden Pole vorab festgelegt, der variablere Faktor ist die Komponente Featurereichtum/Solidität. Beispiel: Der Kostenrahmen für die Entwicklung eines neuen Prototypen ist gedeckelt und auch das Datum des Go-Lives wird auf ein bestimmtes Datum fixiert. Sind Budget und Zeitrahmen begrenzt, bleibt nur noch eine Ecke aus dem magischen Dreieck übrig – der Featureumfang, der variabel angepasst werden kann. Diese Anpassungsfähigkeit macht ja gerade ein wichtiges Prinzip agiler Arbeit aus: Stimmen alle Voraussetzungen, bleiben Entwicklungsteams und Stakeholder reaktionsfähig, können sich auf Veränderungen einstellen und umso größeren Mehrwert für ihre Nutzer:innen schaffen.

Features, die in der Entwicklung oft aufwändiger sind

Unter Punkt 1 haben wir Abhängigkeitsfaktoren bestimmt, die die Produktivität ganz allgemein beeinflussen: Entwicklungsressourcen, Komplexität der App, Plattform-Constraints etc. Nun nehmen wir speziell den Featureumfang in den Blick. Denn in jeder Aufwandsschätzung können konkrete Features ausgemacht werden, die aus Entwicklungssicht zeitintensiv und daher tendentiell aufwändiger sind. Diese Requirements gehen oftmals mit höherem Aufwand einher:

• Vielschichtige Nutzersysteme und Rollen
• Browserkompatibilität (sollen z.B. noch ältere Safari-Versionen unterstützt werden?)
• Stark individualisierte UI
• Native Entwicklung für jede Plattform
• Internationalisierung/Lokalisierungsvorgaben
• Verpflichtende Integration von unfertigen/legacy APIs (oder solchen, die schlecht dokumentiert sind)

Disclaimer: Diese Liste dient als erste Orientierung. Für jedes der genannten Features gibt es, je nach Anforderung, eine große Bandbreite an Implementierungsmöglichkeiten. Vielleicht sind Ihnen hier auch einige Faktoren aufgefallen, die nicht aufgezählt wurden: Ist es teurer, gerätespezifische Features wie GPS-Tracking mit einzubeziehen? Wie aufwändig sind Details wie Animationen? Wie sieht es mit Performance-Optimierungen aus? Ist eine App, die auf mehreren Plattformen läuft, automatisch mit mehr Kosten verbunden?

In vielen Fällen können Spezifikationen auch überraschend schnell implementiert werden. Für spezialisierte IT-Dienstleister beginnt an dieser Stelle die eigentliche Challenge. Für sie steht immer die Frage im Vordergrund: Wie könnte eine nachhaltige, gut skalierbare Architektur aussehen, die zugleich schnelle Ergebnisse liefert? Wenn Sie wissen möchten, was in Ihrer besonderen Situation am meisten Sinn ergibt, fragen Sie uns gerne unverbindlich nach einer Expert:inneneinschätzung.

Workshops during the kick-off phase serve not only to clarify open questions. They can accelerate the implementation

Every project is unique. And every setup is different. We wouldn't do your project justice if we gave blanket advice at this point. Nevertheless, there are certain approaches that have proven to be profitable. In our projects, for example, MVP workshops (Minimum Viable Product) or Design Sprints have proven their worth during the kick-off phase. Both approaches serve to define the set of core features that create a maximum increase in value for users. For example, if you have an IT consulting firm as a partner, you will put the following aspects through their paces in the kick-off phase (among others):

• Targets and deliverables for the release: What should go in version 1.0? Will we have a Minimum Viable Product for testing purposes or rather extended market maturity?
• Team composition and workflows in the agile project: How will our collaboration look like in detail? How "hands-on" can the stakeholders be? Is there a need for clarification regarding our roles? Will we need other positions before we begin?
• Existing UX/UI: How concrete are user flows and wireframes? How solid are the user interface designs? Will we need customized design or can we use design libraries?
• Existing development environment and state: is there an existing (backend) infrastructure that needs to be integrated or adapted? How mature is the testing environment?
• Platform requirements and user interfaces (especially in IoT), constraints and side conditions: Device, browser, accessibility constraints, privacy, etc.
• Stacks, services and frameworks: How could a sustainable, well-scalable ecosystem look like?
• Savings opportunities: What really needs to be custom implemented, where can we take shortcuts without compromising quality?
• Running costs, hosting, services and licenses: What does the operation cost us per year?
• Schedule: What is a realistic development time? How many developers are needed?
• Perspective for after version 1.0: Who will continue to develop? How will in-house developers be involved and empowered from the beginning?

A solid kick-off with customized requirements workshops gets everyone involved on board. It also helps the team to explore shortcuts, set standards for good communication, and find a common focus.

Im Teil II unserer Serie "Was kostet eine App" haben wir versucht zu klären, welche Stellschrauben den Preis für eine App entscheidend beeinflussen. Mit dem Bild des magischen Dreiecks aus dem Bereich des Projektmanagements fiel unser Blick auf den variablen Faktor des Featurerumfangs. Oberste Prämisse für verantwortungsvolle Softwareentwicklung ist die konsequente Ausrichtung auf diejenigen, die auf der anderen Seite des Screens sitzen. So ist nicht zuletzt der für Stakeholder:innen, Entwicklungsteam und Nutzer:innen stimmige Satz an Features oberste Voraussetzung für eine App mit echtem Mehrwert. Mit den richtigen Partnern lassen sich nicht nur die individuellen Kosten quantifizieren. Ist erst der beste Satz an Mindestspezifikationen für Ihre App gefunden, haben Sie die beste Voraussetzung für die schnelle Umsetzung geschaffen.

Lesen Sie weiter: in Teil III verraten die fünf häufigsten Kostentreiber bei der Appentwicklung und wie sie sich vermeiden lassen.