Zunächst eine beruhigende und nachprüfbare Tatsache: Eine generierte Anwendung fixiert alle Abhängigkeiten auf ihre exakte, unveränderliche Version – Next, React, Prisma und alle anderen werden stets mit einer vollständigen, dreistelligen Versionsnummer (z. B. '14.2.3') angegeben, niemals mit Platzhaltern ('^', '~'), Bereichsangaben ('>=14.0.0'), Wildcards ('14.*') oder Begriffen wie 'latest': Nur so ist eine bitgenaue, reproduzierbare Neuinstallation garantiert. Sie lässt sich daher in zwei Jahren identisch neu installieren und bricht nicht von selbst zusammen. Was tatsächlich Wartung erfordert, sind drei klar voneinander getrennte Aspekte: Sicherheitsupdates für Bibliotheken, das Hosting sowie Ihre eigenen geschäftlichen Anpassungen. Solange die Anwendung unter der mitgelieferten URL läuft, entstehen Ihnen für die ersten beiden Punkte keinerlei Kosten; sobald Sie sie jedoch selbst hosten oder ihren Code ändern, wird sie zu einer klassischen Software – und da es sich um Standard-Next.js- und Standard-Prisma-Code handelt, der Ihnen gehört, kann ihn jeder Entwickler übernehmen.
Eine laufende Anwendung verfällt nicht von selbst
Die Intuition sagt, Software „altere“ und breche irgendwann von selbst zusammen. Genau das passiert aber nicht. In der Datei `package.json` einer generierten Anwendung ist jede Abhängigkeit auf ihre exakte, unveränderliche Version festgelegt – ausschließlich als vollständige, dreistellige SemVer-Nummer (z. B. '14.2.3'), niemals mit Platzhaltern ('^', '~'), Bereichsoperatoren ('>=', '<'), Wildcards ('*'), Variablen ('x') oder Begriffen wie 'latest'. Eine Neuinstallation der Anwendung in zwei Jahren rekonstruiert exakt denselben Bibliotheksbaum wie am ersten Tag – und der Code selbst hat sich nicht um ein einziges Byte verändert.
Was sich tatsächlich verschlechtert, ist die Umgebung drumherum: das abgelaufene Zertifikat, der migrierte Server, die vom Hosting-Anbieter nicht mehr unterstützte Node-Version – und vor allem die Sicherheitspatches, die festgelegte Versionen nicht mehr erhalten. Das ist ein grundsätzlicher Unterschied zu „der Software bricht“, und er verändert völlig, was Sie vorausplanen müssen.
Drei unterschiedliche Pflegeaufgaben, die oft vermischt werden
Die erste betrifft die SICHERHEIT der Bibliotheken: Wird eine Schwachstelle in einer Abhängigkeit entdeckt, ist ein Versionsupdate erforderlich. Dies ist die einzige Pflegeaufgabe mit eigenem Zeitdruck – und sie hängt nicht von Ihrer Geschäftstätigkeit ab.
Die zweite ist das HOSTING: Domain, Zertifikat, Datenbank und Backups. Solange die Anwendung über die mitgelieferte URL bereitgestellt wird, übernimmt die Plattform diese Aufgaben – und genau das ist auch die entscheidende Frage, die Sie hier wie bei jedem Anbieter stellen sollten: Wie lautet die Backup-Richtlinie und in welchem Rhythmus erfolgen die Sicherungen? Sobald Sie die Anwendung auf Ihren eigenen Server übertragen, wird dieser Bereich zu Ihrer Verantwortung.
Die dritte Aufgabe ist gar keine Wartung, sondern echte ARBEIT: Ein neues Feld, ein weiterer Status oder ein zusätzlicher Bildschirm, weil sich Ihr Geschäftsmodell geändert hat. Diese Anpassung erfolgt ausschließlich auf Ihre Initiative hin – und wird entsprechend ihrer eigenen Logik behandelt. Dazu finden Sie ausführliche Hinweise im Leitfaden „Ihre Anwendung weiterentwickeln“.
Wer kann das übernehmen – und warum niemand Sie festhält
Der Code basiert auf Standard-Next.js und Standard-Prisma, lässt sich als ZIP-Archiv exportieren oder auf GitHub hochladen – und gehört Ihnen vollständig. Es gibt weder eine proprietäre Sprachvariante noch ein Format, das nur der Hersteller lesen könnte: Der Entwickler, der das Projekt übernimmt, arbeitet mit den Werkzeugen, die er bereits kennt – und genau das macht eine unabhängige Übernahme ohne unser Zutun möglich. Das ist das genaue Gegenteil eines geschlossenen Tools, bei dem die Frage „Wer pflegt das?“ nur eine Antwort zulässt – nämlich den Hersteller, solange er existiert.
Der Gegenwert ist ehrlich benannt: Sobald Sie den Code selbst ändern, ist die aktuell laufende Version nicht mehr jene, die die Plattform automatisch neu generieren kann. Sie gewinnen volle Freiheit – und übernehmen zugleich die Pflegeverantwortung. Viele kleine Unternehmen gehen diesen Schritt nie – und brauchen ihn auch nicht. Doch die Tür bleibt offen, und das ist entscheidend, wenn Sie sie eines Tages durchschreiten möchten.
Was Sie tatsächlich einkalkulieren müssen
Bei maßgeschneiderter Software geht die Fachliteratur davon aus, dass die korrigierende Wartung jährlich rund 15 bis 20 % der Erstinvestition kostet und dass Wartung plus Weiterentwicklung innerhalb von fünf Jahren etwa die Hälfte der gesamten Total Cost of Ownership (TCO) ausmachen. Dieser Posten wird von fast niemandem budgetiert – und doch ist er es, der aus einem erfolgreichen Projekt drei Jahre später ein vernachlässigtes Werkzeug macht.
Die Rechnung ändert sich, wenn die Erstinvestition gering ist und das Hosting inkludiert ist: Solange die Anwendung unverändert läuft, müssen Sie nichts zurücklegen. Die Kosten tauchen nur an zwei Stellen wieder auf – wenn Sie das Hosting selbst übernehmen oder den Code anpassen lassen. Entscheidungen mit diesen beiden Möglichkeiten im Blick sind sinnvoller, als eine Versicherung gegen einen Ausfall abzuschließen, der bei festgelegten Versionen schlicht nicht eintritt.