Fallbeispiel · Tendenziell Routine

Routinemäßige Wartung, Bugfixing und UI-Anpassungen

Dieses Beispiel beschreibt ein typisches, generisches technisches Muster — keinen realen Kundenfall — zur Veranschaulichung der Förderlogik bei Softwarevorhaben.

Ausgangslage

Ein Softwareunternehmen pflegt eine bereits produktiv eingesetzte Anwendung: Es behebt gemeldete Fehler, passt die Benutzeroberfläche an aktuelle Bedienkonventionen an und aktualisiert verwendete Bibliotheken auf neuere Versionen. Diese Tätigkeiten sind Teil des laufenden Betriebs und folgen etablierten, dokumentierten Vorgehensweisen der Softwareentwicklung.

Warum das tendenziell nicht förderfähig ist

Bugfixing, UI-Anpassungen und Bibliotheks-Updates lösen kein offenes technisches Risiko — die Vorgehensweise zur Fehlerbehebung und Aktualisierung ist bereits etablierte Praxis und gehört zum Stand der Technik der Softwareentwicklung. Auch wenn einzelne Fehler komplex zu diagnostizieren sein können, entsteht dabei keine neue technische Erkenntnis, die über das bereits vorhandene fachliche Wissen hinausgeht — der geforderte Neuheitsgrad fehlt.

Was stattdessen infrage kommt

Laufende Wartungskosten sind grundsätzlich Teil des regulären Betriebsaufwands und werden nicht über FuE-Förderung, sondern gegebenenfalls über andere Instrumente adressiert. Enthält ein einzelner Wartungsvorgang ausnahmsweise einen eigenständigen Entwicklungsanteil — etwa weil ein grundlegend neues Verfahren zur Fehlerdiagnose in einem komplexen verteilten System entwickelt werden muss —, kann dieser Anteil separat betrachtet werden. Mehr zur grundsätzlichen Abgrenzung auf der Themenseite Software und Digitalisierung.

Zum Vergleich: das Gegenstück

Würde dasselbe Unternehmen stattdessen eine grundlegend neue Systemarchitektur für ein bislang ungelöstes Skalierungsproblem entwickeln, läge in der Regel eine förderfähige Entwicklungstätigkeit vor — siehe das Gegenbeispiel Grundlegend neue Softwarearchitektur mit technischem Neuheitsgehalt.

Häufige Fragen zu diesem Fallbeispiel

Was, wenn ein Bug besonders schwer zu finden und die Diagnose sehr aufwendig war?

Der Aufwand einer Fehlerdiagnose ist förderrechtlich nicht das entscheidende Kriterium — maßgeblich ist, ob dabei eine neue technische Erkenntnis entsteht, die über bereits bekannte Debugging- und Diagnosemethoden hinausgeht. Ein sehr zeitaufwendiger, aber mit etablierten Mitteln gelöster Fehler bleibt Routine, selbst wenn er das Team tagelang beschäftigt hat. Anders verhält es sich, wenn zur Diagnose ein grundlegend neues Analyseverfahren entwickelt werden muss, das über den Einzelfall hinaus einen eigenständigen technischen Beitrag darstellt — das ist jedoch die Ausnahme.

Zählen größere Refactoring-Projekte auch als Routine, wenn sie die gesamte Codebasis betreffen?

Der Umfang eines Refactorings allein ist nicht entscheidend — ein umfangreiches Refactoring, das ausschließlich bereits bekannte Entwurfsmuster auf bestehenden Code anwendet, bleibt förderrechtlich Routine, unabhängig von seiner Größe. Enthält das Refactoring jedoch die Entwicklung einer neuartigen strukturellen Lösung für ein bislang ungelöstes technisches Problem, etwa eine neue Form der Modularisierung für ein bislang nicht zufriedenstellend lösbares Skalierungsproblem, kann dieser Teil durchaus förderfähig sein. Die Grenze verläuft wie immer zwischen Anwendung bekannter Mittel und echter technischer Neuentwicklung.

Sollte ich Wartungsprojekte grundsätzlich gar nicht erst auf Förderfähigkeit prüfen?

Eine grundsätzliche, kurze Prüfung lohnt sich dennoch, da Wartungsprojekte gelegentlich einen abgrenzbaren, tatsächlich förderfähigen Entwicklungsanteil enthalten, der bei einer pauschalen Einstufung als „reine Wartung“ übersehen würde. Diese Prüfung sollte jedoch realistisch und ehrlich erfolgen, statt routinemäßige Tätigkeiten nachträglich als Forschung umzudeuten, was bei einer fachlichen Begutachtung ohnehin auffallen würde. Der Fördercheck hilft, diese Grenze im konkreten Einzelfall sachgerecht zu ziehen.

Ihr Softwarevorhaben mit ClausiusAI einordnen lassen

ClausiusAI prüft, ob in Ihrem Wartungs- oder Entwicklungsvorhaben ein eigenständiger, förderfähiger Anteil steckt, statt es pauschal als Routine einzustufen.

Schnellere Antragstellung
Der Antrag wird strukturiert vorbereitet, statt bei null anzufangen.
Strukturierter Prozess
Alle Angaben, Dokumente und offenen Punkte in einem gemeinsamen Online-Kooperationstool statt verstreuten E-Mails und Dateien.
Belastbarer Antragsinhalt
Ihr Unternehmenskontext und der wissenschaftlich-technische Hintergrund fließen in den Antrag ein, statt einer generischen Vorlage.
Passende Fördersumme
Förderfähige Kostenarten werden systematisch geprüft, statt Positionen zu übersehen.

Kostenlosen Fördercheck starten

Fallbeispiele aus der Praxis

Tendenziell förderfähig

Grundlegend neue Softwarearchitektur mit technischem Neuheitsgehalt

Eine neu entwickelte Systemarchitektur für ein bislang ungelöstes Skalierungsproblem — ein typisches Beispiel für förderfähige Softwareentwicklung.

Alle Fallbeispiele im Überblick: Fallbeispiele · Zum Thema: Software und Digitalisierung