Individualsoftware: Definition, Beispiele und was im Vertrag stehen muss

Individualsoftware ist Software, die für genau ein Unternehmen entsteht — und nicht für einen Markt. Wer den Begriff sucht, landet allerdings fast immer bei einem Anbieter, der sie verkaufen möchte. Deshalb lesen sich die meisten Seiten gleich: Vorteile, Ablauf, Kontaktformular. Die Fragen, an denen Projekte tatsächlich scheitern, stehen dort selten. Dieser Artikel beantwortet sie. Den Gesamtrahmen dazu liefert unser Leitfaden zur Digitalisierung im Mittelstand.

Was ist Individualsoftware?

Wikipedia definiert Individualsoftware als Anwendungssoftware, die spezifisch für einen bestimmten Anwender entsteht. Das Gabler Wirtschaftslexikon ergänzt die betriebliche Sicht: entwickelt für den Einsatz in einem speziellen Betrieb, entweder selbst erstellt oder extern beauftragt. Beide Definitionen zielen auf denselben Kern — Maßschneiderung für einen einzigen Auftraggeber.

Deutlich präziser wird das BSI im IT-Grundschutz-Baustein APP.7 „Entwicklung von Individualsoftware”. Es unterscheidet zwei Ausprägungen: individualisierte Basislösungen und komplette Neuentwicklungen. Bei der ersten passen Entwickler eine Standardanwendung — etwa ein ERP- oder CMS-System — grundlegend an und erweitern sie um eigene Funktionen. Bei der zweiten entsteht alles von Grund auf neu.

Diese Unterscheidung ist keine Wortklauberei. Sie bestimmt, worüber Sie überhaupt verhandeln. Ein Beispiel: Erweitert ein Dienstleister Ihr bestehendes ERP um ein eigenes Modul, gehört Ihnen am Ende dieses Modul — nicht das ERP darunter. Wer beides in einem Satz „Individualsoftware” nennt, verhandelt über zwei völlig verschiedene Dinge. Vor jedem Vertrag steht deshalb die Frage, welcher der beiden Fälle vorliegt.

Im Sprachgebrauch kursieren dafür mehrere Synonyme: maßgeschneiderte Software, Eigenentwicklung, Custom Software, Individuallösung. Gemeint ist jeweils dasselbe.

Individualsoftware, Standardsoftware, Branchensoftware — die Abgrenzung

Drei Begriffe geraten regelmäßig durcheinander. Standardsoftware entsteht für einen anonymen Markt und wird vielfach lizenziert; Sie passen sich ihr an. Individualsoftware entsteht für einen einzigen Auftraggeber; sie passt sich Ihnen an.

Dazwischen liegt der oft übersehene Mittelweg: Branchensoftware. Technisch ist sie Standardsoftware, fachlich jedoch auf eine enge Nische zugeschnitten — beispielsweise auf Bäckereien, Kfz-Werkstätten oder Arztpraxen. Der Anbieter lizenziert sie an viele Unternehmen derselben Branche und erzielt dadurch Skaleneffekte. Für den Käufer bedeutet das: viel fachliche Passung ohne Entwicklungsaufwand, aber weiterhin fremde Roadmap und fremde Prioritäten.

Genau hier entscheidet sich in der Praxis viel. Wer Branchensoftware übersieht, vergleicht nur zwei Extreme und übersieht die Option in der Mitte. Wie die Abwägung im Detail ausfällt und wo welche Seite gewinnt, lesen Sie in unserem Beitrag zu den Vorteilen von Individualsoftware im Vergleich zu Standardlösungen.

Individualsoftware Beispiele aus der Praxis

Definitionen bleiben abstrakt. Deshalb hier drei Projekte aus unserer eigenen Arbeit — jeweils mit der Frage, warum ein fertiges Produkt nicht ausgereicht hat.

Elektroplanung im Hausbau. Elektroinstallateure planen Steckdosen, Schalter und Leitungen bis heute oft auf Papierplänen. Jede Änderung des Bauherrn bedeutet Radieren, Nachrechnen, neues Angebot. CAD-Programme können zwar zeichnen, kennen aber weder Preise noch Angebotslogik; Angebotssoftware wiederum kennt keine Baupläne. Zwischen beiden klaffte eine Lücke. Wir haben sie mit Elektromeister geschlossen: Planung direkt auf dem digitalen Bauplan, Preise und Angebot ändern sich in Echtzeit mit. Aus zwei getrennten Werkzeugen und einer manuellen Brücke dazwischen wurde ein Arbeitsschritt.

Qualitätsprüfung von Betonplatten. Bei der BraunBeton GmbH prüften Mitarbeiter Betonplatten per Sichtprüfung — stichprobenartig, ermüdend, schwankend. Standardsoftware für diese Aufgabe existiert nicht, denn Haarrisse und Oberflächenstörungen lassen sich nicht in starre Schwellwerte pressen. Unsere KI-Objekterkennung bei BraunBeton prüft stattdessen jede Platte im Fließbandtakt. Bemerkenswert ist dabei, wie viel Arbeit nicht im Modell steckte: Erst ein eigenes Gehäuse mit Lichtschutz schuf konstante Bedingungen in der Halle. Genau solche Anforderungen kauft man nirgends fertig.

Zellerkennung in der Forschung. In der biophysikalischen Zellforschung müssen Forschende Zellen in Aufnahmen erkennen und auswerten. Hier gab es kein Produkt am Markt, weil es den Markt nicht gibt — die Fragestellung existiert in dieser Form nur in diesem Labor. Individualsoftware ist in solchen Fällen keine Abwägung, sondern die einzige Option.

Ein Muster verbindet die drei Fälle: Nicht die Technik war jeweils das Schwierige, sondern das Verstehen des Prozesses. Wie sich Abläufe grundsätzlich digitalisieren und Prozesse automatisieren lassen, behandeln wir separat.

Wann Sie Individualsoftware lassen sollten

Vier Signale sprechen dagegen, ein Projekt überhaupt zu starten. Sie betreffen nicht die Software, sondern Ihre Fähigkeit, sie über Jahre zu tragen.

Es gibt keinen fachlichen Owner im Haus. Jemand muss die Anforderungen verantworten und entscheiden können — verbindlich, nicht im Konsens von sechs Abteilungen. Fehlt diese Person, scheitert das Vorhaben unabhängig vom Dienstleister. Kein Entwicklungspartner kann sie ersetzen.

Der Betrieb nach dem Go-Live ist nicht eingeplant. Die Frage ist hier rein budgetär: Ist Geld für die Zeit nach dem Launch reserviert, ja oder nein? Lautet die Antwort Nein, warten Sie, bis sie Ja lautet. Was das konkret bedeutet, steht weiter unten bei den Risiken.

Nur eine Person versteht den Prozess. Soll die Software einen Ablauf abbilden, den ausschließlich ein einziger Kollege durchdringt, dann bilden Sie dessen Gedächtnis ab — nicht Ihr Unternehmen. Fällt er aus, kann niemand prüfen, ob das Ergebnis stimmt. Klären Sie den Prozess zuerst, danach die Software.

Der Ablauf ändert sich nie. Anpassbarkeit ist der teuerste Teil von Individualsoftware und amortisiert sich nur über Änderungen. Wenn seit zehn Jahren niemand etwas geändert hat und auch niemand etwas ändern will, zahlen Sie für eine Eigenschaft, die Sie nie nutzen.

Die eigentliche Make-or-Buy-Abwägung führen wir an anderer Stelle: Make-or-Buy in fünf Kriterien behandelt sie im Detail.

Festpreis oder Time & Material? Die Vertragsmodelle

Das Vertragsmodell ist keine Formalie. Es verteilt das Risiko — und zwar bevor jemand weiß, wie groß das Risiko ist.

Modell	Wer trägt das Risiko	Passt, wenn
Festpreis	Auftragnehmer trägt das Realisierungsrisiko	Der Umfang steht vorab fest und ändert sich kaum.
Time & Material	Auftraggeber trägt Kosten- und Mengenrisiko	Der Weg ist offen und Sie steuern aktiv mit.
Agiler Festpreis (pro Sprint)	Beide Seiten teilen sich das Risiko	Der Rahmen steht, die Details entstehen unterwegs.

Beim klassischen Festpreis liegt das Realisierungsrisiko nahezu vollständig beim Auftragnehmer. Das klingt zunächst nach der sicheren Wahl. Der Haken: Jede Änderung Ihrerseits löst einen formalen Nachtragsprozess aus. Bei unklarem Umfang wird der Festpreis deshalb teuer — der Anbieter kalkuliert einen Aufschlag für alles, was er nicht wissen kann.

An dieser Stelle eine ehrliche Auskunft: Wie hoch dieser Aufschlag marktüblich ausfällt, lässt sich nicht seriös beziffern. Es existiert keine neutrale Primärquelle dazu. Zahlen, die dazu kursieren, stammen von Anbietern und spiegeln deren Sicherheitsbedürfnis wider, keinen Marktstandard.

Time & Material dreht die Verteilung um. Sie zahlen die geleisteten Stunden und tragen damit das Mengenrisiko, gewinnen aber volle Flexibilität. Der berechtigte Einwand lautet: Wo bleibt der Effizienzanreiz für den Dienstleister?

Hybride Modelle versuchen, beides zu verbinden. Beim agilen Festpreis vereinbaren die Parteien einen fixen Preis pro Sprint. Was das Team im Sprint nicht fertigstellt, liefert es auf eigene Kosten nach. Im Gegenzug dürfen Sie die Prioritäten vor jedem Sprint neu setzen. Eine bekannte Variante ergänzt „Money for nothing, change for free”: Sie tauschen Features bei gleichem Aufwand kostenfrei aus und dürfen das Projekt vorzeitig beenden, sobald weitere Funktionen keinen Nutzen mehr bringen — das Restbudget teilen beide Seiten.

Werkvertrag oder Dienstvertrag — der Unterschied, der im Streitfall zählt

Das BGB kennt für Projekte zwei Grundtypen. Der Werkvertrag nach § 631 BGB schuldet den Erfolg: ein funktionierendes, abnahmefähiges Werk. Der Dienstvertrag nach § 611 BGB schuldet dagegen nur die Tätigkeit.

Der Unterschied wird im Streitfall entscheidend. Beim Werkvertrag löst die Abnahme nach § 640 BGB alles Weitere aus: Fälligkeit der Vergütung, Gefahrübergang und Beginn der Gewährleistung. Beim Dienstvertrag existiert dieses Gewährleistungsregime nicht; bei Schlechtleistung bleiben nur Schadensersatzansprüche. Wer also „agil” arbeitet und den Vertragstyp offenlässt, überlässt die Einordnung im Zweifel einem Gericht.

Ein zweites Risiko betrifft Dienstverträge mit einzelnen Entwicklern. Sind diese in Ihre Arbeitsorganisation eingegliedert und weisungsgebunden, droht die Feststellung der Scheinselbstständigkeit — mit Nachzahlung sämtlicher Sozialversicherungsbeiträge und, bei Vorsatz, strafrechtlichen Folgen nach § 266a StGB. Eine zwischengeschaltete Ein-Personen-GmbH schützt davor nicht.

Immerhin: Scrum allein macht noch keinen Angestellten. Das LSG Baden-Württemberg entschied 2021, dass ein in Scrum-Formaten arbeitender Entwickler sehr wohl frei tätig sein kann — sofern er Arbeitspakete eigenverantwortlich übernimmt, seine Zeit frei einteilt und echtes unternehmerisches Risiko trägt. Entscheidend bleibt die gelebte Praxis, nicht der Papiervertrag.

Wem gehört der Quellcode?

Diese Frage stellen Kunden fast nie — und bereuen das fast immer. Die intuitive Annahme lautet: Ich habe bezahlt, also gehört er mir. Das deutsche Urheberrecht sieht das anders.

Schafft ein Arbeitnehmer Software in Erfüllung seiner Pflichten, fallen die ausschließlichen Nutzungsrechte automatisch dem Arbeitgeber zu (§ 69b UrhG). Beauftragen Sie dagegen einen externen Dienstleister, greift dieses Privileg nicht. Dann müssen die Rechte ausdrücklich per Vertrag nach § 31 UrhG auf Sie übergehen. Ohne Klausel gilt im Zweifel die Zweckübertragungslehre: Sie erhalten nur, was der Vertragszweck zwingend erfordert. Das kann deutlich weniger sein, als Sie erwarten.

Zwei Stufen sind zu unterscheiden. Ein einfaches Nutzungsrecht erlaubt Ihnen die Nutzung, während der Anbieter dieselbe Software weiter verwerten darf. Ein ausschließliches Nutzungsrecht sperrt ihn aus. Die amtlichen EVB-IT Erstellungs-AGB — der Vertragsstandard der öffentlichen Hand für individuell erstellte Software — formulieren hier weitreichend: dauerhaftes, unwiderrufliches, übertragbares Recht, den Code zu nutzen, zu bearbeiten und weiterzuentwickeln. Als Blaupause taugt das auch für ein KMU.

Eine scharfe Linie zieht der Standard allerdings bei vorbestehenden Teilen. Bringt der Dienstleister eigene Bibliotheken oder Frameworks mit, die vor dem Projekt existierten, erhalten Sie daran üblicherweise nur einfache Nutzungsrechte. Fragen Sie deshalb konkret nach: Welche Bausteine sind das, und bleibt die Software ohne sie lauffähig?

Open Source und Escrow: die zwei blinden Flecken

Ein dritter Punkt betrifft Open Source. Nahezu jede moderne Anwendung bindet fremde Bibliotheken ein, und diese sind keineswegs bedingungsfrei. Permissive Lizenzen wie MIT oder Apache verlangen im Wesentlichen die Nennung des Urhebers. Strenges Copyleft wie die GPL wirkt dagegen viral: Verbinden Sie GPL-Code mit eigenem Code zu einem abgeleiteten Werk und vertreiben es, müssen Sie Ihren eigenen Quellcode offenlegen. Lassen Sie sich deshalb eine Stückliste aller Komponenten geben — eine Software Bill of Materials.

Bleibt der Fall, dass der Anbieter selbst ausfällt. Für geschäftskritische Systeme empfiehlt das BSI in APP.7 die Hinterlegung des Quellcodes bei einem neutralen Treuhänder. Dieses Source-Code-Escrow gibt den Code frei, sobald ein definierter Fall eintritt — klassischerweise die Insolvenz. Wichtig dabei: Hinterlegt gehört nicht nur der Code, sondern die komplette Build-Umgebung.

Was passiert, wenn Sie den Anbieter wechseln wollen?

Irgendwann endet jede Geschäftsbeziehung — die Software läuft dann weiter. Ein Wechsel gelingt nur, wenn Sie ihn vorher vertraglich und technisch vorbereiten. Der Quellcode allein reicht dafür nicht.

Übergeben werden muss ein vollständiges Paket:

• Repository mit der aktuellen Version und der gesamten Commit-Historie, nicht als ZIP-Archiv.
• CI/CD-Pipelines, also die Skripte, mit denen aus dem Code ein lauffähiges Deployment entsteht.
• Betriebshandbuch (Runbook) mit Infrastruktur, Migrationsskripten sowie Architektur- und API-Dokumentation.
• Administrative Zugänge zu Hosting, Cloud-Providern und DNS.

Der Praxistest dafür ist unbequem, aber einfach: Kann ein fremdes Team allein mit diesen Artefakten die Software bauen und ausrollen? Wenn nicht, existiert der Exit nur auf dem Papier.

Wie lange eine geordnete Übergabe dauert, lässt sich nicht seriös beziffern: Zahlen dazu kursieren, stammen aber durchweg von Dienstleistern, die Wechselprojekte verkaufen. Belastbar ist nur die Richtung — eine Übergabe ist eine Projektphase, kein Termin. Planen Sie sie ein, bevor Sie sie brauchen. Sinnvoll ist außerdem ein Exit-Schedule im ursprünglichen Vertrag: eine Klausel, die den alten Anbieter gegen Vergütung zu Wissenstransfer und Support verpflichtet. Nach der Kündigung verhandelt es sich darüber deutlich schlechter.

Zuletzt der Datenschutz. Verarbeitet der Dienstleister personenbezogene Daten, brauchen Sie einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO. Dieser regelt nicht nur die Verarbeitung selbst, sondern auch die Löschung aller Bestände nach dem Ende der Zusammenarbeit. Genau diese Löschklausel wird beim Wechsel relevant.

Woran erkennen Sie einen guten Entwicklungspartner?

Die Auswahl des Partners ist der größte Hebel für den Projekterfolg — größer als jede Technologieentscheidung. Vertriebsseitig klingen dabei alle Anbieter gleich. Fragen Sie deshalb nach Engineering-Praxis, nicht nach Referenzlogos.

• Wie wird getestet? Lassen Sie sich die Testabdeckung zeigen, nicht beschreiben. „Wir testen natürlich” ist keine Antwort.
• Wie wird deployt? Ein Deployment sollte ein automatisierter, wiederholbarer Vorgang sein und keine Person mit besonderem Wissen erfordern.
• Wie wird dokumentiert? Fragen Sie nach einem echten Runbook aus einem laufenden Projekt.
• Wie sieht die Übergabe aus? Stellen Sie diese Frage vor der Vergabe, nicht danach — was dazugehört, steht oben im Abschnitt zum Anbieterwechsel.

Ein Warnsignal ist der Satz „wir machen alles”. Wer jede Technologie beherrscht, beherrscht keine davon tief. Wir selbst arbeiten deshalb bewusst mit einem schmalen Stack; warum wir fast nur unseren Tech-Stack verwenden, haben wir aufgeschrieben. Ein Anbieter mit klarem Stack sagt Ihnen auch ehrlich, wann er nicht der Richtige ist.

Neu hinzugekommen ist eine Frage, die es vor drei Jahren nicht gab: Wie geht der Partner mit KI-generiertem Code um? Ohne Review-Disziplin entsteht dabei Code, den niemand im Team wirklich verstanden hat — wir nennen das Shadow Tech Debt. Übergeben lässt sich so etwas kaum.

Diese Kriterien gelten ausdrücklich auch gegen uns. Prüfen Sie Neckar IT an denselben Fragen. Ein Anbieter, dessen Auswahlkriterien nur bei ihm selbst aufgehen, hat sie sich passend gemacht.

Welche Risiken hat Individualsoftware?

Nach der Entscheidung beginnt der Teil, den Anbieterseiten gerne auslassen. Drei Risiken sollten Sie kennen — jeweils mit der passenden Gegenmaßnahme.

Budgets reißen, und zwar systematisch. Die oft zitierten CHAOS-Zahlen der Standish Group taugen dafür nicht als Beleg; ihre Methodik gilt in der Fachwelt als intransparent. Belastbarer ist die Langzeitstudie der Universität Oxford mit McKinsey. Sie untersuchte über 5.400 große IT-Projekte und fand: 45 Prozent Budgetüberschreitung im Schnitt, 7 Prozent Zeitverzug und 56 Prozent weniger Nutzen als im Business Case versprochen. Rund 17 Prozent entgleisen völlig, mit Überschreitungen von 200 bis über 400 Prozent. Die Ursachen sind selten technisch: unklare Ziele, wucherndes Scope Creep, fehlende Steuerung. Gegenmaßnahme: kleine Inkremente, die früh produktiv gehen.

„Fertig” gibt es nicht. Software altert, auch wenn niemand sie anfasst: Betriebssysteme wechseln, angebundene Schnittstellen ändern sich, Sicherheitslücken werden bekannt. Über den Lebenszyklus verschlingt die Wartung deshalb 60 bis 80 Prozent der Gesamtkosten — die Entwicklung ist der kleinere Teil. Wer nur die Erstellung budgetiert, hat je nach Lebensdauer ein Fünftel bis zwei Fünftel des Vorhabens finanziert. Gegenmaßnahme: Wartung von Beginn an als Posten führen.

Wissen konzentriert sich auf Köpfe. Kennt beim Dienstleister nur ein Entwickler das System, ist sein Urlaub Ihr Risiko und seine Kündigung Ihr Problem. Fragen Sie deshalb, wer außer dieser Person das Projekt trägt. Gegenmaßnahme: Code-Reviews im Team und Dokumentation als Lieferbestandteil, nicht als Geste.

Und ja, es entsteht Abhängigkeit. Das ist kein Argument gegen Individualsoftware, sondern eines für einen vorbereiteten Exit.

Wird Individualsoftware durch KI und Low-Code billiger?

Kurz gesagt: Der Preis verschiebt sich, er verschwindet nicht. KI-Assistenten beschleunigen das Schreiben von Code erheblich. Schreiben war jedoch nie der teure Teil.

Die Daten dazu sind mittlerweile eindeutig. Eine empirische Untersuchung von über 300.000 KI-generierten Commits fand, dass ohne Prüfroutinen 22,7 bis 24,2 Prozent der eingeführten technischen Schulden dauerhaft im Produktionscode überleben. Der DORA-Report beobachtet parallel, dass steigende KI-Adoption mit sinkender Delivery-Stabilität einhergeht. Und eine METR-Studie zeigt eine deutliche Lücke zwischen gefühlter und gemessener Produktivität bei komplexen Codebasen. Das Fraunhofer IESE ordnet die Befunde zwischen Produktivitätsschub und Vertrauenskrise ein.

Low-Code verschiebt die Grenze ähnlich. Anwendungen entstehen schneller, dafür wandert die Abhängigkeit von der eigenen Codebasis zur Plattform des Anbieters. Die Exit-Frage aus dem Abschnitt oben stellt sich damit erneut, nur mit anderem Vorzeichen.

Was KI also verändert, ist die Tippgeschwindigkeit. Was sie nicht verändert: Jemand muss den Prozess verstehen, jemand muss das Ergebnis verantworten, und jemand muss das System in fünf Jahren noch betreiben können. Diese drei Posten machen den Großteil der Kosten aus — und sie stehen alle im Vertrag, nicht im Editor.

Fazit

Individualsoftware ist kein Technologiethema. Die Technik ist heute selten das Problem; der Vertrag ist es. Ob Ihr Projekt trägt, entscheidet sich an vier Fragen: Wer trägt welches Risiko im Abrechnungsmodell? Wem gehören am Ende der Code und die Rechte daran? Wie kommen Sie wieder heraus? Und wer betreibt das System, wenn der erste Entwickler nicht mehr da ist?

Klären Sie diese Punkte, bevor die erste Zeile Code entsteht. Danach werden sie teuer. Prüfen Sie uns ruhig an den Kriterien aus diesem Artikel — genau dafür stehen sie hier. Wenn Sie Ihr Vorhaben einordnen möchten, sprechen Sie mit uns in einer kostenlosen Erstberatung.

Dieser Artikel dient ausschließlich der allgemeinen Information und stellt keine Rechtsberatung dar. Die dargestellten Regelungen des Vertrags-, Urheber- und Datenschutzrechts sind vereinfacht; die Beurteilung eines konkreten Vertrags hängt stets vom Einzelfall ab. Trotz sorgfältiger Recherche (Stand: 16. Juli 2026) übernehmen wir keine Haftung für Richtigkeit, Vollständigkeit oder Aktualität. Für die rechtsverbindliche Gestaltung und Prüfung von Software-, Nutzungsrechts- und Auftragsverarbeitungsverträgen wenden Sie sich an eine Rechtsanwältin oder einen Rechtsanwalt für IT-Recht.