Ein Software-Angebot richtig lesen und vergleichen

Warum sich Software-Angebote oft nur scheinbar vergleichen lassen

Wenn drei Anbieter dir für dieselbe Idee drei Zahlen nennen, sagt der Unterschied zwischen den Zahlen erstaunlich wenig darüber aus, wer die bessere Arbeit liefert. Eine Software-Offerte ist kein Preisschild, sondern eine Wette darauf, wie viel Arbeit in deinem Vorhaben steckt. Und diese Wette macht jeder Anbieter auf Basis seiner eigenen Annahmen, seiner eigenen Definition von fertig und seines eigenen Bauchgefühls. Genau deshalb meinen die drei Zahlen fast nie dasselbe.

Ein Angebot richtig zu lesen heisst, die Annahmen hinter der Zahl freizulegen. Was ist drin, was ist bewusst draussen, was haben beide Seiten übersehen. Wer das nicht tut, vergleicht am Ende nur, wer am optimistischsten geschätzt hat. Und Optimismus ist im Softwarebau die teuerste aller Eigenschaften, weil er sich später in Nachträgen rächt.

Ich gehe das hier Schicht für Schicht durch. Am Ende hast du ein Raster, mit dem du zwei Offerten nebeneinanderlegen und dieselben Fragen an beide stellen kannst.

Scope: Was genau wird gebaut, und woran erkennst du Lücken

Der Scope ist die Liste dessen, was tatsächlich entsteht. Klingt banal, ist aber die Stelle, an der die meisten Vergleiche kippen. Ein Anbieter schreibt Benutzerverwaltung und meint damit eine Login-Maske. Der andere schreibt dasselbe und meint Registrierung, Passwort-Reset, Rollen, Einladungen und das Sperren von Konten. Beide nennen es Benutzerverwaltung. Der Aufwand unterscheidet sich um ein Mehrfaches.

Lies deshalb jede Position als Frage: Was kann ein Nutzer damit konkret tun, und was nicht. Ein gutes Angebot beschreibt Funktionen aus Sicht der Person, die sie benutzt, nicht als technisches Stichwort. Der Kunde lädt ein Dokument hoch und sieht den Bearbeitungsstatus ist überprüfbar. Dokumentenmodul ist eine Black Box.

Die teuersten Posten stehen selten in der Offerte, sie fehlen in ihr. Achte auf das, was nicht erwähnt wird. Suche, Filter, Export, Fehlermeldungen, was passiert bei leeren Zuständen, was bei doppelten Einträgen. Das sind keine Kür, das ist der Alltag jeder Anwendung. Wenn ein Angebot auffällig schlank wirkt, ist es oft nicht effizienter kalkuliert, sondern unvollständig. Eine Faustregel aus der Praxis: Je glatter und runder eine Offerte klingt, desto genauer solltest du nach den Rändern fragen, weil dort die unangenehmen Details wohnen.

Wenn du tiefer verstehen willst, woran das überhaupt liegt, dass Schätzungen so weit auseinandergehen, hilft der Blick darauf, warum SaaS-Projekte scheitern. Ein grosser Teil davon entscheidet sich genau hier, in der Unschärfe des Scopes.

Annahmen sichtbar machen: Worauf die Zahl wirklich steht

Jede Schätzung ruht auf Annahmen. Dass die Daten sauber vorliegen. Dass es nur eine Schnittstelle gibt und die dokumentiert ist. Dass das Design schon steht. Dass keine fachliche Sonderregel um die Ecke kommt. Solange diese Annahmen unausgesprochen bleiben, gehören sie nicht dem Anbieter, sondern dir, denn du trägst die Folgen, wenn sie nicht stimmen.

Ein seriöses Angebot listet seine Annahmen auf. Es schreibt hin: Wir gehen davon aus, dass die Stammdaten aus dem bestehenden System per Export bereitstehen. Das ist kein Kleingedrucktes zum Überblättern, das ist die wertvollste Stelle des Dokuments. Denn hier siehst du, welche Risiken der Anbieter dir leise zurückgibt.

Mach daraus eine konkrete Übung. Geh jede Annahme durch und frag dich: Stimmt das bei mir wirklich. Bei Schnittstellen zu einem ERP zum Beispiel ist eine dokumentierte API eine grosse Annahme, die in der Realität oft platzt. Was das kostet, wenn es anders kommt, lässt sich vorher abschätzen, dazu lohnt der Blick auf Schnittstellen und ERP-Anbindung. Fehlt die Annahmen-Liste komplett, frag danach. Die Antwort sagt dir mehr über den Anbieter als jede Referenzliste.

Betrieb: Der Teil, der erst nach dem Launch sichtbar wird

Viele Angebote enden gedanklich am Tag der Übergabe. Die Software ist gebaut, abgenommen, fertig. Nur ist eine Anwendung an dem Tag nicht fertig, sondern geht erst los. Sie muss irgendwo laufen, überwacht werden, Backups brauchen, Updates vertragen, und wenn nachts der Server klemmt, muss jemand das merken, bevor deine Nutzer es tun.

Der Betrieb ist die Schicht, die in günstigen Offerten am häufigsten fehlt, weil sie im Verkaufsgespräch unsexy ist. Frag deshalb explizit: Wer hostet, wer überwacht, wer wird nachts angerufen, was kostet das pro Monat, und ist es überhaupt im Angebot. Ein Festpreis für die Entwicklung ohne ein Wort zum Betrieb ist ein halbes Angebot.

Hier liegt ein Unterschied, der sich schwer behaupten und leicht belegen lässt. Wir bei Wertstifter bauen nicht nur, wir betreiben eigene Produkte selbst, Wortfreunde und Reazon, Tag für Tag im echten Lauf. Wer seine eigene Software nachts am Laufen hält, kalkuliert Monitoring, Backups und Alerting nicht als Beiwerk, sondern als Pflicht. Eine reine Agentur, die nach der Abnahme weiterzieht, hat diesen Erfahrungsdruck nie gespürt. Was ein vernünftiger Mindeststandard im Betrieb ist, haben wir in Monitoring, Backups und Alerting ausgeführt. Wenn ein Angebot dazu schweigt, weisst du, welche Arbeit später ungeplant auf jemanden zukommt, vermutlich auf dich.

Rechte und Übergabe: Wem gehört am Ende was

Eine Frage, die im Angebot oft gar nicht vorkommt und genau deshalb teuer wird: Wem gehört der Quellcode. Bekommst du ihn, kannst du ihn weitergeben, kannst du den Anbieter wechseln, ohne bei null anzufangen. Manche Konstruktionen binden dich so eng an einen Anbieter, dass jeder spätere Wechsel einem Neubau gleichkommt. Das ist kein Zufall, das ist ein Geschäftsmodell.

Klär das vor der Unterschrift. Sichere dir die Rechte am Code, den Zugang zu den Konten, auf denen die Software läuft, und eine saubere Dokumentation. Diese Dinge kosten nichts, wenn du sie am Anfang vereinbarst, und sie kosten sehr viel, wenn du sie am Ende verhandeln musst, weil dann die Verhandlungsmacht beim anderen liegt. Die Details dazu stehen in wem gehört der Code und beim Thema Vendor-Lock-in vermeiden.

Festpreis oder Aufwand: Welches Modell zu welcher Unsicherheit passt

Die Frage, ob du einen Festpreis nimmst oder nach Aufwand abrechnest, ist keine Glaubensfrage, sondern hängt davon ab, wie klar dein Vorhaben umrissen ist.

Ein Festpreis verschiebt das Risiko zum Anbieter. Verschätzt er sich, zahlt er drauf. Klingt gut für dich, hat aber einen Preis: Der Anbieter rechnet einen Puffer ein, weil er das Risiko trägt, und er wird jede Änderung, die nicht exakt im vereinbarten Scope steht, als kostenpflichtigen Nachtrag behandeln. Ein Festpreis funktioniert nur dort, wo der Scope wirklich fest ist. Bei einem Vorhaben, das sich während der Entwicklung noch klärt, wird er zur Quelle endloser Diskussionen darüber, was dazugehört.

Aufwand (oft Time and Material genannt) verschiebt das Risiko zu dir, gibt dir dafür aber Flexibilität. Du zahlst die tatsächlich geleistete Arbeit und kannst die Richtung jederzeit anpassen. Das setzt Vertrauen voraus und ein wachsames Auge auf den Fortschritt. Bei explorativen Vorhaben, einem ersten Wurf, einem MVP, ist dieses Modell meist das passendere, weil niemand seriös festpreisen kann, was noch nicht ausdefiniert ist. Die Abwägung im Detail steht in Festpreis vs Time and Material.

Ein Mittelweg, der in der Praxis oft am besten trägt: einen kleinen, klar umrissenen ersten Block festpreisen, um Vertrauen und ein gemeinsames Bild aufzubauen, und danach in Aufwand weitergehen. So kaufst du dir Sicherheit für den Start und Beweglichkeit für den Weg.

Wann der Vergleich von Offerten der falsche Schritt ist

Manchmal ist die Antwort auf drei Angebote nicht das vierte Angebot, sondern ein Schritt zurück. Wenn die drei Zahlen weit auseinanderliegen und alle Anbieter sichtlich raten, ist das kein Anbieterproblem, sondern ein Zeichen, dass dein Vorhaben noch nicht reif für ein Angebot ist. Niemand kann sauber schätzen, was noch nicht klar gedacht ist.

In diesem Fall lohnt eine kleine, bezahlte Vorstufe mehr als jede weitere Offerte: ein kurzes Konzept, ein Prototyp, eine Woche gemeinsames Schärfen des Problems. Danach werden die Angebote vergleichbar, weil alle vom selben Bild ausgehen. Was dabei wirklich zählt, ist die erste Funktion, der harte Kern, dazu hilft die erste Funktion und der Produktkern.

Und manchmal ist Software überhaupt nicht der richtige Schritt. Wenn ein angepasstes Standard-Tool dein Problem zu achtzig Prozent löst, ist eine Eigenentwicklung selten die klügere Wahl, das beleuchtet Standard-Tool anpassen vs eigenes bauen. Ein guter Partner sagt dir das, auch wenn er damit ein Projekt verliert. Wer dir ungefragt zum teuersten Weg rät, hat sein Interesse über deins gestellt.

Den günstigsten Weg erkennt man erst über die ganze Laufzeit

Die billigste Zahl gewinnt den Vergleich auf dem Papier und verliert ihn fast immer in der Realität. Denn was am Anfang fehlt, kommt später zurück, als Nachtrag, als ungeplanter Betriebsaufwand, als teurer Wechsel, weil dir der Code nicht gehört. Der günstigste Weg ist der, bei dem die Summe aus Bau, Betrieb und Beweglichkeit über die Jahre am kleinsten bleibt, nicht der mit der niedrigsten Zahl im ersten Quartal.

Leg die Offerten also nicht nebeneinander, um die kleinste Zahl zu suchen. Leg sie nebeneinander, um zu sehen, wer am gründlichsten gedacht hat. Wer seine Annahmen offenlegt, den Betrieb einplant, dir die Rechte gibt und beim Vertragsmodell das passende vorschlägt statt das bequemste, der hat dir die meiste spätere Arbeit abgenommen, bevor sie entsteht.

Wenn du an genau diesem Punkt stehst und eine Einschätzung dazu brauchst, ob ein Vorhaben überhaupt für ein Angebot reif ist, schau dir an, wie wir SaaS-Produktentwicklung angehen. Ein gutes Gespräch über das, was fehlt, ist am Anfang mehr wert als jeder Preisvergleich am Ende.