Individualsoftware vs. Standardsoftware — in Architektur-Reviews fällt diese Abwägung früh, meistens in einem einzigen Satz: «Gibt es das nicht schon fertig?»
Meistens gibt es das. Und überraschend oft ist Kaufen die richtige Antwort. Ich leite die Entwicklung bei CODT Technologies, und der teuerste Code, den ich verantworte, ist der, den wir nie hätten schreiben dürfen. Wenn Ihre Lohnbuchhaltung läuft wie die aller anderen, kaufen Sie ein Lohnprodukt. Dafür bauen wir Ihnen nichts, und das ist in Ordnung.
Die nützliche Frage lautet deshalb nicht «bauen oder kaufen?». Sie lautet: Welcher Teil Ihres Betriebs ist wirklich anders als der Rest der Branche?
Individualsoftware vs Standardsoftware: die kurze Antwort
Standardsoftware kaufen Sie für Abläufe, die in Ihrer Branche überall gleich funktionieren: Buchhaltung, Lohn, E-Mail, ein CRM von der Stange. Individualsoftware lassen Sie dort entwickeln, wo Ihr Ablauf der Wettbewerbsvorteil ist oder wo kein Produkt am Markt ihn sauber abbildet. Die Entscheidung fällt pro Prozess, einzeln.
Individualsoftware-Beispiele: drei Projekte aus dem Portfolio
Drei Beispiele für Individualsoftware, die wir gebaut haben — zwei davon für denselben Kunden, einen Schweizer Foodtech-Betrieb — und jeweils der Grund, warum nichts von der Stange gereicht hätte.
Aviatize — Betrieb und Compliance für die Luftfahrt. Flugschulen und Operator führten sicherheitskritische Nachweise auf Papier, in Tabellen und in getrennten Planungstools. Planungssoftware gibt es. Dokumentenablagen auch. Was es nicht gab: ein System, in dem die tägliche Disposition den Prüfnachweis gleich miterzeugt. Heute: Audit-Vorbereitung von drei Tagen auf vier Stunden, über 1'000 Flugzeuge und Crews im System, 100% Inspektions-Compliance. Die Fallstudie steht hier.
FeelEat Admin Portal — ein Rückgrat für zwei Geschäftsmodelle. FeelEat betreibt Catering und vernetzte Kühlschränke gleichzeitig. Menüs, Firmenkunden, Gutscheine und Umsatzzahlen lagen über Tabellen und E-Mails verstreut. Zwei Standardprodukte nebeneinander hätten zwei Versionen der Wahrheit bedeutet, und der Umsatz wäre weiter von Hand zusammengerechnet worden. Nach dem Umbau: 12 Stunden pro Woche und Mitarbeiter gespart, Umsatzabgleich von zwei Tagen auf vier Stunden, über 200 Firmenkunden in einem System. Details hier.
Unified Recipe System — Rezepte, die ein Audit überstehen. Rezepte lebten in PDF-Ordnern und in den Köpfen der Küchenchefs; Allergenfragen beantwortete das Servicepersonal aus dem Gedächtnis. Nach der Umstellung auf ein versioniertes System: +47% beim Rezept-Konsistenz-Score, −82% Allergen-Vorfallrate, −60% Anlaufzeit für neue Standorte. So haben wir es gebaut.
Ein Muster fällt auf. In keinem der drei Fälle fehlte ein Produkt am Markt. Es fehlte ein Produkt, das zwei Dinge gleichzeitig konnte, für die es sonst zwei getrennte Anbieter braucht. Genau dort liegt fast immer der Fall für einen Eigenbau.
Was Standardsoftware besser kann
Diese Seite wird in Gesprächen über Software gern kleingeredet. Zu Unrecht:
- Der Preis steht am Anfang fest. Keine Schätzung, keine Bandbreite — meist eine veröffentlichte Zahl pro Nutzer pro Monat.
- Jemand anderes pflegt sie. Sicherheitsupdates, Browser-Kompatibilität, neue Steuersätze — nicht Ihr Problem.
- Sie ist am Montag da. Kein Projekt, kein Sprint, kein Go-live-Wochenende.
- Es gibt Leute, die sie schon können. Sie stellen jemanden mit passender Produkterfahrung ein und sparen einen guten Teil der Einarbeitung.
- Der Funktionsumfang wächst ohne Sie. Der Anbieter baut für tausend Kunden, und Sie bekommen es mit.
Der Haken kommt später und heisst Customizing. Ein Produkt, das fast passt, wird mit Konfiguration, Plug-ins und Beratungstagen passend gebogen. Was dieses Biegen kostet, steht in keinem Lizenzangebot. Und je mehr angepasst wurde, desto schwerer wiegt jeder Versionssprung — irgendwann ist das Upgrade selbst ein Projekt.
Die vollständige Rechnung
Unsere Seite steht offen in der Preisliste:
| Projektform | Team | Dauer | Indikatives Band |
|---|---|---|---|
| Schlankes MVP — ein Kern-Ablauf, wo möglich mit bewährten Fertigbausteinen, schnell vor echten Nutzern | 2–3 Entwickler | 8–14 Wochen | $30,000–55,000 |
| Standard-Produkt — mehrere Rollen, echte Integrationen, Admin und Reporting | 3–4 Entwickler + Delivery-Lead | 12–20 Wochen | $55,000–110,000 |
| Komplexe Plattform — Multi-Tenant, regulierte Daten, Migration am Livesystem | 5+ Entwickler, multidisziplinär | 20+ Wochen | $120,000–250,000+ |
Indikative Bänder für 2026, kein Angebot. Was die Zahl bewegt, ist Komplexität — Integrationen, Compliance, Datenmigration und die Zuverlässigkeit, die Sie ab Tag eins brauchen. Jedes Projekt wird nach einem bezahlten Discovery-Sprint fix und schriftlich bepreist, und der Sprint wird vollständig auf die Umsetzung angerechnet.
Dazu der laufende Betrieb: Der jährliche Support liegt typischerweise bei 15–20% der ursprünglichen Umsetzungskosten. Unser Kostenrechner rechnet Ihren konkreten Zuschnitt in zwei Minuten durch, und für die Einordnung in Franken gibt es den Schweizer Kostenleitfaden.
Die andere Seite müssen Sie selbst aufstellen, weil nur Sie Ihre Angebote kennen: Lizenz pro Nutzer, mal Anzahl Nutzer, mal so viele Monate, wie Sie das System betreiben werden — fünf Jahre sind der ehrliche Horizont. Plus Implementierungspartner. Plus Customizing. Plus die Beratungstage bei jedem grösseren Upgrade. Erst dann vergleichen Sie zwei vollständige Zahlen statt einer Projektsumme gegen einen Monatspreis.
Ein Posten taucht in solchen Vergleichen fast nie auf und zählt trotzdem: Bei uns gehören Arbeitsergebnis und Quellcode mit der Zahlung Ihnen. 100% der Rechte gehen über — kein Lock-in, keine Lizenz pro Sitzplatz. Die meiste Standardsoftware mieten Sie im Abo, und diese Zeile läuft weiter, solange Sie sie nutzen.
Der dritte Weg, den ich am häufigsten empfehle
Die Frage ist selten «alles kaufen oder alles bauen». In den Häusern, die ich mir ansehe, ist die richtige Antwort gemischt: Standardprodukte für Buchhaltung, Lohn und Ablage, Individualsoftware für die zwei oder drei Abläufe, an denen Ihr Geschäft tatsächlich hängt, per Schnittstelle sauber an den Rest angebunden.
Das hat eine Bedingung, die gern übersehen wird: Ihre Standardsysteme brauchen brauchbare Schnittstellen. Prüfen Sie das vor der Unterschrift, und zwar konkret. Kommen Sie an alle Objekte heran oder nur an die, die im Demo-Video vorkommen? Gibt es Webhooks, oder müssen Sie stündlich abfragen? Sind Löschungen sichtbar, oder verschwinden Datensätze einfach? Wie viele Aufrufe pro Minute erlaubt der Vertrag, und was kostet die nächste Stufe? Ein Produkt, das seine Daten nur häppchenweise herausgibt, macht den gemischten Weg später unmöglich.
Und wenn gebaut wird, entscheiden ein paar frühe Architekturfragen über die nächsten fünf Jahre. Mandantenfähigkeit ist das klassische Beispiel — warum «machen wir später» hier die teuersten drei Worte sind, steht hier. Wie wir solche Produkte aufsetzen, steht auf unserer Seite zur Individualsoftware-Entwicklung.
Vier Fragen, an denen ich die Entscheidung festmache
- Würde ein Wettbewerber diesen Ablauf genauso beschreiben? Wenn ja: kaufen.
- Wie viel Arbeitszeit steckt täglich darin? Je mehr Stunden ein Ablauf frisst, desto schneller zahlt sich ein Werkzeug aus, das genau dafür gemacht ist.
- Was kostet ein Fehler in diesem Prozess? Bei Allergenen, Prüfnachweisen oder Zahlungen lautet die Antwort «viel», und die Anforderungen sind dann meist zu spezifisch für ein Produkt von der Stange.
- Wie lange bleibt der Prozess so, wie er ist? Wenn Sie ihn seit Jahren nicht angefasst haben, wird ein Anbieter ihn vermutlich abbilden können. Wenn er sich jedes Quartal verschiebt, weil Ihr Markt sich verschiebt, zahlen Sie beim gekauften Produkt jedes Mal Beratungstage dafür.
Wenn Sie bei zwei oder mehr dieser Fragen klar auf der Bauen-Seite landen, ist die Frage nicht mehr ob, sondern in welchem Zuschnitt Sie starten — was ein erstes echtes Release umfasst, haben wir hier aufgeschrieben.
Wie wir anfangen
Der erste Workshop und eine grobe Einschätzung sind kostenlos — in der Regel innerhalb von drei Arbeitstagen. Wir schauen dabei zuerst, was Sie kaufen sollten. Was danach übrig bleibt, ist der Teil, für den sich ein Eigenbau rechnet.
Manchmal bleibt nichts übrig. Dann sagen wir Ihnen das auch.
