Next.js-Wartung & Support

Die meisten Anwendungen fallen nicht aus. Sie driften. Das Framework zieht zwei Hauptversionen davon, eine Abhängigkeit wird nicht mehr gepflegt, die Person, die die Caching-Schicht verstand, geht - und eines Tages ist ein Routine-Upgrade ein Zwei-Wochen-Projekt, das niemand eingeplant hat.

Das ist der Dienst für Teams, die eine Anwendung in Produktion haben, keinen Next.js-Spezialisten für vierzig Stunden die Woche brauchen und nicht wollen, dass das erste Gespräch mit einem Spezialisten während eines Vorfalls stattfindet.

Was es nicht ist

Kein Retainer, der existiert, um eine Rechnung zu erzeugen. Wir sagen das deutlich, weil die Branche sich das Misstrauen verdient hat: Steckt in einem Monat keine Arbeit, sagen wir es Ihnen, und Sie zahlen die Stunden nicht.

Es ist auch kein Support-Desk. Sie reichen keine Tickets in eine Warteschlange ein. Sie sprechen mit den Entwicklern, die Ihre Codebasis gelesen haben.

Was es abdeckt

Framework- und Abhängigkeits-Upgrades. Next.js und React bewegen sich schnell. Wir verfolgen, was sich ändert, entscheiden, was für Ihre Anwendung konkret zählt, und führen das Upgrade mit gelesenen Release Notes durch statt mit erhöhter Versionsnummer. Ein Minor, der Ihr Caching-Verhalten berührt, ist eine andere Aufgabe als einer, der es nicht tut - und zu wissen, welcher was ist, ist der größte Teil des Werts.

Sicherheit und Abhängigkeitsrisiko. Advisories gegen Ihre Lockfile, triagiert danach, ob der verwundbare Pfad einer ist, den Ihr Code überhaupt erreicht. Die meisten Advisories in einem Next.js-Abhängigkeitsbaum sind in Ihrer Anwendung nicht ausnutzbar; von denen, die es sind, müssen Sie am selben Tag hören.

Performance-Regressionen. Felddaten bleiben nicht von allein gut. Ein in der CI durchgesetztes Budget fängt, was ein Deploy tut; ein monatlicher Blick auf die Core Web Vitals fängt, was eine CMS-Änderung, ein neues Tag oder ein Dritter getan hat. Der Mechanismus ist derselbe, den wir im Performance-Engineering installieren - hier halten wir ihn ehrlich.

Vorfälle. Eine namentlich benannte Entwicklerin, die Ihre Architektur kennt und in einem vereinbarten Fenster erreichbar ist. Der Punkt ist nicht die Reaktionszeit im Vertrag. Der Punkt ist, dass die Person, die abhebt, Ihren Code vor dem Vorfall gelesen hat und nicht während dessen.

Die kleine Arbeit, die nie priorisiert wird. Eine Route, die statisch sein sollte und es nicht ist. Eine Abhängigkeit, die weg könnte. Das use client, das nach oben ins Layout gekrochen ist. Einzeln rechtfertigt nichts davon ein Projekt; zusammen ist es der Unterschied zwischen einer Anwendung, die gut altert, und einer, die es nicht tut.

Wie es geschnitten ist

Ein monatliches Stundenkontingent, im Voraus vereinbart, mit aufgeschriebenem Zweck. Ungenutzte Stunden bleiben ungenutzt - wir erfinden keine Arbeit, um sie zu verbrauchen, und wir schieben sie auch nicht unbegrenzt vor uns her, denn ein wachsendes Guthaben ist ein Zeichen, dass die Vereinbarung falsch ist, und das gehört gesagt.

Über das Kontingent hinaus wird Arbeit als Projekt angeboten. Im Hintergrund läuft kein Stundenzähler.

Beide Seiten können mit einem Monat Frist beenden. Eine Wartungsvereinbarung, die einen Vertrag zum Überleben braucht, wollen wir nicht.

Was Sie im ersten Monat bekommen

Vor jeder laufenden Arbeit dieselbe Orientierung, die wir auf jeder geerbten Anwendung fahren: eine Routenkarte, die Datengrenze, der Deployment-Pfad und die Liste dessen, was als Nächstes bricht, nach Zeitpunkt sortiert. Dieses Dokument gehört Ihnen, ob die Vereinbarung weiterläuft oder nicht. Es ist dasselbe Artefakt wie in Migration und Rettung beschrieben, und es macht alles danach billiger.

Wann Sie das nicht brauchen

Haben Sie eine Entwicklerin, die die Next.js-Release-Notes liest, brauchen Sie uns für Upgrades nicht. Ist Ihre Anwendung eine Marketing-Seite, die sich zweimal im Jahr ändert, kostet ein jährlicher Review weniger und leistet dasselbe.

Das sagen wir lieber am Anfang, als ein Jahr lang abzurechnen, in dem nichts passiert.