Software für KMUs: bauen, kaufen oder warten? Ein Entscheidungs-Framework

Drei Trigger, an denen KMUs die Frage stellen

In den meisten KMUs taucht die Frage „bauen wir das selbst, kaufen wir was Fertiges, oder warten wir noch?" an drei spezifischen Triggern auf:
**Trigger 1 — Eine Standard-Software passt nicht mehr.** Die Branche ist zu spezifisch, der Workflow zu individuell, oder das Tool wurde irgendwann ausgewachsen und kostet jeden Monat mehr Workarounds.
**Trigger 2 — Ein interner Prozess wird zum Engpass.** Angebote, Auftragsabwicklung, Kundenkommunikation — irgendwo verbringst du jede Woche Stunden, die nichts liefern außer Beibehaltung des Status quo.
**Trigger 3 — Die Marktposition verlangt nach digitalem Differenzierungs-Hebel.** Ein Wettbewerber hat eine eigene App, ein Kundenportal oder eine offene API — und plötzlich wirken die Excel-Templates wie ein Auslaufmodell.
An jedem dieser drei Trigger entstehen schlechte Entscheidungen, wenn die Frage „bauen oder kaufen?" nicht systematisch beantwortet wird.

Die drei Dimensionen der Entscheidung

Die richtige Antwort hängt von drei Achsen ab, die du für deinen konkreten Fall ehrlich beantworten musst:
**Standardfähigkeit.** Ist das, was du brauchst, ein gelöstes Problem (CRM, Buchhaltung, E-Mail-Marketing) oder ein branchen- bzw. workflow-spezifisches Problem? Je höher die Standardfähigkeit, desto stärker Richtung „kaufen". Eine bessere CRM-Datenbank baust du nicht selbst — die Welt hat genug davon.
**Differenzierungsgrad.** Macht das Tool deinen Wettbewerb tatsächlich enger, oder ist es ein Backoffice-Bedarf? Differenzierende Tools, die deinen Kunden ein anderes Erlebnis liefern, lohnen sich zu bauen — Backoffice-Tools nur dann, wenn der Markt wirklich nichts Brauchbares hergibt.
**Zeitdruck.** Brauchst du eine Lösung in drei Wochen, drei Monaten oder einem Jahr? Zeitdruck verschiebt die Antwort fast immer Richtung „kaufen plus später bauen", nicht „direkt bauen unter Zeitdruck".

Wann "Bauen" der richtige Move ist

Bauen ist die richtige Antwort, wenn drei Bedingungen zusammenkommen: niedrige Standardfähigkeit, hoher Differenzierungsgrad, planbarer Zeitrahmen.
Konkret: Du machst etwas, das es am Markt so nicht gibt (oder nur Enterprise-Lösungen mit fünfstelligen Implementierungs- und Lizenzkosten anbieten), das deine Kunden anders erleben werden, und du hast 2-12 Wochen Zeit, um es zu liefern.
Beispiel aus der Praxis: ein Field-Service-Team brauchte einen ROI-Kalkulator, den Vertreter live beim Kunden in unter zwei Minuten ausfüllen können. Standard-CRMs konnten das nicht, externe Kalkulatoren waren zu unflexibel, der Wettbewerb hatte nichts Vergleichbares. Bauen war die richtige Antwort — Setup in wenigen Tagen, seitdem in Produktion, Angebotszeit von 30 auf 2 Minuten gesenkt.

Wann "Kaufen" der richtige Move ist

Kaufen ist die richtige Antwort bei hoher Standardfähigkeit oder niedrigem Differenzierungsgrad — egal wie maßgeschneidert die SaaS-Lösung wirken muss.
Faustregel: Wenn drei Wettbewerber dasselbe Problem mit dem gleichen Standard-Tool lösen, baut man kein eigenes. Backoffice-Bedarf wie Buchhaltung, Payroll, Document-Signing oder E-Mail-Marketing gehört in ca. 95 % der Fälle in diese Kategorie. Eigenes Bauen kostet 10× mehr und liefert keinen Markt-Vorteil — nur Wartungs-Verantwortung.
Wichtig in dieser Kategorie: bei der SaaS-Wahl auf EU-Hosting und DSGVO-Konformität achten. Migration zwei Jahre später ist deutlich teurer als die richtige Wahl heute.

Wann „Warten" der richtige Move ist

Die am häufigsten übersehene Antwort. Warten ist richtig, wenn du den Trigger spürst, aber noch nicht genug Signal hast, um die Investition zu rechtfertigen.
Typisches Beispiel: Du denkst über ein Kundenportal nach, weil ein Kunde es mal angefragt hat. Du weißt aber nicht, ob es 5 oder 50 Kunden wirklich nutzen würden. Sofort bauen wäre eine fünfstellige Wette auf unklare Nachfrage. Stattdessen: Click-Dummy bauen lassen, 5-10 Kunden zeigen, Reaktion messen, dann entscheiden.
„Warten" heißt in diesem Kontext nicht nichts tun. Es heißt: gezielt Signal generieren, bevor die teure Entscheidung getroffen wird. Wer das überspringt, baut entweder am Bedarf vorbei oder zahlt für die spätere Korrektur dreimal.

Die drei häufigsten Fehlentscheidungen

In KMU-Audits sehen wir immer wieder die gleichen drei Fehler:
**Zu spät bauen.** Das Team arbeitet drei Jahre mit einem Tool-Stack aus 12 SaaS-Tools, die alle nicht ineinander greifen. Wenn endlich gebaut wird, ist die Migration ein Albtraum, weil drei Jahre Daten in 12 Tools verstreut liegen.
**Zu früh bauen.** Das Team baut ein Kundenportal, das niemand braucht — weil die Annahme „unsere Kunden wollen ein Portal" nie validiert wurde. Sechs Monate Entwicklungszeit und ein fünfstelliger Betrag versenken sich in einer Funktion, die ungenutzt bleibt.
**Bei der falschen Agentur bauen.** Festpreis war nicht festgepreist, der Code gehört nicht dem KMU, Wartung wird im Monatsabo verkauft, und nach 18 Monaten merkt das KMU, dass es im Vendor-Lock-in steckt — und jeder Bugfix den Stundensatz der Agentur in Geld umrechnet.

Wie wir KMUs durch die Entscheidung führen

aunomo.tech bietet die Entscheidungsschritte als Festpreis-Pakete an, statt sie in einem offenen Beratungsstunden-Modell zu binden. Jedes Paket hat ein klar definiertes Ergebnis, und du kannst nach jedem Schritt aussteigen.
**The Spark (2.490 €) — wenn die Entscheidung noch offen ist.**Ein zweitägiger Initial-Sprint, der die drei Dimensionen für deinen konkreten Fall durchgeht und eine klare Empfehlung produziert: bauen, kaufen oder warten — plus konkreter nächster Schritt. Wer mit „bauen" rausgeht, hat einen klaren Scope. Wer mit „kaufen" rausgeht, hat eine kurze SaaS-Shortlist. Wer mit „warten" rausgeht, hat einen Validierungsplan.
**The Signal (3.900 €) — wenn Signal vor der Investition gebraucht wird.**Ein Click-Dummy oder eine interaktive Demo, mit der du das Konzept bei 5-10 Kunden validierst, bevor du das Budget für die Vollversion freigibst. Verhindert die größten Bauten-am-Bedarf-vorbei-Fehler.
**The Prototype (6.900 €) — wenn das Konzept steht und Software in 7-10 Tagen gebraucht wird.**Produktionsreife Web-App für genau eine klar definierte Aufgabe. Senior-Engineering, kein Agentur-Lock-in, volles Eigentum am Code, an der Doku, am System.
**The Build (Custom-Projekt) — wenn der Prototype läuft und Produktions-Skalierung kommt.**Senior-Engineering-Aufbau für skalierbare Systeme, weiterhin Festpreis, weiterhin volles Eigentum. Für KMUs, die nach dem ersten erfolgreichen Schritt die Lösung in die zentrale Operations-Architektur integrieren wollen.
Der Vorteil der Gradation: du investierst nur in den nächsten Schritt, nicht in einen Sechs-Monats-Plan. Spark führt zu Signal, Signal zu Prototype, Prototype zu Build — oder einer von vier Schritten ist genug, weil die Entscheidung sich vorher klärt.

Du stehst gerade vor der Frage "bauen, kaufen oder warten"? Gehe auf uns zu und erhalte einen kostenlosen Audit. 30 Minuten, kein Pitch. Strukturelle Erst-Einschätzung mit klarer Empfehlung am Ende.