← Zurück
Pillar · Custom Software für KMU

Individuelle Software für KMU: Wann lohnt sich Custom-Dev?

~16 Min Lesezeit · Stand 2026-04-29 · Von Simon Maiwald

Die meisten Mittelständler glauben, sie bräuchten Custom-Software. In den meisten Fällen reicht ein gut konfiguriertes Standard-Tool plus eine AI-gestützte Integration. Custom-Software lohnt sich erst dort, wo Ihr Prozess echter Wettbewerbsvorteil ist, nicht dort, wo SaaS-Anbieter zufällig keine perfekte Vorlage haben.

Dieser Leitfaden ist aus der Perspektive eines AI-Beratungs- und Custom-Software-Hauses geschrieben, das im DACH-Mittelstand selbst baut. Er ist für mittelständische Geschäftsführer und CTOs, die vor der Make-or-Buy-Entscheidung stehen. Er beantwortet die Fragen, die in den meisten Erstgesprächen kommen: Wann lohnt sich Eigenbau? Was kostet er realistisch? Welcher Stack trägt langfristig? Cloud oder On-Premise? Outsourcing oder eigenes Team? Und wie schützt man sich vor Lock-In?

Was Sie hier finden: ein Make-or-Buy-Framework, ehrliche Budget- und Timeline-Bandbreiten, Architektur-Patterns für KMU, sechs häufige Fragen mit zitierfähigen Antworten, und Verlinkungen zu vertiefenden Spokes. Was Sie hier nicht finden: Frameworks aus Marketing-Decks, “agile Transformation”-Phrasen oder die Behauptung, dass jede Firma eine eigene Plattform braucht.

Wann Standard-Tools nicht mehr reichen

Bevor wir über Custom-Software reden: 80 % der Mittelstand-Use-Cases werden besser durch ein konfiguriertes Standard-Tool gelöst. Salesforce, HubSpot, Notion, Airtable, Pipedrive, ClickUp, Monday, Make.com, n8n: alle diese Tools sind 2026 so leistungsfähig, dass viele “Wir-brauchen-eine-eigene-Plattform”-Diskussionen sich von selbst auflösen, wenn man eine Stunde im richtigen Standard-Tool sitzt.

Es gibt aber fünf konkrete Anzeichen, dass Sie aus dem Standard-Bereich herausgewachsen sind:

1. Sie zwingen sich in Workarounds, die niemand mehr versteht

Wenn Ihre Mitarbeitenden Daten zwischen drei Excel-Dateien kopieren, weil das CRM eine bestimmte Logik nicht kann, sind Sie in Workaround-Land. Ein einzelner Workaround ist OK. Fünf, die voneinander abhängen, kosten Sie zwei Mitarbeitende-Tage pro Woche und produzieren Datenfehler, die niemand mehr nachvollziehen kann. Tool-Flickenteppich nennt man das, und das ist der erste Hinweis auf Custom-Bedarf.

2. Ihr Prozess ist Ihr Wettbewerbsvorteil

Wenn das, was Sie tun, genau so wie Sie es tun, der Grund ist, warum Kunden bei Ihnen kaufen: dann lohnt sich eigene Software. Eine Steuerkanzlei mit einem speziellen, jahrelang verfeinerten Mandanten-Onboarding-Workflow, ein Werkstatt-Betrieb mit eigener Diagnose-Methodik, ein Hersteller mit proprietärer Qualitätsprüfung. Ihr Prozess ist IP. Standard-Software würde diesen IP weichwäschen.

3. Standard-Software erfordert mehr Anpassung als Eigenbau

Wenn Salesforce-Customizing-Berater Ihnen ein 80.000-Euro-Angebot machen, um Ihre Anforderungen abzubilden, lohnt sich oft die ehrliche Frage: was würde Eigenbau kosten? Manchmal sind 80k Salesforce-Custom = 60k Custom-Software, die genauer passt und Ihnen gehört. Die Kosten-Per-Outcome-Rechnung ist die wichtigere als die Kosten-Per-Lizenz-Rechnung.

4. Skalierungs-Engpässe durch Standard-Tool-Limits

API-Limits, Lizenzkosten pro User, Performance bei hohem Volumen: ab einer gewissen Skalierungsstufe wird Standard-SaaS teurer als Eigenbau. Faustregel: ab etwa 100 täglich aktiven Nutzern oder mittel-sechsstelligen API-Calls pro Monat lohnt sich die Total-Cost-of-Ownership-Rechnung.

5. Datensilos verhindern KI-Use-Cases

Wenn Sie KI auf Ihren eigenen Daten einsetzen wollen (RAG-Systeme, interner Q&A-Bot, Auto-Klassifikation), brauchen Sie eine Datenarchitektur, die Standard-SaaS oft nicht bietet. Eigene Software mit klarer Datenebene macht KI-Integration trivial. Mehr dazu in unserem vollständigen Leitfaden zu KI im Mittelstand.

Das Make-or-Buy-Entscheidungs-Framework

Wenn mindestens zwei der fünf Anzeichen oben zutreffen, lohnt sich eine strukturierte Entscheidung. Das pragmatische Framework hat zwei Achsen: strategische Wichtigkeit und Standard-Verfügbarkeit.

Standard verfügbar Standard fehlt / unzureichend
Strategisch wichtig Standard kaufen + tief konfigurieren (Salesforce, HubSpot, etc.) Custom-Build: Top-Quadrant. Hier rechtfertigt sich Eigenbau
Strategisch unwichtig Standard kaufen + minimal konfigurieren Workaround mit Standard-Tools + AI-Integration

Werkzeug und Handwerk nicht verwechseln: Wer im strategisch-wichtig + Standard-fehlt-Quadrant landet, bekommt durch Custom-Software einen echten Wettbewerbsvorteil. Wer im strategisch-unwichtig + Standard-fehlt-Quadrant landet, sollte sich fragen, ob er das Problem überhaupt lösen muss.

Praktisch sind die meisten Custom-Software-Erfolge im Mittelstand 2026 in einer dieser drei Konstellationen:

  • Branchenspezifische Workflow-Tools: Steuerkanzleien, Coaching-Praxen, Werkstätten, Maklerbüros mit Branchen-IP, das kein generisches Tool abbildet
  • Datenkonsolidierungs-Plattformen: wenn Daten aus 5+ Systemen in einer Auswertung zusammenlaufen müssen, regelmäßig, mit Logik die Standard-Reporting-Tools nicht abbilden
  • Kunden-/Partner-Portale mit eigenem Branding: wenn Ihr externes Front-End Ihr Markenversprechen ist und Standard-Portal-Lösungen das verwässern

Drei Anti-Patterns, die Sie vermeiden sollten

Genauso wichtig wie zu wissen wann Custom-Software lohnt: zu wissen, wann sie nicht lohnt. Drei Anti-Patterns, die in Erstgesprächen am häufigsten auftauchen:

1. “Wir wollen unser eigenes Tool weil das was wir machen besonders ist.” Prüfen Sie, ob das “Besondere” wirklich strategischer Vorteil ist, oder nur Gewohnheit. Wenn die Antwort “Gewohnheit” ist: Standard-Tool plus Schulung kostet 2 % von Custom-Build.

2. “Wir bauen jetzt ein eigenes ERP”: das ist fast immer ein 24-Monats-Projekt, das in Monat 18 zerbricht. ERPs sind kommodifiziert. Custom-Build für Spezial-Workflows IN einem Standard-ERP ist die richtige Antwort, nicht ERP-Replacement. Ein anonymisierter Kunde aus dem Heizungsbau hat genau das versucht, 18 Monate gebrannt, am Ende zu Microsoft Dynamics gewechselt und dort die Spezial-Workflows eigen-entwickelt. Gespart hätte er 9 Monate plus Hunderttausende Euro.

3. “Wir wollen das so machen wie [bekannte Marke X] es macht”, gefolgt von einer Anforderungsliste, die ein internationales Tech-Unternehmen nachbaut. Bei 50 Mitarbeitenden ist das Over-Engineering. Was bei 5.000 Mitarbeitenden Sinn macht, ist bei 50 Mitarbeitenden Bauernopfer am eigenen Budget.

Architektur-Patterns für KMU-Software

Für mittelständische Custom-Software gibt es 2026 drei dominante Architektur-Patterns. Jedes hat seinen Sweet-Spot.

Pattern 1: Modulith mit klarer Domain-Struktur

Eine einzelne Codebase, ein einzelner Deploy, aber intern in klar abgegrenzte Domains strukturiert. Für KMU mit 1-3 Entwicklern die richtige Wahl: weniger Operations-Overhead als Microservices, leichter zu betreiben, leichter zu refactoren wenn das Geschäft pivotiert. Stack: Next.js mit Server-Actions oder Astro mit Server-Endpoints, Postgres über Supabase, Vercel- oder AWS-Hosting in EU-Region.

Pattern 2: Headless mit API-First

Backend als API-Layer (REST oder GraphQL), Frontend als separate Web-App und potenziell Mobile-App, gemeinsame Datenebene. Sweet-Spot wenn das Front-End über mehrere Plattformen ausgespielt wird (Web + Mobile + Partner-Embed). Stack: TypeScript-Backend (Node.js, Hono), Frontend in React oder Svelte, optional native Apps mit Expo. Mehr Aufwand als Modulith, aber tragfähiger wenn Multi-Channel-Strategie steht.

Pattern 3: AI-Native mit RAG-Layer

Die neue Klasse 2026: Software, die LLMs nicht als Add-on, sondern als Kern-Architektur-Element behandelt. Datenebene ist auf Embedding-Search optimiert (Postgres mit pgvector), Anwendungs-Logik nutzt LLM-Calls für Klassifikation und Generation. Sweet-Spot wenn der eigentliche Wert der Software in der intelligenten Verarbeitung unstrukturierter Daten liegt: Dokumenten-Workflows, Wissens-Bots, intelligente Suche. Vertiefung: LLM-Integration in Unternehmenssoftware.

Ein Anti-Pattern, das wir häufig sehen: Microservices als ersten Architektur-Wurf. Für KMU mit kleinem Entwicklungsteam ist Microservices fast immer Over-Engineering. Erst wenn ein Modulith an konkrete Skalierungs-Engpässe stößt (selten unter 10 Mitarbeitende-Years Entwicklung), lohnt sich der Schnitt. Bis dahin: kein Pferd, sondern ein Stall. Klare Domains in einer Codebase, keine Verteilung um der Verteilung willen.

Stack-Auswahl-Checkliste für KMU-Custom-Software

Fünf Fragen, die Sie vor jeder Stack-Entscheidung beantwortet haben sollten:

  • Wie viele Entwickler werden in 3 Jahren am Code arbeiten? 1-3 → Modulith mit Mainstream-Stack. 4-10 → Headless mit klaren API-Grenzen. 10+ → Microservices-Diskussion sinnvoll.
  • Welche Daten-Domain ist Kern Ihres Geschäfts? Relational + transaktional → Postgres. Volltext-Suche kritisch → Postgres mit pg_trgm oder Elasticsearch. KI-zentrisch → Postgres mit pgvector.
  • Wo sind Ihre Bestand-Systeme integriert? Microsoft-Welt → C#/.NET kann Sinn machen. Sonst TypeScript/Python als sichere Standards mit größter Entwickler-Verfügbarkeit.
  • Mobile-App nötig? Wenn ja: React Native (Expo) als universellen Stack mit Web. Wenn Web-only erstmal reicht: Web-First, Mobile später.
  • Hosting-Region kritisch? DSGVO + EU-Mandat → Vercel-Frankfurt, AWS Frankfurt, Hetzner. Globale Skalierung ohne Region-Mandat → Cloudflare oder klassisches AWS Multi-Region.

Realistische Timelines und Budgets

Wer Sie nicht in einer Discovery-Phase mit konkreten Anforderungen quizzt, sondern direkt einen Festpreis nennt, plant nicht. Aber Bandbreiten lassen sich angeben, und sind die wichtigste Erwartungs-Justierung vor Projektstart.

Discovery-Sprint

5 Arbeitstage. 2.500 € Festpreis, abbrechbar. Ein funktionsfähiger Prototyp mit echten Daten auf einem klar abgegrenzten Use-Case. Ziel: Realisierbarkeit prüfen, Live-Demo, Entscheidung ermöglichen. Bei New Life Digital ist der Discovery-Sprint der Standard-Einstieg: die POC-First-Methodik heisst Live-Demo, bevor wir Vertrag reden.

Custom-Build Small · Medium

Small: 6-8 Wochen, 25-35k €. Medium: 8-12 Wochen, 35-55k €. Erstes produktives System, abgegrenzter Funktionsumfang, in echte Prozesse integriert. Für erste 5-30 Endnutzer typischerweise. Hier laufen Funktionen, die im Discovery-Sprint nur angedeutet waren: User-Management, Audit-Logs, Berechtigungen, Integration mit Bestandssystemen.

Custom-Build Large

12-16 Wochen. 55-80k € Festpreis. Skalierbar, gehostet in produktiver Infrastruktur, integriert in alle relevanten Bestandssysteme, mit Monitoring und Cost-Controlling. Bereit für 50+ Nutzer und kontinuierliches Feature-Wachstum.

Multi-Phase Build

Mehrere Phasen über 4-8 Monate verteilt, pro Phase Festpreis und klares Lieferziel, Re-Scoping zwischen Phasen. Vollständige Custom-Plattform, mehrere Frontends, alle Datenintegrationen, eigenes Mobile-App falls nötig, KI-Layer, eigene Reporting-Suite. Hier landen typischerweise Konzerntöchter oder Mittelständler mit konkreter Internationalisierungs-Story.

Maintenance-Retainer

Nach Go-Live 500-2.500 €/Monat, je nach Systemtiefe (entspricht 15-25 % der Initial-Kosten pro Jahr) für Wartung, Sicherheits-Updates, kleine Erweiterungen, Bug-Fixes. Wer das nicht einplant, sitzt in zwei Jahren auf einem System, das niemand mehr versteht. Bauchgefühl in Zahlen verpackt: Jede Software altert. Pflege-Budget ist nicht optional.

Praxisbeispiel: anonymisierter Werkstatt-Betrieb

Ein Kfz-Werkstatt-Verbund in der Rhein-Neckar-Region mit drei Standorten und 35 Mitarbeitenden hatte 2025 ein klassisches Problem: jede Werkstatt arbeitete mit eigenen Excel-Listen für Auftragsverwaltung, Ersatzteil-Bestellungen und Rechnungsstellung. Drei Listen-Systeme, keine Integration, doppelte Datenpflege, etwa 12 Stunden pro Woche an Daten-Reconciliation am Standort-übergreifenden Reporting.

Discovery-Sprint (5 Tage, 2.500 €): Wir haben mit allen drei Werkstattleitern gesprochen, die Excel-Listen analysiert und einen funktionsfähigen Auftragsverwaltungs-Prototyp mit echten Daten der größten Werkstatt gebaut. Stack: Next.js, Supabase, Vercel-Hosting in Frankfurt. Kern-Erkenntnis: 80 % der Anforderungen waren branchen-spezifisch (Diagnose-Codes, TÜV-Prüflogik, Spezialteil-Disposition), 20 % waren Standard-CRM-Funktionen. Alle drei Werkstattleiter konnten den Prototyp in der Live-Demo nutzen, Feedback war überwiegend positiv. Custom-Build war die richtige Antwort.

Custom-Build Large (16 Wochen, 68.000 €): Voll-Produktiv für alle drei Standorte, integriert mit Bestand-Buchhaltung (DATEV-Schnittstelle) und Ersatzteil-Lieferanten-API. AI-Klassifikation der eingehenden Kunden-Nachrichten via Claude API. User-Schulung 2 halbe Tage pro Werkstatt.

Resultat nach 6 Monaten Betrieb: Daten-Reconciliation ist von 12 auf 1 Stunde pro Woche gesunken (90 % Reduktion). Standort-übergreifendes Reporting ist von Quartalsweise (manuell) auf Echtzeit-Dashboard geändert. Pflege-Budget liegt bei 13.000 € pro Jahr (20 % der Initial-Kosten). Amortisation: 11 Monate. Die Inhaberin hat seitdem zwei zusätzliche Werkstatt-Standorte übernommen, ohne IT-Aufwand pro Standort zu verändern.

Outsourcing vs. eigenes Team

Die Frage “eigenes Entwicklerteam oder externer Partner?” hat keine universelle Antwort, aber drei klare Faustregeln:

Für das erste Custom-Software-Projekt: externer Partner. Kein eigenes Team aus dem Stand aufbauen für ein einzelnes Projekt. Die Recruiting-Zeit (3-6 Monate Suche, dann 3 Monate Onboarding) frisst die ersten 9 Monate, in denen ein erfahrener externer Partner schon V1 produktiv hat.

Bei kontinuierlicher Entwicklung über Jahre: Hybrid. Internes Produkt-Team (1-3 Personen für Anforderungs-Klarheit, Domain-Expertise, Architektur-Entscheidungen) plus externer Implementierungs-Partner mit 2-5 Personen je nach Projektphase. Reines Inhouse rechnet sich erst ab 5+ Personen Vollzeit-Entwicklung über 3+ Jahre.

Bei One-Off-Projekten ohne Folge-Bedarf: Externer Partner mit klarer Code-Übergabe-Klausel. Sie wollen den Code nicht selbst betreiben, aber Sie wollen ihn verstehen und bei Bedarf weiterentwickeln können. Die ehrliche Tiefen-Analyse dieser Entscheidung steht in unserem Spoke Outsourcing vs. eigenes Team, mit konkreten Tagessatz-Bandbreiten und dem Hybrid-Modell, das in der Praxis am häufigsten funktioniert.

Bei der Wahl des externen Partners gilt die einfachste Heuristik: ein guter Partner stellt zuerst Fragen, ein schlechter macht zuerst Angebote. Wer sich nicht für Ihren Prozess interessiert, wird Software bauen, die zu Ihrem Prozess nicht passt, egal wie gut technisch.

Nearshore und Offshore: wann es sich rechnet

Wir empfehlen mittelständischen Kunden in der DACH-Region in 90 % der Fälle lokale oder Nearshore-Partner. Tagessätze in Deutschland liegen 2026 bei 900-1.400 Euro für erfahrene Senior-Entwickler. Nearshore (Polen, Tschechien, Rumänien, Portugal) liegt 30-50 % darunter mit guter technischer Ausbildung und 1-2 Stunden Zeit-Überlappung. Offshore (Indien, Vietnam, Philippinen) ist nochmal 40-60 % darunter, kostet aber durch Zeitzonen-Differenz, Kommunikations-Overhead und Kultur-Mismatch oft mehr Management-Zeit als die Tagessatz-Ersparnis bringt.

Faustregel für Mittelstand-Custom-Dev 2026: bei Projekten unter 50.000 € lokal halten (Kommunikations-Vorteil überwiegt). Bei Projekten 50.000-200.000 € Nearshore-Hybrid mit lokalem Lead prüfen. Bei Projekten über 200.000 € lohnt sich strukturiertes Multi-Standort-Setup mit klarer Process-Disziplin.

Legacy-Modernisierung als Spezialfall

Etwa die Hälfte aller Custom-Software-Diskussionen im Mittelstand sind eigentlich Legacy-Modernisierungen: ein bestehendes System, das vor 8-15 Jahren gebaut wurde, läuft noch, aber blockiert neue Anforderungen oder ist Wartungs-teuer geworden.

Die zwei Pole bei Legacy-Modernisierung sind: Big-Bang-Rewrite (alles neu in 18-24 Monaten) und Strangler-Fig-Pattern (schrittweise neue Module ersetzen alte). Für mittelständische Szenarien ist Strangler-Fig fast immer die richtige Wahl: minimales Risiko, sofortiger Mehrwert, keine Ausfallzeit.

Konkrete Bandbreiten: Discovery-Sprint zur System-Inventur (5 Tage, 2.500 €) plus optionaler Strategie-Workshop für die Modernisierungs-Roadmap (5-10 Tage, 5-10k €). Pilot-Modernisierung eines Moduls als Custom-Build Medium (35-55k) oder Large (55-80k). Vollständige Migration als Multi-Phase Build (mehrere Phasen, pro Phase Festpreis und klares Lieferziel). Vertiefung mit Strangler-Fig-Pattern und Cost-of-Nichtstun-Berechnung in unserem Spoke Legacy-Systeme modernisieren: Wann lohnt es sich?

Wie wir bei New Life Digital arbeiten

Unser Ansatz: AI-Beratung und Custom Software für den Mittelstand, in einer Hand. Wir beraten, wie sich Prozesse effizient digitalisieren lassen, mit oder ohne KI, und bauen die Software direkt mit. POC-First, Festpreis, Customer Excellence: kein Vertrag bevor Sie den Use-Case live in echtem Code gesehen haben. Das spart Ihnen drei bis sechs Monate Konzeptphase, vermeidet Fehlinvestitionen in nicht-realisierbare Konzepte und gibt Ihnen Entscheidungssicherheit auf Basis von echtem Code.

Build-Klassen mit Festpreis: Discovery-Sprint 2.500 € (5 Tage, abbrechbar). Custom-Build Small 25-35k (6-8 Wochen), Medium 35-55k (8-12 Wochen), Large 55-80k (12-16 Wochen) oder Multi-Phase für tiefere Plattformen. Maintenance-Retainer 500-2.500 €/Monat nach Go-Live.

Stack-Default: TypeScript überall, Next.js oder Astro für Web-Apps, Postgres über Supabase, Vercel oder AWS Frankfurt für Hosting, Anthropic Claude für AI-Integration. Eigene Software-Erfahrung aus drei live laufenden und mehreren abgeschlossenen Eigenprodukten (siehe Simon Maiwald) fliesst direkt in jedes Kundenprojekt.

Wenn Sie wissen wollen, ob Ihr aktueller Schmerzpunkt einen Custom-Build rechtfertigt: ein Strategiegespräch dauert 30 Minuten und ist kostenlos. Wir gehen die fünf Anzeichen aus diesem Leitfaden konkret für Ihre Situation durch und sagen ehrlich, ob Custom-Build die richtige Antwort ist, oder ob ein Standard-Tool plus AI-Integration mehr bringt.

Häufige Fragen

Wann lohnt sich Custom-Software gegenüber Standard-Tools?

Custom-Software lohnt sich, wenn drei Bedingungen zusammenkommen: (1) Ihr Prozess ist ein echter Wettbewerbsvorteil, kein Standard-Workflow, (2) bestehende SaaS-Tools zwingen Sie zu unsinnigen Workarounds, (3) das Volumen rechtfertigt mindestens fünfstellige Investition. Etwa 80 % der Mittelstand-Use-Cases werden besser durch konfiguriertes Standard-Tool plus AI-gestützte Integration gelöst. Die anderen 20 % rechtfertigen Custom-Build innerhalb von 18-36 Monaten.

Was kostet eine eigene Software-Lösung im Mittelstand realistisch?

Realistische Bandbreiten 2026 für Mittelstand-Custom-Software: Discovery-Sprint 2.500 € (5 Tage, abbrechbar) zur Validierung, danach Custom-Build Small 25-35k (6-8 Wochen), Medium 35-55k (8-12 Wochen), Large 55-80k (12-16 Wochen) oder Multi-Phase Build (pro Phase Festpreis, Re-Scoping zwischen Phasen) für tiefere Plattformen. Maintenance-Retainer 500-2.500 €/Monat nach Go-Live (entspricht 15-25 % der Initial-Kosten pro Jahr). Wer mit deutlich darunter angeboten bekommt, sollte Architektur und Wartung kritisch hinterfragen: Software wird nicht günstiger durch Tagessatz-Reduktion, sondern durch klare Anforderungen.

Wie lange dauert ein Custom-Software-Projekt?

Realistische Timelines: Discovery-Sprint 5 Arbeitstage zur Validierung, Custom-Build Small 6-8 Wochen, Medium 8-12 Wochen, Large 12-16 Wochen, Multi-Phase Build über mehrere Phasen verteilt (typisch 4-8 Monate). Wer ein Custom-Software-Projekt verkauft, das in 4 Wochen produktiv sein soll, plant nicht, er hofft. Realistische Erwartungen sind die Hälfte der Erfolgsformel.

Welcher Tech-Stack passt für KMU mit 50-250 Mitarbeitern?

Für die meisten Mittelstand-Anwendungen ist 2026 ein pragmatischer Default: Frontend Next.js oder Astro mit React/TypeScript, Backend Node.js oder Python, Datenbank Postgres (über Supabase oder direkt), Hosting Vercel oder AWS Frankfurt, AI-Integration über Anthropic Claude API. Diese Kombination deckt 80 % der Use-Cases, ist DSGVO-konform implementierbar, hat große Entwickler-Community und niedrige Lock-In-Risk. Spezial-Fälle (Hochlast, Spezial-Hardware, mobile Apps) verlangen Anpassungen.

Sollte Custom-Software in der Cloud oder On-Premise laufen?

Cloud (EU-Region) ist 2026 die pragmatische Default-Wahl für 90 % der Mittelstand-Anwendungen: niedrigere Wartungskosten, automatische Skalierung, EU-DSGVO-Konformität ist über AWS Frankfurt, Azure EU oder Google Cloud Belgium gegeben. On-Premise lohnt sich nur bei drei Triggern: hochsensible Daten (Verteidigung, spezielle Patientendaten), regulatorisches No-Cloud-Mandat, oder Token-/Compute-Volumen so hoch dass Hardware-Amortisation < 2 Jahre liegt.

Wie schütze ich mich vor Vendor-Lock-In bei Custom-Software?

Drei Architektur-Prinzipien minimieren Lock-In: (1) IP-Eigentum vertraglich beim Auftraggeber sichern (Code-Übergabe, Repository-Zugang), (2) Standard-Stack statt Nische verwenden (TypeScript/Python schlägt proprietäre Frameworks), (3) Kapselung externer Services hinter abstrahierten Schichten: kein direktes openai.chat.completions in der Business-Logic, sondern eigener generateAnswer-Service der intern routet. Wer alle drei umsetzt, kann den Anbieter wechseln ohne Software-Rewrite.

Weiterlesen

Fünf Spoke-Artikel, die einzelne Aspekte dieses Leitfadens vertiefen:

Konkret werden

Wenn Sie in der Make-or-Buy-Entscheidung stehen: