Was eine individuelle Node.js-Plattform wirklich kostet: Entwicklung, Launch und drei Jahre Betrieb

Jemand hat Ihnen eine Zahl für den Aufbau einer individuellen Plattform genannt. Es ist eine große Zahl, und Sie versuchen herauszufinden, ob sie die richtige ist. Die unbequeme Antwort: Der Entwicklungsbetrag — von wem auch immer er stammt — ist etwa die Hälfte dessen, was die Plattform Sie über drei Jahre kosten wird, und die fehlende Hälfte ist nicht versteckt. Sie ist schlicht nicht das, was ein Statement of Work beschreibt.

Das ist das Modell, das wir verwenden, wenn ein Kunde uns bittet, sein Budget sauber zu planen — auch für Arbeit, die er womöglich nicht an uns vergibt.

Jahr null: die Entwicklung

Die sichtbare Zahl. Sie verteilt sich meist berechenbarer, als Auftraggeber erwarten:

• Discovery und Architektur: 8–12 % der Entwicklungskosten. Hier zu sparen ist der zuverlässigste Weg, später zu viel auszugeben.
• Kernanwendung: 40–50 %. Die Funktionen aus dem Briefing.
• Integrationen: 15–30 %. Fast immer unterschätzt — siehe unten.
• Nichtfunktionale Arbeit: 10–20 %. Authentifizierung, Berechtigungen, Rate Limiting, Dateiverarbeitung, Transaktions-E-Mails, Logging, Fehlerbehandlung. In einer Demo unsichtbar, im Produktivbetrieb tragend.
• Tests und Härtung: 8–15 %.
• Deployment und Infrastruktur-Setup: 5–10 %.

Für eine wirklich individuelle Plattform mit echten Integrationen liegt eine realistische Entwicklung zwischen £120.000 und £450.000. Unter rund £80.000 kaufen Sie ein MVP — ein legitimer Kauf, solange es alle offen aussprechen.

Warum Integrationen die Schätzung sprengen

Anbindung an das ERP ist eine Zeile im Briefing und drei bis acht Wochen Arbeit. Die Streuung entsteht durch Dinge, die zum Zeitpunkt des Angebots niemand wissen kann: ob die API dokumentiert ist, ob es eine Sandbox gibt, ob das Rate Limiting des Anbieters Ihr Volumen zulässt, ob die Datenmodelle zusammenpassen und ob die Person, die das System versteht, dort noch arbeitet.

Kalkulieren Sie Integrationen als Spanne mit je einer benannten Annahme und rechnen Sie nach einem technischen Spike neu. Eine Integration, die zum Festpreis angeboten wird, bevor jemand die API gesehen hat, ist eine Schätzung, die sich als Preis ausgibt.

Jahr eins: Launch und Stabilisierung

Das Jahr, das die meisten Budgets als Wartung verbuchen und das alles andere als das ist.

• Stabilisierung nach dem Launch: 15–25 % der Entwicklungskosten. Echte Nutzer finden jedes Mal das, was die Tests nicht gefunden haben.
• Infrastruktur: £500–£5.000/Monat, je nach Größenordnung und Redundanz.
• Drittanbieter-Dienste: Monitoring, Error Tracking, E-Mail-Versand, Suche, Authentifizierung. £200–£2.000/Monat, und es wächst unbemerkt.
• Der Änderungs-Backlog: alles, was das Unternehmen wollte, aber zurückgestellt hat. Planen Sie 20–35 % der Entwicklungskosten für das erste Jahr ein — sonst erstarrt die Plattform an dem Tag, an dem sie live geht.

Jahr zwei und drei: der Betrieb

Hier unterscheidet sich Individualsoftware grundlegend von Lizenzsoftware — und hier hören die meisten Business Cases still auf zu rechnen.

Wartung der Abhängigkeiten

Eine Node.js-Anwendung trägt einen großen Abhängigkeitsbaum, und der hält nicht still. Der Release-Zyklus von Node stellt Versionen planmäßig ab, Frameworks und Bibliotheken veröffentlichen Breaking Changes, und Security Advisories kommen unabhängig davon, ob Sie gerade Kapazität haben.

Planen Sie 5–10 % der Entwicklungskosten pro Jahr allein dafür ein, aktuell zu bleiben. Lassen Sie das aus, sparen Sie nicht — Sie häufen eine Schuld an, die auf einen Schlag fällig wird, meist dann, wenn ein Security Advisory sie dringend macht und der Upgrade-Pfad inzwischen aus einer Kette von fünf Major-Versionen besteht.

Betrieb und On-Call

Jemand meldet sich, wenn es um drei Uhr nachts ausfällt. Das ist eine Leistung mit einem Preis, und dieser Preis unterscheidet sich um eine Größenordnung, je nachdem, was Sie tatsächlich brauchen:

• Geschäftszeiten, Best Effort: £1.500–£4.000/Monat
• Erweiterte Zeiten mit Reaktions-SLA: £4.000–£10.000/Monat
• Echte 24/7-Bereitschaft mit Dienstplan: ab £10.000/Monat, weil es genug Leute braucht, damit ein Dienstplan zumutbar bleibt

Entscheiden Sie ehrlich, was Sie brauchen. 24/7 für eine Plattform zu kaufen, deren Nutzer alle in einer Zeitzone sitzen, ist Verschwendung; nur Geschäftszeiten für ein System zu kaufen, das nachts Bestellungen verarbeitet, heißt am falschen Ende zu sparen — und Sie werden es auf die unangenehmste Art merken.

Kontinuierliche Weiterentwicklung

Eine Plattform, die sich nicht verändert, wird von den Anforderungen überholt. Die meisten erfolgreichen Individualentwicklungen pendeln sich bei 15–30 % der ursprünglichen Entwicklungskosten pro Jahr an laufender Weiterentwicklung ein. Das ist kein Versäumnis im ursprünglichen Umfang, sondern schlicht, wie es aussieht, Software zu besitzen.

Klumpenrisiko durch Einzelpersonen

Der Posten, der am schwersten zu kalkulieren und am leichtesten zu übersehen ist. Wenn nur eine Person die Plattform versteht, haben Sie kein Vermögen, sondern ein Risiko. Das abzufedern — Dokumentation, Pair Programming, ein zweiter Entwickler, der das System wirklich kennt — kostet Geld und ist trotzdem günstiger als die Alternative. Kalkulieren Sie es ausdrücklich ein, sonst zahlen Sie es ungeplant.

Das Bild über drei Jahre

Nehmen Sie eine Entwicklung für £200.000. Ein realistischer Gesamtbetrag über drei Jahre liegt bei moderater laufender Roadmap und Support zu Geschäftszeiten bei etwa £520.000–£700.000, sobald Stabilisierung, Infrastruktur, Wartung der Abhängigkeiten, Betrieb und Weiterentwicklung mitgerechnet sind.

Das ist kein Argument gegen den Eigenbau. Es ist die Zahl, die Sie der Alternative gegenüberstellen — und genau dafür macht man die Rechnung.

Wann Sie nicht selbst bauen sollten

Wir lehnen Individualentwicklungen regelmäßig ab, und das sind die Gründe:

• Ein konfigurierbares Produkt deckt 80 % davon ab. Die restlichen 20 % rechtfertigen fast nie, alles für immer selbst zu besitzen.
• Intern kann niemand die Verantwortung übernehmen. Individualsoftware ohne internen Verantwortlichen verkommt zu einer ungewarteten Altlast, so gut sie auch gebaut wurde.
• Die Anforderungen bewegen sich noch. Bauen Sie gegen ein bewegliches Ziel, zahlen Sie die Entwicklung zweimal. Bauen Sie zuerst einen Prototyp auf etwas Günstigem.
• Die Summe über drei Jahre übersteigt den Wert, den sie erschließt. Machen Sie diese Rechnung, bevor die Entwicklung beginnt, nicht im zweiten Jahr.
• Es ist nicht Ihr Alleinstellungsmerkmal. Bauen Sie das, womit Sie Geld verdienen; kaufen Sie das, was alle brauchen.

Das stärkste Argument für den Eigenbau ist der Umkehrschluss: Die Software ist das Geschäft, oder sie bildet einen kommerziellen Vorteil ab, den niemand von der Stange verkauft. So lagen die Dinge bei Hotelogix' Hotelmanagement-SaaS und bei der Plattform von Dad.Live — in beiden Fällen war das Produkt die Sache selbst und keine unterstützende Funktion.

Fragen, die Sie jedem Angebot stellen sollten

1. Was ist nicht enthalten? Die aufschlussreichste Frage, die Sie stellen können — die Antwort verrät, wie erfahren das Team ist.
2. Bei welchen Integrationen haben Sie die API tatsächlich gesehen? Alles Ungesehene ist eine Schätzung, kein Preis.
3. Was umfasst die Übergabe — Dokumentation, Runbooks, Architecture Decision Records, eine funktionierende lokale Umgebung für einen neuen Entwickler?
4. Wem gehören der Code, die Repositories, die Cloud-Accounts und die Domains? Fragen Sie vor der Unterschrift, nicht erst dann, wenn Sie gehen wollen.
5. Wie sieht das Support-Modell nach dem Launch aus, und was kostet es?
6. Was würden Sie anders bauen, wenn das Budget 30 % kleiner wäre? Die Antwort zeigt, was das Team für unverzichtbar hält.

Wenn Sie das Drei-Jahres-Modell für Ihre eigenen Anforderungen aufgestellt haben möchten: Das ist Arbeit, die unsere Node.js- und Full-Stack-Teams vor einem Projekt leisten und nicht erst mittendrin — und unsere Full-Stack-Entwicklung deckt die Betriebsseite ab, die im Angebot für die Entwicklung fehlt.

Rechnen Sie es durch, bevor Sie sich festlegen

Schicken Sie uns das Briefing, und wir erstellen das Bild über drei Jahre — einschließlich der Fälle, in denen die ehrliche Empfehlung lautet, stattdessen etwas zu kaufen. Sprechen Sie mit unserem Team; wir antworten innerhalb eines Werktags.