Keine Rechts- oder Anlageberatung. Stand: 14. Oktober 2026. Die Quellen findest du am Ende des Artikels.
Du kannst deine App weiterentwickeln lassen, ohne sie neu bauen zu müssen. Der entscheidende Punkt ist, dass du vorher weißt, was genau weiterentwickelt werden soll und ob der aktuelle Zustand der App das überhaupt hergibt.
Wann Weiterentwicklung Sinn ergibt
Eine App weiterzuentwickeln ist etwas anderes als eine App zu reparieren. Bei einer Reparatur ist etwas kaputt: Die App stürzt ab, ein Update wurde abgelehnt, eine Schnittstelle liefert keine Daten mehr. Bei der Weiterentwicklung läuft die App grundsätzlich. Du willst aber mehr: ein neues Feature, ein besseres Onboarding, eine Anpassung an neue Systemversionen.
Ein Grund ist die Plattform selbst. Google verlangt von Apps im Play Store, dass sie eine bestimmte Ziel-API-Ebene nutzen. Wer das ignoriert, kann irgendwann keine Updates mehr veröffentlichen. Apple hat eigene Review-Richtlinien, die sich regelmäßig ändern. Was vor zwei Jahren durchging, kann heute abgelehnt werden. Beide Punkte sind in den verlinkten Artikeln zu App entwickeln lassen und App reparieren lassen genauer beschrieben.
Ein zweiter Grund ist die Nutzung. Laut Bitkom waren 2025 in Deutschland durchschnittlich 42 zusätzliche Apps auf Smartphones installiert, ohne vorinstallierte Anwendungen mitzuzählen. Bei unter 30-Jährigen waren es 55. Das heißt: Deine App konkurriert mit Dutzenden anderen um Aufmerksamkeit. Wer eine App hat, die läuft, aber nicht mehr genutzt wird, denkt oft zuerst an ein neues Feature. Manchmal ist das richtig. Manchmal wäre es besser, zuerst die Ladezeit zu verbessern oder den Einstieg zu vereinfachen.
Der Zustand des Codes entscheidet
Bevor du jemanden mit der Weiterentwicklung beauftragst, lohnt sich ein ehrlicher Blick auf den Zustand der App. Auf den Code unter der Oberfläche.
Viele Apps, die seit ein paar Jahren laufen, haben ein gemeinsames Problem: Der Code ist gewachsen, ohne dass jemand aufgeräumt hat. Abhängigkeiten sind veraltet, Teile sind doppelt vorhanden, und die Person, die den ursprünglichen Code geschrieben hat, ist nicht mehr da. Das ist normal. Es ist aber auch der Grund, warum eine kleine Änderung plötzlich drei Wochen dauert.
Der OWASP Mobile Application Security Verification Standard (MASVS) beschreibt, was eine mobile App sicher macht. Dazu gehören Kontrollgruppen für sichere Datenspeicherung, Kryptografie, Authentifizierung, Netzwerkkommunikation und Plattforminteraktion. Der zugehörige Mobile Application Security Testing Guide (MASTG) beschreibt, wie man diese Kontrollen technisch prüft. Beide Dokumente sind öffentlich und kostenlos. Sie richten sich an Entwickler, aber du kannst sie nutzen, um mit einem Dienstleister auf Augenhöhe zu sprechen.
Wenn du den Verdacht hast, dass deine App Sicherheitslücken hat, ist das ein Fall für eine Reparatur, nicht für ein neues Feature. Ein neues Feature auf einem unsicheren Fundament macht das Problem größer.
Was du vor dem ersten Angebot klären solltest
Bevor du Angebote einholst, solltest du drei Dinge wissen.
Erstens: Was genau soll sich ändern? Ein neues Feature, eine Anpassung an neue Systemversionen, eine bessere Performance, ein neues Design. Je konkreter du das beschreibst, desto besser kannst du Angebote vergleichen. Ein Satz wie "Die App soll besser werden" führt zu Angeboten, die nicht vergleichbar sind.
Zweitens: Wer hat den Code? Wenn du die App von einer Agentur hast und der Vertrag dir den Code nicht überträgt, hast du ein Problem. Das ist ein Thema, das viele erst merken, wenn sie wechseln wollen. Kläre das, bevor du mit jemand Neuem sprichst.
Drittens: Gibt es Tests? Wenn die App keine automatisierten Tests hat, wird jede Änderung riskanter. Du musst nicht zuerst alle Tests nachholen. Aber du solltest wissen, dass der Aufwand für die erste Änderung höher sein kann, weil der Dienstleister erst verstehen muss, was der Code tut.
Sicherheit ist kein Feature
Sicherheit lässt sich nicht am Ende dazukaufen. OWASP empfiehlt, Sicherheitsstrategien für mobile Apps auf dem MASVS aufzubauen. Wer eine App weiterentwickelt, übernimmt auch die Verantwortung für den bestehenden Code.
Das heißt praktisch: Wenn du eine App hast, die sensible Daten speichert, und du lässt ein neues Feature einbauen, muss der Dienstleister auch prüfen, ob die bestehende Datenspeicherung sicher ist. Sonst baust du ein neues Zimmer auf ein Haus mit morschem Fundament.
Die OWASP-Dokumente sind dafür ein guter Ausgangspunkt. Ein Dienstleister, der sie nicht kennt, ist für eine Weiterentwicklung mobiler Apps wahrscheinlich die falsche Wahl.
Was eine Weiterentwicklung kostet
Über Preise lässt sich schwer allgemein sprechen, weil jede App anders ist. Was du aber tun kannst: Vergleiche Angebote anhand der gleichen Beschreibung. Wenn du drei Dienstleistern die gleiche Aufgabe gibst und die Preise weit auseinanderliegen, liegt das oft an unterschiedlichen Annahmen über den Aufwand.
Ein Dienstleister, der den Code nicht gesehen hat und trotzdem einen Festpreis nennt, rät. Ein Dienstleister, der zuerst in den Code schauen will, bevor er einen Preis nennt, arbeitet seriös. Das ist keine Garantie, aber ein gutes Zeichen.
Der Gründer von re-entry sagt es so: "Wir können die Preise der nächsten Agentur unterbieten und liefern bessere Qualität." Prüfen kannst du das nur im Vergleich.
Der Unterschied zwischen Weiterentwicklung und Neubau
Manchmal ist es billiger, eine App neu zu bauen, als sie weiterzuentwickeln. Das klingt widersinnig, kommt aber vor. Wenn der Code so veraltet ist, dass jede Änderung mehr kostet als ein Neuanfang, ist der Neubau die bessere Entscheidung.
Ein Hinweis darauf ist die Zahl der Abhängigkeiten. Wenn deine App auf Bibliotheken basiert, die seit Jahren nicht mehr gepflegt werden, wird jede Weiterentwicklung zum Minenfeld. Ein anderer Hinweis ist die Struktur: Wenn niemand mehr erklären kann, warum bestimmte Teile so gebaut wurden, wie sie gebaut wurden, ist das Wissen verloren.
Behalte die Option Neubau im Hinterkopf, wenn du Angebote vergleichst. Ein guter Dienstleister sagt dir, wenn Weiterentwicklung keinen Sinn ergibt.
Was du beim Briefing beachten solltest
Ein gutes Briefing für eine Weiterentwicklung enthält drei Teile: den Ist-Zustand, den Ziel-Zustand und die Randbedingungen.
Der Ist-Zustand ist das, was die App heute tut. Welche Plattformen, welche Version, welche wichtigen Funktionen. Der Ziel-Zustand ist das, was sich ändern soll. Ein neues Feature, eine Anpassung, eine Verbesserung. Die Randbedingungen sind das, was nicht kaputtgehen darf: bestehende Nutzer, Bewertungen im App Store, Daten, Schnittstellen.
Je klarer diese drei Teile sind, desto besser wird das Angebot. Und desto besser kannst du vergleichen.
Studioarbeit bei re-entry
re-entry ist ein unabhängiges App-Studio in Hanau. Eigene Apps kommen zuerst: QuoteBefore für Handwerker, Fazit für Gesprächsnotizen auf dem Mac, Hollin kommt bald. Daneben nimmt das Studio wenige Aufträge an: eine App bauen, eine reparieren oder eine Site verbessern. Kein monatlicher Agenturvertrag. Anfragen gehen an hello@re-entry.ai. Mehr dazu auf der Seite Studioarbeit.