Festpreis oder Aufwand: Was sollten wir vertraglich vereinbaren?

Für klar umrissene, gut planbare Projekte wie eine einzelne Schnittstelle oder ein definiertes Portal-Modul passt ein Festpreis, weil das Risiko beim Anbieter liegt und Sie ein verbindliches Budget haben. Bei Projekten mit offenem Umfang, etwa einer Anwendung, deren genaue Funktionen sich erst im Piloten zeigen, ist eine Aufwandsabrechnung mit klarem Stundenbudget je Etappe ehrlicher, weil ein Festpreis dort meist über Puffer oder nachträgliche Änderungswünsche teurer wird als offen kalkuliert. In der Praxis funktioniert eine Mischung am besten: Festpreis für den ersten, klar geschnittenen Pilotbereich, Aufwand mit Obergrenze je Etappe für den Ausbau danach. Lassen Sie sich in jedem Fall vor Projektstart einen verbindlichen Rahmen nennen, unabhängig vom Modell.

Wie groß muss ein Anbieter für unser Projekt sein?

Größer ist nicht automatisch besser, entscheidend ist die Passung zum Projekt. Ein kleines Projektteam oder ein Systemhaus mit eigener Entwicklung reagiert oft schneller und kennt nach dem ersten Auftrag Ihre Systeme bereits, eine große Agentur bringt dafür mehr parallele Kapazität für sehr große Vorhaben mit. Für die meisten Individualsoftware-Projekte im Mittelstand, ein Portal, eine Schnittstelle, ein internes Werkzeug, reicht ein kleines bis mittleres Team völlig aus, wenn es die beteiligten Systeme kennt. Wichtiger als die Teamgröße ist, ob derselbe Ansprechpartner Sie durch Konzept, Entwicklung und den Betrieb danach begleitet, statt dass das Projekt nach der Übergabe bei einem anderen Team landet.

Können wir mit unserem eigenen IT-Mitarbeiter statt eines externen Partners entwickeln?

Bei einem einzelnen, sehr spezifischen Werkzeug und einem IT-Mitarbeiter mit Entwicklungserfahrung durchaus. Die Grenze zeigt sich beim laufenden Betrieb: Wer entwickelt, muss die Lösung auch Jahre später warten, bei Urlaub oder Kündigung vertreten und bei Sicherheitslücken schnell reagieren können. Ein einzelner interner Entwickler ohne Vertretung ist dabei ein Risiko, das oft erst auffällt, wenn er ausfällt, etwa mitten in der Hochsaison, wenn niemand sonst den Code kennt. Externe Partner mit Teamstruktur federn das ab, weil im Urlaubs- oder Krankheitsfall ein Kollege einspringen kann, kosten dafür laufend mehr als eine interne Stunde. Für viele KMU ist deshalb eine Kombination sinnvoll: interne Fachkenntnis der Abläufe und Anforderungen, externe Entwicklung und Betreuung der technischen Umsetzung, mit klarer Aufgabenteilung von Anfang an.

Was, wenn wir mit dem gewählten Partner nicht mehr weiterarbeiten wollen?

Das sollte vor Projektstart vertraglich geklärt sein, nicht erst im Streitfall. Entscheidend sind drei Punkte: Ihnen gehören der vollständige Quellcode und alle Nutzungsrechte am Ergebnis, Sie erhalten eine Dokumentation, die auch ein anderer Entwickler versteht, und Zugänge zu Servern, Datenbanken und Diensten laufen auf Ihren eigenen Konten, nicht auf denen des Anbieters. Sind diese drei Punkte vertraglich gesichert, ist ein Wechsel unangenehm, weil Einarbeitungszeit beim neuen Partner anfällt, aber machbar, ohne dass Sie bei null anfangen. Fehlen sie, sitzen Sie im Zweifel fest, weil weder Code noch Zugänge ohne den bisherigen Partner nutzbar sind, und ein Wechsel wird faktisch zum Neubau. Fragen Sie das gezielt im Erstgespräch ab, ein seriöser Anbieter beantwortet das offen und ohne Ausweichen.

Ratgeber · Softwareentwicklung

Softwareentwicklungspartner finden: Kriterien, Ablauf, Warnsignale

Von Luis Waidmann · Stand: Juli 2026 · Lesezeit: ca. 7 Minuten

Kurz gesagt: Ein guter Softwareentwicklungspartner erkennt sich weniger am günstigsten Angebot als an drei Dingen: er versteht Ihre bestehenden Systeme, statt eine Insel danebenzustellen, er nennt einen verbindlichen Kosten- und Zeitrahmen vor Projektstart, und er bleibt auch nach dem Go-live erreichbar. Für die Auswahl zählen Referenzen aus Ihrer Systemlandschaft mehr als die Teamgröße, und ein Vertrag, der Ihnen Quellcode und Zugänge sichert, ist Pflicht, kein Nice-to-have.

Woran erkennt man einen guten Softwareentwicklungspartner?

Die verlässlichsten Signale zeigen sich schon im Erstgespräch, lange vor dem ersten Angebot. Ein guter Partner fragt zuerst nach Ihrem Ablauf und Ihren bestehenden Systemen, ERP, Archiv, Warenwirtschaft, statt sofort eine Lösung zu präsentieren. Er sagt auch, wann sich ein Projekt nicht lohnt oder eine Standardlösung reicht, das haben wir selbst im Ratgeber zu Individualsoftware-Kosten so gehandhabt und handhaben es im Erstgespräch genauso. Referenzen aus vergleichbaren Systemlandschaften wiegen dabei schwerer als die reine Teamgröße, denn wer bereits an eEvolution, Sage 100 oder ELO angebunden hat, kennt die typischen Stolperstellen, statt sie bei Ihnen zum ersten Mal zu lernen. Und ein Partner, der auch von sich aus sagt „das würde ich anders bauen", ist wertvoller als einer, der jeden Wunsch unwidersprochen umsetzt.

Festpreis, Aufwand oder Sprint: Welches Abrechnungsmodell passt?

Die drei gängigen Modelle verteilen das Risiko unterschiedlich zwischen Ihnen und dem Anbieter. Welches passt, hängt weniger von persönlicher Vorliebe ab als vom Reifegrad der Anforderung:

Modell	Wann sinnvoll	Risiko liegt bei	Typisch für
Festpreis	Umfang ist klar umrissen und dokumentiert	Anbieter, kalkuliert Puffer für Unwägbarkeiten ein	Einzelne Schnittstelle, klar definiertes Modul
Aufwand (Time & Material)	Umfang entwickelt sich erst im Projekt	Auftraggeber, dafür ohne versteckten Risikoaufschlag	Neue Anwendung mit offenen Details
Sprint-basiert mit Budgetdeckel	Größeres Projekt, das in Etappen wachsen soll	Geteilt, Deckel je Etappe begrenzt beide Seiten	Portale, Web-Apps mit mehreren Ausbaustufen

In der Praxis bewährt sich eine Kombination: Der erste, klar geschnittene Pilotbereich läuft als Festpreis, der Ausbau danach als Sprint mit Budgetdeckel je Etappe. So haben Sie beim Einstieg Planungssicherheit und beim Ausbau die Flexibilität, auf echte Nutzung statt auf die ursprüngliche Wunschliste zu reagieren.

Wie läuft ein Projekt von der Anfrage bis zum Go-live ab?

1. Anforderungsgespräch: Welches Problem soll gelöst werden, welche Systeme sind beteiligt, wer nutzt das Ergebnis später? Ein guter Partner fragt hier nach dem Ist-Ablauf, nicht nach einer Featureliste.
2. Angebot mit Rahmen: Verbindlicher Kosten- und Zeitrahmen für den ersten Ausbau, inklusive der Annahmen, auf denen er beruht. Ändern sich die Annahmen, ändert sich transparent auch der Rahmen.
3. Prototyp statt Pflichtenheft: Ein klickbares Zwischenergebnis nach wenigen Wochen sagt mehr als zwanzig Seiten Spezifikation. Hier zeigt sich auch, ob die Zusammenarbeit im Alltag funktioniert.
4. Pilotbetrieb mit echten Nutzern: Die erste Version läuft mit einer kleinen Gruppe realer Anwender, bevor der volle Rollout beginnt. Rückmeldungen fließen direkt in die nächste Etappe.
5. Übergabe und Betrieb: Dokumentation, vollständige Zugänge auf Ihren Namen und ein klarer Ansprechpartner für Wartung und Weiterentwicklung. Dieser Schritt entscheidet, wie unabhängig Sie danach sind.

Worauf sollten Sie bei der Auswahl konkret achten?

Neben den Kriterien aus dem Erstgespräch lohnt sich ein Blick auf vier vertragliche und organisatorische Punkte, die im Alltag den größten Unterschied machen. Erstens, Nutzungsrechte: Der Quellcode und alle Rechte am Ergebnis müssen vertraglich bei Ihnen liegen, nicht beim Anbieter. Zweitens, Systemkenntnis: Kennt der Partner Ihr ERP oder Archiv bereits, oder lernt er es auf Ihre Kosten kennen? Drittens, Erreichbarkeit nach Go-live: Gibt es einen festen Ansprechpartner für Support und Weiterentwicklung, oder endet die Beziehung mit der Rechnung? Viertens, Dokumentation: Wird die Lösung so dokumentiert, dass auch ein anderer Entwickler sie später warten könnte? Fehlt einer dieser vier Punkte im Angebot, fragen Sie gezielt nach, bevor Sie unterschreiben.

Wann ein externer Partner nicht die richtige Wahl ist

Nicht jedes Vorhaben braucht einen externen Entwicklungspartner. Bei einer einmaligen, sehr einfachen Aufgabe, etwa einer Excel-Vorlage oder einem einzelnen Formular, ist der Koordinationsaufwand eines externen Projekts oft größer als der Nutzen, hier reicht interne Bordmittel-Lösung. Ebenso, wenn eine Standardsoftware neunzig Prozent der Anforderung bereits abdeckt: Dann ist die Einführung eines bestehenden Systems in aller Regel wirtschaftlicher als eine Eigenentwicklung. Und wenn intern bereits ein erfahrener Entwickler mit Vertretung vorhanden ist, kann interne Entwicklung für einzelne Werkzeuge sinnvoller sein, externe Partner lohnen sich dann vor allem für Spitzen oder spezialisiertes Wissen, das intern fehlt. Ein seriöser Anbieter weist Sie im Zweifel selbst darauf hin, dass ein Projekt bei Ihnen (noch) nicht ansteht.

Typische Warnsignale bei der Partnerwahl

Kein verbindlicher Rahmen: Wer vor Projektstart weder Kosten noch Zeitplan nennen will oder kann, verlagert das Risiko vollständig zu Ihnen.
Vertrag ohne Quellcode-Klausel: Fehlt die klare Regelung, dass Ihnen der Code und die Nutzungsrechte gehören, sind Sie im Zweifel an den Anbieter gebunden.
Zugänge auf fremdem Konto: Laufen Hosting, Domain oder Datenbank auf einem Konto des Anbieters statt auf Ihrem eigenen, sind Sie bei einem Wechsel technisch blockiert.
Keine Referenz zu vergleichbaren Systemen: Ein Partner ohne jede Erfahrung mit ERP- oder Archiv-Anbindung lernt die Stolperstellen live an Ihrem Projekt, meist auf Ihre Kosten.
Alles wird zugesagt: Ein Anbieter, der nie „das würde ich anders machen" sagt oder jeden Termin unhinterfragt bestätigt, prüft selten kritisch mit.

Ein Kundenportal oder eine Schnittstelle sind typische erste Projekte, an denen sich diese Kriterien gut prüfen lassen, weil beide einen klar abgrenzbaren Pilotbereich erlauben. Als individuelle Softwareentwicklung arbeiten wir selbst nach genau diesem Muster: verbindlicher Rahmen vor Projektstart, Quellcode und Zugänge auf Namen des Kunden, und derselbe Ansprechpartner von der Anfrage bis zur Weiterentwicklung Jahre später.

Luis Waidmann

B.Sc. Wirtschaftsinformatik · Digitale Transformation · COS Waidmann Systemhaus, Ravensburg