Dokumentation, die sich selbst schreibt

Das echte Ausmaß des Problems

Entwicklerinnen und Entwickler dokumentieren nicht, weil sie es nicht wollen — sondern weil die Dokumentation immer der nächste Schritt ist, der unter Zeitdruck wegfällt. Laut einer Analyse von CodeScene verbringen Entwickler durchschnittlich 13,5 Stunden pro Woche mit Problemen, die durch technische Schulden entstehen — ein erheblicher Anteil davon durch fehlende oder veraltete Dokumentation.

Für IT-Dienstleister und MSPs ist das Problem besonders teuer:

• Wissensverlust bei Personalwechsel: Die Kosten für den Ersatz eines Senior-Entwicklers liegen laut Schätzungen bei 50.000 bis 100.000 Euro — ein großer Teil davon sind stille Kosten durch das Wissen, das mit ihm geht. Netzwerkarchitekturen, Deployment-Eigenheiten, warum eine bestimmte Konfigurationsentscheidung vor zwei Jahren so getroffen wurde — das landet nirgendwo, wenn es nicht aktiv dokumentiert wird.
• Eskalationen durch undokumentierte Kundensysteme: Ein Techniker übernimmt einen Kunden vom Kollegen. Die Credentials sind in IT-Glue, aber warum der Kundenserver jeden Montag neu gestartet werden muss, steht nirgendwo. Der nächste Montagmorgen lehrt ihn das auf die harte Tour.
• Onboarding dauert Wochen statt Tage: Nicht weil neue Mitarbeitende langsam sind, sondern weil das institutionelle Wissen über die betreuten Systeme nicht zugänglich ist. Es sitzt bei zwei oder drei Personen im Team — und die haben ihre eigentliche Arbeit zu tun.
• Falsche Annahmen bei Projekten: Jemand macht eine Architekturentscheidung, ohne zu wissen, dass diese Diskussion vor 18 Monaten bereits geführt und aus gutem Grund anders entschieden wurde. Das Ergebnis ist doppelte Arbeit oder ein Fehler, der sich tief ins System eingräbt.

Laut Erhebungen von Atlassian verbringen Teams ohne funktionierendes Wissensmanagement rund 20 Prozent der Arbeitszeit mit Suchen, Wiederholen und Rückfragen. Für ein 10-köpfiges Entwicklerteam sind das zwei volle Personenstellen, die täglich im Leerlauf laufen.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Erfahrungswerte aus MSP- und IT-Dienstleister-Projekten (Stand 2025). Kein repräsentatives Sample, aber konsistente Beobachtung bei gut durchgeführten Rollouts.

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5) KI-gestützte Dokumentation spart 2–4 Stunden pro Woche je Entwicklerin — real, aber weniger dramatisch als beim Ticket-Autopilot, der täglich 1–3 Stunden direkt zurückgewinnt. Beim Dokumentationsassistenten ist der Effekt diffuser: weniger Suchzeit, weniger Rückfragen, schnellere Incidents — aber nichts, das sich in einem einzigen Messwert ablesen lässt. Nicht zu unterschätzen ist der kumulative Effekt: Was in Monat 1 kaum auffällt, ist nach einem Jahr ein erheblicher Produktivitätsgewinn.

Kosteneinsparung — niedrig (2/5) Die Einsparung ist real, aber schwer direkt zuzuordnen. Kürzere Onboarding-Zeit, weniger Eskalationen, weniger Wissensverlust bei Fluktuation — das hat alles einen Euro-Wert, aber er ist indirekt. Niemand bucht “fehlende Dokumentation” als Kostenposition, deshalb fehlt die direkte Vergleichsbasis. Anders als beim Ticket-Autopilot, wo du Ticket-Volumen direkt zählst und vergleichst, bleibt hier die Attribution schwierig.

Schnelle Umsetzung — gut (4/5) Das ist die eigentliche Stärke: Für den häufigsten Ansatz — GitHub-Integration plus LLM-gestützte Commit-Auswertung — brauchst du keine komplexen Systemintegrationen. Keine RMM-Anbindung, kein PSA-Mapping, keine kritische Infrastruktur, die du anfasst. Realistischer Zeitplan bis zum ersten produktiven Einsatz: 3–5 Wochen. Das ist im Vergleich zu den anderen IT-Dienstleister-Use-Cases das schnellste Ergebnis.

ROI-Sicherheit — mittel (3/5) Onboarding-Dauer und Incident-Lösungszeit sind messbar, aber nur wenn du sie vorher systematisch erfasst hast. Die meisten IT-Dienstleister tun das nicht — was den Vorher-Nachher-Vergleich schwierig macht. Wenn du den ROI-Beweis führen musst (gegenüber Geschäftsführung oder einem Investor), wird die Indirektheit zum Problem. In der Praxis reicht erfahrungsgemäß die Team-Wahrnehmung: „Wir finden Sachen deutlich schneller” ist nach 3 Monaten oft der überzeugendste Beweis.

Skalierbarkeit — sehr hoch (5/5) Das ist der stärkste Aspekt dieses Use Cases. Einmal eingerichtet, skaliert der Dokumentationsassistent kostenlos mit: Jedes neue Kundenprojekt, jedes neue Repository, jedes neue Team-Mitglied profitiert sofort von der bestehenden Wissensbasis — ohne dass jemand extra Arbeit investiert. Kein anderer Use Case in dieser Kategorie hat diese Eigenschaft so ausgeprägt. Ein Ticket-Autopilot braucht für jeden neuen Kunden neue Integrationen; eine Wissensdatenbank wächst einfach weiter.

Richtwerte — stark abhängig von Teamgröße, Dokumentationsrückstand und Technologiestack.

Was der Dokumentationsassistent konkret macht

Es gibt zwei sehr unterschiedliche Varianten, die oft verwechselt werden:

Variante 1: Bestehende Artefakte auswerten Das KI-System verbindet sich mit GitHub/GitLab und liest Commit-Messages, Pull-Request-Beschreibungen, Merge-Notizen und Deployment-Logs. Aus diesen rohen Informationen generiert es strukturierte Dokumentation: Was wurde geändert? Warum? Welche Komponenten sind betroffen? Das Ergebnis landet automatisch in Confluence, Notion oder einem anderen Wiki. Der Entwicklerin bleibt das Schreiben erspart — sie reviewt und korrigiert den Entwurf.

Variante 2: Interaktive Wissensextraktion Der Assistent stellt gezielte Rückfragen während oder kurz nach der Arbeit. Nach einem Deployment: „Du hast gerade die Datenbankverbindung geändert — soll ich das als Architekturentscheidung dokumentieren?” Nach einem langen Slack-Thread: „Ihr habt euch für Redis als Cache entschieden — soll ich die Entscheidungsgründe zusammenfassen?” Das klingt kleiner als es ist: Viele wichtige Architekturentscheidungen entstehen informell in Chat-Nachrichten und verschwinden spurlos.

Für MSPs gilt eine dritte Dimension: Kundensystemdokumentation. IT-Glue und Hudu können mit RMM-Tools (NinjaRMM, Datto) verbunden werden und scannen Kundensysteme automatisch — welche Geräte sind im Netz, welche Betriebssystemversionen, welche Software. Das ersetzt nicht die menschliche Dokumentation von Konfigurationsentscheidungen, aber es hält den Gerätestand automatisch aktuell.

Was das System nicht kann: Es erfindet kein Wissen. Wenn eine Architekturentscheidung nie diskutiert wurde — weder in Code-Kommentaren, noch im Slack, noch in Commits — dann kann kein KI-Assistent sie dokumentieren. Das ist die wichtigste Einschränkung: Der Assistent ist so gut wie das, was er lesen kann.

Konkrete Werkzeuge — was wann passt

IT-Glue — der MSP-Standard IT-Glue ist die meistgenutzte Dokumentationsplattform bei Managed Service Providern weltweit. Stärke: Strukturierte Kundendokumentation mit Asset-Tracking, Passwort-Management und Netzwerkdiagrammen. Cooper Copilot, die KI-Funktion, generiert SOPs aus vorhandenen Tickets und schlägt Wissenslücken vor. Integration in ConnectWise, Autotask, NinjaRMM. Preislich der teuerste Ansatz: ab 29 USD/Nutzer/Monat, Mindest-5-Nutzer-Pflicht. Einschränkung: US-Datenhaltung, kein EU-Hosting.

Hudu — die günstigere Alternative mit EU-Hosting Für kleinere MSPs (1–10 Techniker) ist Hudu die attraktivste Alternative. Kein Nutzer-Minimum, keine Setup-Gebühr, und — entscheidend für DSGVO-bewusste IT-Dienstleister — Self-Hosting-Option. Das bedeutet: Betrieb auf eigenem Server oder EU-Cloud (Hetzner, IONOS), vollständige Datenkontrolle. Der Funktionsumfang ist schlanker als IT-Glue, aber für die meisten kleinen MSPs ausreichend.

GitHub Copilot — für Entwicklungsabteilungen Nicht primär ein Dokumentationstool, aber eine der praktischsten Quellen für automatische Code-Dokumentation. Copilot generiert auf Wunsch Docstrings, erklärt unkommentierte Funktionen und schreibt README-Entwürfe. Wer bereits GitHub Copilot im Einsatz hat, braucht keinen separaten Dokumentationsassistenten für die Code-Ebene. Kosten: 19 USD/Nutzer/Monat (Individual), ab 39 USD/Monat (Business).

Confluence mit Atlassian-KI Für IT-Dienstleister, die bereits im Atlassian-Ökosystem arbeiten (Jira für Tickets), ist Confluence die naheliegende Wissensplattform. Atlassian-KI (in bezahlten Plänen enthalten) hilft beim Erstellen von Zusammenfassungen, Seiten-Entwürfen und Action-Item-Listen. Die Integration mit Jira-Tickets ist ein echter Vorteil: Gelöste Tickets können direkt als Basis für Runbooks dienen. Kosten: Standard ab 6,40 USD/Nutzer/Monat, Premium ab 12,30 USD/Nutzer/Monat.

Notion AI — für kleinere Teams ohne Atlassian Für IT-Dienstleister mit unter 15 Mitarbeitenden, die kein Atlassian-Ökosystem betreiben, ist Notion AI eine leichtgewichtigere Alternative. Notion AI hilft beim Erstellen von Seiten, Zusammenfassungen und Dokumentenstrukturen. Einschränkung: weniger MSP-spezifische Strukturen als IT-Glue oder Hudu, keine RMM-Integration. Preis: ab 20 Euro/Person/Monat (Business-Plan).

Zusammenfassung: Welcher Ansatz für wen

• MSP mit 5+ Technikern, vorwiegend Kundendokumentation → IT-Glue
• Kleiner MSP (1–5 Personen), DSGVO-sensibel oder Budget-bewusst → Hudu Self-Hosted
• Entwicklungsnaher IT-Dienstleister mit aktivem GitHub-Einsatz → GitHub Copilot + Confluence
• Kleinteam ohne Atlassian, gemischte Dokumentationsanforderungen → Notion AI

Datenschutz und Datenhaltung

Interne technische Dokumentation enthält selten direkte personenbezogene Daten — aber Kundendokumentation tut das fast immer: IP-Adressen, Zugangsdaten, Systemkonfigurationen, Kontaktdaten von Ansprechpartnern. Sobald ein KI-System diese Daten liest oder verarbeitet, gilt die DSGVO vollumfänglich.

Die kritischste DSGVO-Frage für MSPs: Darf ich Kundendaten an einen US-amerikanischen KI-Dienst weitergeben? Die Antwort ist rechtlich komplex und hängt von deinen Kundenverträgen und dem eingesetzten Tool ab.

Klare Handlungsempfehlungen:

• IT-Glue und GitHub Copilot: US-Datenhaltung. Auftragsverarbeitungsvertrag (AVV) verfügbar und muss vor Produktivbetrieb abgeschlossen werden. Prüfen, ob eure Kundenverträge die Weitergabe an US-Anbieter erlauben.
• Hudu Self-Hosted auf EU-Server: DSGVO-sicherster Ansatz. Kein AVV mit Hudu notwendig, vollständige Datenkontrolle. Betriebsaufwand für eigene Infrastruktur einplanen.
• Confluence Cloud: Atlassian bietet EU-Datenresidenz für zahlende Kunden — aktiv konfigurieren, nicht automatisch aktiv.
• Für besonders sensible Kundendaten (z.B. Kunden aus Gesundheitswesen oder Finanzsektor): Vor Einsatz eines cloudbasierten KI-Tools Rücksprache mit Datenschutzbeauftragten oder Anwalt empfehlenswert.

Wichtig: Viele MSPs betreiben heute schon US-cloudbasierte Tools (Microsoft 365, Google Workspace) und haben einen AVV — dann ist IT-Glue kein grundsätzliches neues Datenschutzproblem, sondern eine weitere Kategorie, die unter bestehende Rahmenvereinbarungen fällt.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

• GitHub-Integration und erste Dokumentationsregeln konfigurieren: ca. 3–8 Tage interner Aufwand
• Bestehende Dokumentation sichten und migrieren: stark abhängig vom Rückstand — 1 Woche bis mehrere Monate
• Externe Einrichtungsunterstützung: 1.500–4.000 Euro für einen geführten Rollout mit Integration

Laufende Kosten (monatlich, 5-köpfiges Team)

• IT-Glue: 145–200 USD/Monat (5 Nutzer)
• Hudu Cloud: ca. 80–120 USD/Monat (5 Nutzer)
• GitHub Copilot Business: 195 USD/Monat (5 Nutzer)
• Confluence Standard + Atlassian-KI: ca. 40–60 EUR/Monat (5 Nutzer)

Wie du den Nutzen tatsächlich misst Vor dem Rollout diese drei Kennzahlen aufnehmen: (1) Onboarding-Dauer neuer Entwickler bis zur eigenständigen Arbeit, (2) durchschnittliche Incident-Lösungszeit bei unbekannten Systemen, (3) Anzahl Eskalationen pro Woche, bei denen jemand einen Kollegen fragen musste weil etwas nicht dokumentiert war. Nach 3 Monaten erneut messen. Das sind die einzigen Zahlen, die du brauchst.

Was du dagegenrechnen kannst Ein Senior-Entwickler mit 70.000 Euro Jahresgehalt kostet brutto etwa 43 Euro pro Stunde. Wenn vier Entwicklerinnen im Team täglich je 30 Minuten weniger mit Suchen, Rückfragen und Wiederholen verbringen: Das sind 2 Stunden täglich, rund 40 Stunden im Monat — ein Geldwert von ca. 1.700 Euro/Monat. Im konservativen Szenario (50 Prozent davon tatsächlich realisiert): immer noch 850 Euro/Monat, die die Werkzeugkosten von 80–200 Euro/Monat deutlich übersteigen. Die Rechnung stimmt schon bei kleinen Teams. Was sie nicht abbildet: der Wert des verhinderten Wissensverlusts bei Personalwechsel — das ist in der Praxis oft der entscheidendere Faktor.

Drei typische Einstiegsfehler

1. Alle bestehenden Dokumente gleichzeitig migrieren. Der Impuls: Jetzt ist der Zeitpunkt, alles aufzuräumen — das alte Confluence, die OneNote-Sammlung, die Dokumente auf dem Netzlaufwerk. In der Praxis versickert das Projekt genau hier: Die Migration dauert Wochen, das Team verliert die Motivation, und am Ende ist das neue System auch nicht aktueller als das alte. Besserer Ansatz: Mit drei bis fünf kritischen Dokumenten starten — die Runbooks für die häufigsten Incidents, das Deployment-Playbook für den wichtigsten Kunden. Die KI hilft dann, diese zu strukturieren und zu erweitern, statt alten Ballast zu transportieren.

2. Den Dokumentationsassistenten als Einmallösung behandeln. „Wir richten das ein, dann läuft es.” Nein. Ein KI-Dokumentationssystem braucht aktive Pflege: Jemand muss KI-Entwürfe reviewen, veraltete Seiten markieren, und entscheiden, welche neuen Systemänderungen dokumentiert werden sollen. Ohne diese Rolle — eine Person mit 20–30 Prozent ihrer Zeit — entsteht nach 12 Monaten eine Wissensbasis, die zwar vollständiger als vorher ist, aber trotzdem veraltet und unkontrolliert wächst. Die Qualität des Systems ist eine Funktion des Pflegeaufwands, nicht der initialen Einrichtung.

3. Meinen, dass die KI das undokumentierte Wissen kennt. Dieser Fehler passiert beim allerersten Test: Jemand fragt den Assistenten nach dem Deployment-Prozess — und bekommt eine leere Antwort oder eine Antwort auf Basis von zwei Jahre alten, widersprüchlichen Dokumenten. Daraus wird der Schluss gezogen: „Funktioniert nicht.” Tatsächlich funktioniert das System korrekt — es gibt zurück, was vorhanden ist. Das Problem ist, dass das Wissen hauptsächlich in Köpfen sitzt und nie dokumentiert wurde. Der Rollout eines Dokumentationsassistenten ist auch ein Anlass, dieses implizite Wissen explizit zu machen. Das dauert länger als erwartet und muss als eigener Projektschritt eingeplant werden.

Was mit der Einführung wirklich passiert — und was nicht

Die häufigste Enttäuschung: Das neue System ist nach vier Wochen nicht die vollständige, aktuelle Wissensbasis, die sich alle erhofft haben. Das liegt nicht am Tool — es liegt daran, dass die Hoffnung unrealistisch war.

Was realistisch passiert in den ersten drei Monaten:

Die zwei oder drei Personen im Team, die ohnehin gut dokumentieren, adoptieren das System sofort. Sie schreiben besser strukturierte Seiten, nutzen KI-Vorschläge als Ausgangspunkt, und sind die ersten, die sehen: Das spart Zeit. Der Rest des Teams ist abwartend. Sie nutzen das System zum Lesen, aber nicht zum Schreiben.

Was typischerweise auffällt nach Monat 2: Das System hat eine klare Lücke. Fast immer dieselbe: Die Deployment-Prozesse für drei von fünf Kunden sind dokumentiert, für die anderen zwei nicht. Das ist der Moment, wo eine bewusste Entscheidung nötig ist: Macht das Team eine explizite Session, um diese Lücken zu schließen — oder bleibt es bei den zwei nicht dokumentierten Kunden?

Was konkret hilft:

• Beim Launch eine Team-Session durchführen: Jede Person benennt die drei Fragen, die sie am häufigsten gestellt bekommt. Diese Antworten werden als erste Dokumente eingerichtet.
• Eine Person als Dokumentations-Owner benennen, die KI-Entwürfe reviewt und freigibt. Diese Rolle braucht klare Zeit im Kalender — keine Aufgabe „nebenbei”.
• Wöchentlich im Team-Meeting: Welche Systeme haben sich diese Woche geändert, ohne dass es dokumentiert wurde? Drei Minuten, aber konsistent über Monate.

Was nicht passiert: Das Team schreibt keine Dokumentation mehr manuell. Das ist eine Übererwartung, die regelmäßig für Frust sorgt. Der Assistent generiert Entwürfe, keine fertigen Dokumente. Jemand muss sie prüfen, ergänzen und freigeben. Der Aufwand sinkt erheblich — aber er verschwindet nicht.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

„Dafür haben wir keine Zeit.” Das ist der ehrlichste Einwand — und der schwierigste. Schlechte Dokumentation ist ein klassisches Produktivitätsproblem, das sich selbst perpetuiert: Weil niemand Zeit hat, fällt Dokumentation weg. Weil keine Dokumentation da ist, dauern Onboarding, Incidents und Übergaben länger. Dadurch hat niemand Zeit. Der Ausweg ist nicht, mehr Zeit zu finden — sondern anzuerkennen, dass der Dokumentationsrückstand aktiv Zeit kostet. Wer das konkret beziffert (wie oben gerechnet), findet die Entscheidung leichter.

„Unsere Systeme sind zu komplex für automatische Dokumentation.” Das Gegenteil ist der Fall: Komplexe Systeme profitieren am stärksten, weil manuelles Dokumentieren bei Komplexität als erstes aufgegeben wird. Die KI braucht keine Vereinfachung — sie liest Commits, Logs und Konfigurationsdateien so, wie sie sind. Der erste Entwurf ist oft überraschend vollständig.

„Wenn der Assistent etwas Falsches schreibt, ist das gefährlicher als keine Dokumentation.” Das ist eine legitime Sorge. Die Antwort ist der Review-Prozess: Kein KI-Entwurf geht ohne menschliche Prüfung in die offizielle Wissensbasis. Der Assistent generiert, eine Person verifiziert, dann wird es freigegeben. Dieser Schritt darf nicht wegfallen — deshalb ist der Documentation-Owner eine Pflichtrolle, keine Option.

Woran du merkst, dass das zu dir passt

• Du hast ein Team mit 5+ Entwicklerinnen oder Technikern, und das Onboarding neuer Personen dauert mehr als 2 Wochen, weil das Wissen über Systeme nicht zugänglich ist
• Du betreust mehrere Kundenmandanten als MSP, und bei Techniker-Wechsel gibt es regelmäßig Wissenslücken, die durch Eskalationen oder Fehler sichtbar werden
• Du verlierst durch Fluktuation aktiv Wissen: Wenn ein Entwickler geht, geht ein Teil der Systemkenntnisse mit — und das kostet Geld und Zeit für Nachfolger und Kunden
• Incidents dauern zu lange, weil Systeme nicht dokumentiert sind und der nächste On-Call-Dienst erst 30 Minuten recherchiert, bevor er die richtige Person anruft
• Ihr Deployment-Prozess ist im Kopf von einer Person, nicht in einem Runbook — und diese Person ist immer das Nadelöhr bei Releases

Wann es sich noch nicht lohnt — drei harte Ausschlusskriterien:

1. Team unter 4 Personen, weniger als 3 betreute Kundensysteme. Der Einrichtungsaufwand übersteigt den Nutzen. Ein geteiltes Dokument in Notion oder Confluence reicht vollständig — ohne KI, dafür mit konsistenter Pflege.

2. Das Wissen sitzt zu 80 Prozent in Köpfen, nicht in Artefakten. Wenn es keine Commits, keine Tickets, keine Slack-Entscheidungen gibt, die der Assistent lesen kann, kann er nichts generieren. Dann ist der erste Schritt nicht ein KI-Tool, sondern eine Dokumentations-Kultur: regelmäßige Wissens-Sessions, kurze Runbook-Entwürfe nach jedem Incident, Entscheidungsnotizen in Ticket-Kommentaren. Das dauert 3–6 Monate, bevor ein KI-Assistent sinnvoll eingesetzt werden kann.

3. Keine Person verfügbar, die Dokumentation aktiv pflegt. Eine Wissensbasis ohne Owner veraltet in Monaten. Der Assistent generiert neue Einträge, aber er löscht keine veralteten — und er merkt nicht, wenn eine Architektur sich geändert hat, die Dokumentation aber noch die alte Version beschreibt. Das Ergebnis nach 18 Monaten ohne aktive Pflege ist eine Wissensbasis, die selbstbewusst falsche Informationen liefert.

Das kannst du heute noch tun

Öffne GitHub Copilot (kostenloser Testzugang für 30 Tage) oder Notion AI und wähle ein konkretes, undokumentiertes System aus eurem Betrieb — am besten eins, das in letzter Zeit für Rückfragen gesorgt hat. Gib dem Assistenten die letzten 10 Commit-Nachrichten aus diesem Repository und frag ihn, eine erste Beschreibung des Systems zu erstellen.

Das dauert 20 Minuten. Was du danach weißt: ob der Ansatz für euren Technologiestack funktioniert — und wie gut eure bisherigen Commit-Messages als Dokumentations-Grundlage taugen.

Für den strukturierten Einsatz — Runbooks, Deployment-Playbooks, Incident-Leitfäden — hier ist ein Prompt, den du direkt verwenden kannst:

Quellen & Methodik

• Entwickler verbringen 13,5 Stunden/Woche mit technischen Schulden: CodeScene, „Code Health Study” (2023). Dokumentationsmangel ist ein Subkategorie-Treiber dieser Zahl, keine separate Erhebung.
• Kosten für Entwickler-Fluktuation (50.000–100.000 EUR): The Ash Group, „The True Costs of IT Turnover and Vacancy” (2024); bestätigt durch branchenübliche HR-Berechnungsmodelle (1–2x Jahresgehalt für Vollkostenberechnung).
• 20 Prozent Arbeitszeit für Suchen und Rückfragen: Atlassian, „State of Teams” (2023); McKinsey Global Institute, „The social economy” (2012) — bestätigt ähnliche Größenordnung für wissensintensive Rollen.
• Onboarding-Benchmarks und Incident-Lösungszeiten: Erfahrungswerte aus IT-Dienstleister-Projekten (Stand 2025). Kein repräsentatives Sample.
• IT-Glue-Preise: itglue.com, veröffentlichte Tarife (Stand April 2026). Kaseya-Übernahme 2021 hat Preisstruktur verändert.
• Hudu-Preise: usehudu.com, veröffentlichte Tarife (Stand April 2026).
• GitHub Copilot Produktivitätsdaten (55 % schneller): GitHub-eigene Studie (2022), unabhängig repliziert mit ähnlichen Größenordnungen. Vendor-Zahlen — in der Praxis stark kontextabhängig.

Willst du wissen, welcher Ansatz für euren Technologiestack und eure Kundenmandanten konkret passt? Meld dich — das klären wir in 30 Minuten gemeinsam.