Was kostet ein App-Redesign? Budget für Refresh, Refactoring und Neubau

Kostenrahmen nach Eingriffstiefe

Die folgenden Beträge beziehen sich auf eine umgesetzte, getestete und veröffentlichte Lösung für iOS und Android. Eine reine UX/UI-Leistung ohne Programmierung wird separat kalkuliert.

Bei sensiblen Gesundheits- oder Finanzdaten, mehreren Rollen, komplexer Offline-Synchronisation oder Hardware-Anbindung kann der Aufwand darüber liegen. Eine Untersuchung einzelner Nutzerwege oder ein Prototyp ohne Umsetzung kann dagegen kleiner sein. Wichtig ist, dass beim Preisvergleich alle Angebote dasselbe Ergebnis versprechen.

Der häufigste Preisfehler: Design mit Release verwechseln

Eine Designleistung kann Nutzerforschung, Informationsarchitektur, Abläufe, Wireframes, visuelle Gestaltung, Komponenten und einen klickbaren Prototyp umfassen. Das ist ein sinnvolles Ergebnis, wenn ein internes Team die Umsetzung übernimmt.

Ein veröffentlichtes Redesign enthält zusätzlich mobile Entwicklung, Fehler- und Leerzustände, Barrierefreiheit, Backend-Anpassungen, Analytics, Kompatibilität, Gerätetests, Store-Material und Release-Begleitung. Auch seltene Fälle gehören dazu: Passwort vergessen, abgelaufene Sitzung, fehlgeschlagene Zahlung, alter Deep Link oder ein Nutzer mit einer sehr alten App-Version.

Ein Angebot sollte deshalb jede Position als Analyse, Design, Entwicklung, Migration, Qualitätssicherung, Veröffentlichung oder Betreuung kennzeichnen. Die Vorlage für eine App-Kostenschätzung zeigt, welche Leistungen bei einem knappen Pauschalpreis oft fehlen.

Vor dem Festpreis steht die Bestandsaufnahme

Eine Zusage wie "Wir übernehmen den vorhandenen Code vollständig" ist vor dem Repository-Zugriff wertlos. Im Bestand können erprobte Regeln und stabile Schnittstellen stecken. Genauso gut kann er auf nicht mehr gepflegten Bibliotheken, eingebetteten Zugangsdaten und undokumentierten Sonderfällen beruhen.

Eine kurze Produktprüfung betrachtet Trichterdaten, Supportanfragen, Store-Bewertungen und die Abläufe, die Umsatz oder Kundennutzen erzeugen. Technisch werden Build-Anleitung, Architektur, Abhängigkeiten, Backend, Umgebungen, Tests, Absturzberichte und Release-Verlauf geprüft. Beim Design geht es um wiederkehrende Komponenten, Abweichungen und unnötige Varianten.

Am Ende sollte kein vages Ampelsystem stehen, sondern eine belastbare Wiederverwendungskarte:

• unverändert beibehalten;
• hinter einer stabilen Schnittstelle beibehalten;
• vor einer Erweiterung refaktorieren;
• aufgrund des Risikos ersetzen;
• in einer klar begrenzten Analysephase untersuchen.

Der Artikel von x-root zum professionellen App-Redesign beschreibt ebenfalls, dass eine etablierte Nutzerbasis und eine tragfähige technische Grundlage für ein echtes Redesign sprechen. Liegt das Problem in der Basis, wird aus dem Designauftrag schnell eine Modernisierung.

Wiederverwendung ist mehr als alter Quellcode

Auch wenn die mobile Anwendung neu entsteht, können Marke, Store-Eintrag, Inhalte, Nutzerkonten, Transaktionshistorie und ein stabiles Backend erhalten bleiben. Dokumentierte Geschäftsregeln und bestehende Tests sind wertvolle Spezifikationen für neu geschriebene Module.

Ein Baustein ist besonders gut wiederverwendbar, wenn Eigentum, Verhalten und Schnittstellen klar sind. Eine geprüfte Zahlungsabwicklung mit funktionierenden Webhooks und Erstattung ist wertvoller als eine einzelne schöne Ansicht ohne Fehlerfälle. Eine API mit Tests lässt sich besser einschätzen als direkter Datenbankzugriff aus vielen alten Komponenten.

Schwache Kandidaten sind verlassene Bibliotheken, unklare Lizenzen, Geheimnisse im App-Paket, nicht dokumentierte lokale Daten und Module, die nur auf dem Rechner eines ehemaligen Entwicklers gebaut werden können. Ihre Übernahme senkt möglicherweise das erste Angebot, erhöht aber das Termin- und Ausfallrisiko.

Das Bild einer Brücke passt gut: Eine intakte Oberfläche zu erneuern ist etwas anderes, als tragende Teile zu verstärken. Muss währenddessen eine neue Verbindung entstehen, kommen Verkehrsführung und Übergangsbetrieb hinzu. Bei einer laufenden App sind Nutzer und Daten dieser Verkehr.

Diese Arbeitspakete bestimmen den Preis

Produktanalyse und UX. Daten, Interviews, Supportmuster und Tests zeigen, welche Abläufe verändert werden müssen. Ein fokussiertes Projekt kann sich auf Registrierung und Buchung beschränken. Ein Neubau muss auch Wiederherstellung, Kündigung, Support und seltene Ausnahmefälle abdecken.

Designsystem. Typografie, Farben, Abstände, Bedienelemente, Icons und Inhaltsregeln werden als wiederverwendbare Komponenten geplant. Dazu gehören Lade-, Leer-, Fehler-, Sperr- und barrierefreie Zustände. iOS und Android dürfen gemeinsame Grundlagen haben, brauchen aber bewusst gewählte Plattformunterschiede.

Mobile Umsetzung. Komponenten werden mit Navigation, Zustand, Berechtigungen, Benachrichtigungen, lokalem Speicher und Gerätefunktionen verbunden. Eine Oberfläche, die die bestehende Architektur ignoriert, kann in der Umsetzung überraschend teuer werden.

Backend und Admin-Panel. Ein neuer Buchungsweg verändert möglicherweise Verfügbarkeit und Storno. Ein Marktplatz-Redesign kann Moderation, Auszahlungen und Konfliktbearbeitung betreffen. Die Arbeit des internen Teams gehört zum Produktumfang.

Migration und Kompatibilität. Konten, Sitzungen, Käufe, Abos, Favoriten, Entwürfe und alte Links müssen weiter funktionieren oder nachvollziehbar überführt werden.

Tests und Veröffentlichung. Regression, echte Geräte, Analytics, Barrierefreiheit, Store-Prüfung und überwachte Einführung sind kein optionaler Abschluss. Sie entscheiden, ob das Redesign im laufenden Betrieb tragfähig ist.

Bestandsnutzer machen die Migration zum eigenen Teilprojekt

Bei einer neuen App ist die Datenbank am Anfang leer. Ein Redesign übernimmt Historie, lokale Daten und erlernte Bedienmuster. Die Spezifikation sollte erklären, was passiert, wenn jemand von einer sechs Monate alten Version aktualisiert, eine offene Bestellung fortsetzt oder über eine alte Benachrichtigung zurückkehrt.

Zu prüfen sind mindestens:

1. Kontokennungen, Sitzungen und Zugangswiederherstellung.
2. Abonnements, Käufe, Guthaben und laufende Erstattungen.
3. Favoriten, Entwürfe und lokal gespeicherte Informationen.
4. Deep Links, E-Mail-Links und Benachrichtigungsziele.
5. Kontinuität von Nutzerkennungen und Analytics-Ereignissen.
6. Support für alte und neue App-Versionen.

Manche Backend-Endpunkte müssen beide Versionen bedienen, bis genügend Menschen aktualisiert haben. Funktionsschalter helfen, einen kritischen Ablauf abzuschalten, ohne auf die nächste Store-Freigabe zu warten. Der Support benötigt Versions- und Migrationsstatus, sonst kann er Fehler nicht einordnen.

Mit unserer Checkliste für Dokumentation und Übergabe lassen sich Konten, Repositories, Datenregeln und Release-Zugänge vor Projektbeginn sichern.

Drei typische Ausgangslagen

Terminbuchung mit stabiler Technik. Die Nutzer finden Leistung, Zeit und Stornobedingungen schlecht, aber Backend und Releases sind zuverlässig. Ein fokussierter Refresh kann diese Wege vereinfachen, Komponenten vereinheitlichen und die Verbesserung messen. Das Buchungssystem neu zu bauen wäre unnötig.

E-Commerce-App mit brüchiger Oberfläche. Katalog und Bestellungen funktionieren, doch Konto, Warenkorb und Treueprogramm folgen unterschiedlichen Mustern. Jede Veröffentlichung verursacht neue Fehler. Hier passt oft ein Redesign mit gezieltem Refactoring: Daten und bewährte Integrationen bleiben, die mobile Komponentenstruktur und die Grenzen des Checkouts werden erneuert.

Dienstleistungsplattform mit neuem Geschäftsmodell. Früher gab es nur Kunden, künftig zusätzlich Anbieter und Betreiber, Echtzeitstatus, Auszahlungen und Konflikte. Das ist keine optische Überarbeitung mehr. Trotz gleicher Marke und vorhandener Nutzer nähert sich der Umfang einer kontrollierten Neuentwicklung.

Alle drei Produkte könnten dieselbe Zahl an Ansichten besitzen. Ihre Kosten unterscheiden sich wegen Rollen, Zuständen, Migration und Betriebslogik.

So wird der Umfang kleiner, ohne Qualität zu verstecken

Wählen Sie für die erste Veröffentlichung ein messbares Ziel: mehr abgeschlossene Registrierungen, weniger Abbrüche bei Buchungen oder weniger Supportkontakte. Bearbeiten Sie die dazugehörigen Abläufe und verschieben Sie unabhängige Wünsche.

Eine stabile Infrastruktur darf bleiben. Ein neues Erscheinungsbild erfordert nicht automatisch ein neues Backend. Umgekehrt sollte ein gefährliches Modul nicht nur deshalb weiterleben, weil bereits Geld hineingeflossen ist.

Früh bereitgestellte Zugänge sparen echte Zeit: Repositories, Store-Konten, Analytics, Crash-Berichte, Testnutzer, Umgebungen und Design-Dateien. Die Übersicht zur Entwicklungsdauer zeigt, wie stark Entscheidungen und fehlende Zugänge den Kalender beeinflussen.

Neue Funktionen sollten während der Migration nur aufgenommen werden, wenn sie für Kompatibilität oder das vereinbarte Ziel erforderlich sind. Ein Redesign mit gleichzeitig offener Wunschliste lässt sich weder zuverlässig testen noch steuern.

Woran man ein belastbares Angebot erkennt

Ein gutes Angebot nennt aktuelle Versionen, Zielplattformen, Nutzerwege und Arbeitspakete. Es trennt mobile App, Backend, Admin-Panel, Migration, Tests und Store-Veröffentlichung. Annahmen zur Wiederverwendung werden schriftlich festgehalten, ebenso der Umgang mit neuen Erkenntnissen aus der Prüfung.

Abnahmekriterien beschreiben beobachtbares Verhalten. "Zeitgemäßes Design" ist Geschmack. "Ein Bestandskunde behält seine Daten, bucht im neuen Ablauf und erhält die richtige Erinnerung" lässt sich prüfen.

Warnzeichen sind:

• Wiederverwendungsversprechen ohne Codezugriff;
• Kalkulation ausschließlich nach Idealansichten;
• kein Budget für alte Daten und Versionskompatibilität;
• fehlende Analytics, Absturzüberwachung und Rückfallplan;
• Tests und Store-Veröffentlichung werden vollständig ausgelagert;
• Technologieentscheidung vor Produkt- und Bestandsanalyse.

Die Vertragscheckliste für App-Projekte ergänzt diese Prüfung um Rechte, Abnahme, Konten und Projektübergabe.

Ein gestaffelter Rollout begrenzt das Risiko

Vor der breiten Einführung sollte die neue Version intern und mit einer repräsentativen Testgruppe geprüft werden. Danach werden Abstürze, Anmeldung, Zahlungen, Zielerreichung, Support und Bewertungen beobachtet, während der Anteil der Nutzer schrittweise wächst.

Apple bietet für geeignete Updates eine siebentägige stufenweise Veröffentlichung. In Google Play lässt sich ein gestaffelter Rollout erhöhen oder stoppen. Beides begrenzt die Reichweite eines Fehlers, ersetzt aber keine kompatible Datenmigration.

Stoppsignale werden vor dem Release festgelegt: sinkende absturzfreie Sitzungen, mehr Zahlungsfehler, defekte Kontowiederherstellung oder ein starker Einbruch im Kernablauf. Dafür braucht es vorbereitete Ereignisse. Die Anleitung zur App-Analytics und unsere QA-Checkliste helfen bei der Vorbereitung.

Wie Appfyl ein bestehendes Produkt schätzt

Appfyl trennt zunächst den sichtbaren Wunsch vom eigentlichen Produktproblem. Wir prüfen wichtige Abläufe, verfügbare Daten, den Zustand von App und Backend, interne Werkzeuge, Release-Zugänge und das nächste Geschäftsziel.

Im Angebot ist sichtbar, was aufgefrischt, refaktoriert, ersetzt oder bewusst beibehalten wird. Migration, Admin-Arbeit, Tests und gestaffelte Einführung stehen nicht zwischen den Zeilen. Dadurch lässt sich der Umfang ehrlich reduzieren, ohne Bestandsnutzer auszublenden.

Den ersten Rahmen können Sie im interaktiven Appfyl-Briefing vorbereiten. Nennen Sie die bestehende App, die zu verbessernden Abläufe, verfügbare Unterlagen und feste Termine. Mehr zum Team finden Sie bei Appfyl App-Entwicklung.

Sehen Sie, wie Appfyl Funktionsumfang in veröffentlichte Produkte übersetzt. Appfyl Cases ansehen.

Häufige Fragen