Wann lohnt es sich, eine App von Grund auf neu zu schreiben?

Wenn das Datenmodell nicht zum Geschäft passt, niemand den Hauptablauf erklären kann und sich der Code ohne Umbau nicht testen lässt. Treffen acht oder mehr der zwölf Punkte zu, schreiben Sie den Kern neu. Der Prototyp dient dann als Vorlage dafür, was funktioniert und was nicht.

Was heißt, einen Prototyp zu stabilisieren?

Den Code behalten und ergänzen, was für den Betrieb fehlt: Tests für die Hauptabläufe, Berechtigungen und Schlüssel auf dem Server, Backups und Monitoring. Das ist schneller und günstiger als ein Neubau.

Warum auch abhaken, was ich nicht weiß?

Weil „weiß nicht“ bei einem Prototyp schon ein Befund ist. Weiß niemand, wo die Backups liegen oder wer Zugang zum Hosting hat, ist das genauso ein Risiko wie ein fehlendes Backup.

Was, wenn die App auf einer Plattform liegt, von der man nicht wegkommt?

Lösen Sie das zuerst, unabhängig vom Ergebnis. Solange Sie Code und Daten nicht exportieren können, findet jede Korrektur in einem fremden System statt, und es gehört Ihnen nie ganz.

Test mit Urteil

Stabilisieren oder neu schreiben? Prototyp-Test in 5 Minuten

Ob Sie einen Prototyp stabilisieren oder neu schreiben, entscheiden 12 Fragen in vier Bereichen: Daten und Zugriffe, Deployment, Tests und Code. Haken Sie ab, was zutrifft, auch dort, wo Sie es nicht wissen, und Sie sehen ein Urteil: stabilisieren, stabilisieren und zuerst den schwächsten Bereich beheben, oder den Kern neu schreiben. Von Grund auf neu zu schreiben lohnt sich seltener, als es scheint.

Was Sie ausfüllen und abhaken, bleibt nur in diesem Browserfenster. Wir senden nichts, solange Sie sich die Auswertung nicht per E-Mail schicken lassen. Nach dem Schließen ist es weg, drucken Sie Ihr Ergebnis also aus.

Für Vibe Coder und Gründer, deren App in einem KI-Tool oder bei einem Freelancer entstanden ist und jetzt wachsen soll. Haken Sie ab, was auf Ihre App zutrifft. Wo Sie es nicht wissen, haken Sie ebenfalls ab: „weiß nicht“ ist bei einem Prototyp schon ein Befund.

Seit 2023 haben wir 15+ Produktivprojekte geliefert und mehrfach fremden Code übernommen. Von Grund auf neu zu schreiben lohnt sich seltener, als viele denken.

1. Daten und Zugriffe

Das Datenmodell passt nicht zum Geschäft: Eine Änderung an einer Stelle bricht zwei andere.
Berechtigungen sind nur ausgeblendete Buttons, oder geheime Schlüssel stehen im Browser-Code.
Sie können die Daten nicht aus der Plattform exportieren, auf der die App läuft.

2. Deployment

Hosting, Datenbank oder Domain liegen auf dem privaten Konto einer einzelnen Person.
Eine Person deployt von Hand, und niemand sonst kann es wiederholen.
Sie haben keine geprüften Backups und keinen Alarm, wenn die App ausfällt.

3. Tests

Die Hauptabläufe haben keinen automatischen Test.
Behobene Fehler kehren an Stellen zurück, die niemand geändert hat.
Ein Test lässt sich nicht hinzufügen, ohne den Code umzuschreiben.

4. Code

Niemand, auch nicht der Autor, kann erklären, was vom Klick bis zum Speichern der Daten passiert.
Jede neue Funktion dauert länger als die vorherige.
Der Code lässt sich außerhalb der Plattform, in der er entstanden ist, nicht betreiben.

5. Was das Ergebnis bedeutet

Abgehakt	Urteil	Wie weiter
0 bis 3	Fast am Ziel	Stabilisieren. Der Code bleibt. Ergänzen Sie Tests für die Hauptabläufe, verlagern Sie Schlüssel und Berechtigungen auf den Server, richten Sie Backups und Monitoring ein.
4 bis 7	Auf halbem Weg	Stabilisieren, aber zuerst den schwächsten Bereich beheben. Behalten Sie, was funktioniert, und bauen Sie nur den Bereich mit den meisten Haken neu, meist das Datenmodell oder den Login.
8 bis 12	Am Anfang	Kern neu schreiben. Bauen Sie den Kern auf gängigen Technologien neu und übertragen Sie die Daten. Der Prototyp bleibt die Vorlage dafür, was funktioniert und was nicht.

Trifft der dritte Punkt bei den Daten oder der letzte beim Code zu, lösen Sie ihn zuerst, unabhängig vom Ergebnis: Solange Sie nicht von der Plattform wegkommen, findet jede Korrektur in einem fremden System statt.

Sie wollen Gewissheit bei Daten und Zugriffen? Starten Sie den Prompt zur Prototyp-Prüfung. Der ganze Weg vor dem Start steht in der Checkliste mit 25 Punkten.

Weitere Tools für Sie

Sehen Ihre Nutzer fremde Daten? Prüfen Sie Ihren Prototyp selbst

Ein Prompt für Claude Code oder Cursor, der Ihr Repository in sechs Bereichen prüft und die Befunde nach Schweregrad sortiert.

Vom Prototyp in die Produktion: 25 Punkte vor dem Start

Häufige Fragen

Wann lohnt es sich, eine App von Grund auf neu zu schreiben?: Wenn das Datenmodell nicht zum Geschäft passt, niemand den Hauptablauf erklären kann und sich der Code ohne Umbau nicht testen lässt. Treffen acht oder mehr der zwölf Punkte zu, schreiben Sie den Kern neu. Der Prototyp dient dann als Vorlage dafür, was funktioniert und was nicht.
Was heißt, einen Prototyp zu stabilisieren?: Den Code behalten und ergänzen, was für den Betrieb fehlt: Tests für die Hauptabläufe, Berechtigungen und Schlüssel auf dem Server, Backups und Monitoring. Das ist schneller und günstiger als ein Neubau.
Warum auch abhaken, was ich nicht weiß?: Weil „weiß nicht“ bei einem Prototyp schon ein Befund ist. Weiß niemand, wo die Backups liegen oder wer Zugang zum Hosting hat, ist das genauso ein Risiko wie ein fehlendes Backup.
Was, wenn die App auf einer Plattform liegt, von der man nicht wegkommt?: Lösen Sie das zuerst, unabhängig vom Ergebnis. Solange Sie Code und Daten nicht exportieren können, findet jede Korrektur in einem fremden System statt, und es gehört Ihnen nie ganz.

Wie geht es weiter?

MVP und Produkt

Ein laufendes Produkt in Wochen, nicht Monaten

Prototyp-Audit

Ein Senior geht den Code durch und schreibt auf, was zu stabilisieren, was neu zu schreiben ist und in welcher Reihenfolge. Wir melden uns innerhalb von zwei Arbeitstagen mit ein paar Fragen zu Ihrer Arbeit. Dann vereinbaren wir, was wir zuerst angehen.

Schreiben Sie uns, was zuerst live gehen muss Oder ein 15-minütiges Erstgespräch

Für wen

Leistungen

Know-how

Was ist ein KI-Agent? Einfach erklärt, mit Beispielen

Wann reicht Excel im Unternehmen nicht mehr?