Softwareentwicklung — Custom-Software, Web-Apps und Architektur 2026

Software ist 2026 für mittelständische Unternehmen kein Werkzeug mehr, sondern der zentrale Hebel für Differenzierung, Skalierung und operative Effizienz. Wer einen Geschäftsprozess in Software gießt, kann ihn präzise messen, schrittweise verbessern und ohne zusätzliches Personal skalieren. Wer ihn als Excel-Tabelle, Mail-Ping-Pong oder mündliche Übergabe betreibt, zahlt täglich Reibungsverluste. Gleichzeitig ist die Entscheidung „Welche Software für welchen Prozess?" anspruchsvoller geworden: zwischen fertigen SaaS-Produkten, Low-Code-Plattformen und individueller Custom-Software liegen heute echte Wahlmöglichkeiten mit sehr unterschiedlichen Kosten-, Risiko- und Tempo-Profilen. Dieser Leitfaden zeigt, wann welche Variante richtig ist, welcher Tech-Stack 2026 stabil trägt, wie eine professionelle Architektur aussieht und welche Kosten realistisch sind.

Warum individuelle Softwareentwicklung 2026 ein Wettbewerbsvorteil ist

Der Mittelstand in DACH hat in den letzten zehn Jahren überwiegend auf Standardsoftware gesetzt — und das war meist die richtige Entscheidung. Buchhaltung, klassisches CRM, ERP-Kernfunktionen sind standardisiert, weil sie überall ähnlich funktionieren. Doch genau dadurch entsteht ein Problem: Wenn alle Mitbewerber mit derselben Standardsoftware arbeiten, kann Software nicht mehr Differenzierungsmerkmal sein. Wettbewerbsvorteile entstehen heute dort, wo Sie Prozesse haben, die Ihre Konkurrenz nicht hat — und diese Prozesse abzubilden, geht selten mit Standardsoftware.

Drei Treiber machen Custom-Software 2026 wirtschaftlich attraktiver als noch vor fünf Jahren. Erstens fallende Baukosten: moderne Frameworks wie Next.js, SvelteKit und Nuxt 4 plus etablierte Komponenten-Bibliotheken (shadcn/ui, Mantine, Radix) reduzieren den Implementierungsaufwand um 40 bis 60 Prozent gegenüber 2020. Zweitens KI-Assistenz: Entwickler-Tools wie Cursor, GitHub Copilot und Claude Code schreiben heute den Boilerplate-Code, der früher 30 Prozent der Bauzeit verschlungen hat. Drittens steigende Standardsoftware-Kosten: SaaS-Lizenzen sind in den letzten drei Jahren um 25 bis 60 Prozent gestiegen, parallel wurden Funktionen in höhere Tarife verschoben. Ab einer bestimmten Lizenz-Summe pro Jahr wird Eigenbau wirtschaftlicher als immer höhere Mietgebühren.

Praktisch heißt das: Wer einen Geschäftsprozess hat, der wirklich Ihrer ist, sollte 2026 ehrlich rechnen, ob die fortlaufende Anpassung einer Standardlösung wirtschaftlich noch trägt — oder ob eine fokussierte Eigenentwicklung mit klarem MVP-Scope nicht die bessere Investition in die nächsten zehn Jahre ist.

Custom-Software vs Standard vs Low-Code — ein Entscheidungs-Framework

Drei Optionen stehen heute zur Wahl, und jede hat ein klares Einsatz-Profil. Die Entscheidung ist keine Glaubensfrage, sondern hängt an wenigen objektiven Kriterien.

Standardsoftware (SaaS) ist richtig, wenn der Prozess sich an etablierte Software anpassen lässt, kein Differenzierungspotenzial im Prozess steckt, schnelle Verfügbarkeit wichtiger ist als perfekte Passung, und das Lizenzvolumen pro Jahr unter etwa 30.000 Euro bleibt. Klassische Felder: Buchhaltung (DATEV, Sage, Lexware), klassisches CRM (HubSpot, Pipedrive, Salesforce Starter), Projektmanagement (Asana, Linear, Jira), HR-Stamm (Personio, BambooHR).

Low-Code-Plattformen (Microsoft Power Platform, Mendix, OutSystems, Retool, Bubble) sind richtig, wenn es um interne Tools mit überschaubarer Komplexität geht, das Team einen technisch versierten Power-User hat (Citizen Developer), und Wartbarkeit über fünf bis sieben Jahre akzeptabel ist. Vorsicht-Punkt: Low-Code wirkt am Anfang schneller, wird aber bei wachsender Logik schnell unwartbar und schafft Vendor-Lock-in. Für formularlastige interne Workflows oft die richtige Wahl, für Kundenprodukte selten.

Custom-Software ist richtig, wenn der Prozess Ihr Differenzierungsmerkmal ist, keine passende Standardlösung existiert, mehrere Hundert Nutzer oder hohe Anforderungen an UX, Performance oder Compliance bestehen, oder die jährliche Lizenzsumme einer Standardlösung über 50.000 Euro liegt und weiter wächst. Klassische Felder: Branchen-spezifische Plattformen, Kundenportale mit eigener Identität, B2B-Marktplätze, datenintensive Steuerungssysteme, regulierte Anwendungen mit individuellem Compliance-Profil.

Der häufigste Fehler in der Praxis: Unternehmen wählen eine Standardlösung, passen sie mit Customizing an, zahlen über die Jahre 60 bis 120 Prozent des Lizenzpreises an Anpassungskosten und sitzen am Ende auf einer schlecht wartbaren Sonderlösung im Standardmantel. Wenn Sie schon im Discovery merken, dass mehr als 30 Prozent der Lizenz-Funktionen ungenutzt bleiben und mehr als 30 Prozent durch Customizing ergänzt werden müssen, ist Custom-Software meist die wirtschaftlichere Wahl.

Web-Anwendungen 2026 — TypeScript, Next.js, Vue, SvelteKit, Tailwind

Web-Anwendungen sind 2026 die dominante Form der Geschäftssoftware — vor mobilen Apps, vor Desktop-Anwendungen. Drei Gründe: universelle Erreichbarkeit ohne Installation, zentrale Updates ohne Endgeräte-Roll-out, einheitlicher Tech-Stack zwischen interner Verwaltung und externem Kundenportal. Die Stack-Frage hat sich in den letzten Jahren konsolidiert.

TypeScript als Sprache ist 2026 unangefochten die richtige Wahl für Neuentwicklungen. Statische Typprüfung, hervorragende IDE-Unterstützung, breite Verfügbarkeit von Bibliotheken und ein riesiger Talentpool. Plain JavaScript empfehlen wir nur noch für sehr kleine Skripte oder Legacy-Code.

Next.js mit App Router ist der De-facto-Standard für komplexere Web-Anwendungen — React-basiert, serverseitiges Rendering, integrierte API-Routes, hervorragende Performance, sehr breite Entwickler-Verfügbarkeit. Next.js 16 (Cache Components, Partial Prerendering) liefert 2026 die beste Mischung aus Entwickler-Produktivität und Endbenutzer-Performance. Hosting auf Vercel oder als Standalone-Build auf eigener Infrastruktur.

SvelteKit ist die schlanke Alternative für Teams, die kleinere Bundle-Größen, einfachere Reaktivitäts-Mechanik und weniger Boilerplate schätzen. Svelte 5 mit Runes hat 2026 eine sehr aufgeräumte Programmiermodell-Story. Geeignet für mittelgroße Anwendungen mit kleinem bis mittlerem Team.

Vue.js mit Nuxt 4 bleibt eine valide Wahl, besonders in Europa stark vertreten. Geringere Einstiegshürde als React, gute Performance, etabliertes Ökosystem. Sinnvoll, wenn Ihr Team bereits Vue-Erfahrung hat oder wenn Sie Entwickler in Regionen suchen, in denen Vue verbreiteter ist als React (Frankreich, Teile Osteuropas).

Tailwind CSS ist 2026 der etablierte Standard für Styling. Utility-first, sehr produktiv, kombinierbar mit Komponenten-Bibliotheken wie shadcn/ui, Radix UI oder Headless UI. Klassisches CSS oder CSS-in-JS verlieren weiter an Marktanteil.

Unsere Default-Empfehlung für ein neues Mittelstands-Projekt 2026: TypeScript + Next.js (App Router) + Tailwind + shadcn/ui für die UI-Schicht, PostgreSQL + Drizzle ORM für die Datenschicht, Vercel oder ein klassisches PaaS für das Hosting, Vitest und Playwright für Tests. Mit diesem Stack baut ein erfahrenes Team in 90 Tagen einen produktiven MVP.

APIs — REST vs GraphQL vs gRPC vs tRPC

Die API-Schicht entscheidet darüber, wie gut Ihre Anwendung mit anderen Systemen, Clients und Partnern zusammenarbeitet. Vier Stile sind 2026 relevant, jeder mit klarem Einsatzfeld.

REST bleibt der Default für öffentliche APIs, Partner-Integrationen und einfache Client-Server-Anwendungen. Vorteile: universell verstanden, exzellente Werkzeugkette (OpenAPI/Swagger für Spezifikation und Code-Generierung, Postman/Insomnia für Tests, Caching über Standard-HTTP-Mechanismen). Nachteile: Over-Fetching und Under-Fetching bei komplexen UIs, viele Endpoints bei großen Datenmodellen. Für 70 Prozent aller Projekte die richtige erste Wahl.

GraphQL lohnt sich, wenn Sie mehrere Clients mit unterschiedlichem Datenbedarf bedienen (Web, Mobile, Public API) oder wenn Over-Fetching ein echtes Problem ist. Apollo Server und Mercurius (für Fastify) sind 2026 die etablierten Server-Implementierungen. Nachteile: höhere Komplexität in Authorization, Caching und Performance-Tuning (N+1-Problem über DataLoader-Patterns lösen), steilere Lernkurve im Team.

gRPC ist die richtige Wahl für interne Service-zu-Service-Kommunikation mit hohem Durchsatz und engen Latenz-Anforderungen — Protobuf-Schema, HTTP/2, Streaming nativ unterstützt. Sinnvoll in Microservice-Architekturen oder bei Echtzeit-Datenströmen. Für externe APIs ungeeignet, weil Browser-Support nur über gRPC-Web mit Reverse Proxy funktioniert.

tRPC ist eine pragmatische, neuere Option für TypeScript-Monorepos, in denen Client und Server vom selben Team entwickelt werden. Typsicherheit von der Datenbank bis zum UI ohne separate API-Spezifikation, ohne Code-Generierung. Für interne Tools und kleine bis mittlere SaaS-Anwendungen sehr produktiv. Ungeeignet für sprach- oder team-übergreifende Schnittstellen.

Praktische Faustregel: REST für extern, tRPC für intern in TypeScript-Stacks, gRPC für interne Service-zu-Service-Aufrufe mit Performance-Anforderungen, GraphQL nur bei nachweislichem Bedarf. Die meisten Projekte brauchen genau einen API-Stil — nicht drei parallel.

Mobile — Native iOS/Android vs React Native vs Flutter vs Capacitor

Mobile Apps sind 2026 selten der Default — die meisten Mittelstands-Anforderungen lassen sich mit einer Progressive Web App (PWA) erschlagen. Aber wenn Sie wirklich eine App brauchen, stehen vier Optionen zur Wahl.

Native (Swift für iOS, Kotlin für Android) ist die Wahl, wenn Sie eine Premium-Consumer-Erfahrung anbieten, häufig auf aktuelle Plattform-APIs zugreifen (Apple Vision, ARKit, Health, Wallet), oder hardware-nahe Funktionen brauchen (Bluetooth Low Energy, NFC, Kamera-Steuerung). Aufwand: zwei separate Codebasen, höchster Implementierungs- und Wartungsaufwand, dafür beste UX und beste Plattform-Integration.

React Native ist 2026 die etablierte Cross-Platform-Wahl für Business- und B2B-Apps. Ein TypeScript-Stack, sehr breite Bibliotheken-Auswahl, native Module bei Bedarf nachladbar. Mit Expo als Framework reduziert sich die Initial-Komplexität deutlich. Erreicht 85 bis 95 Prozent native Erfahrung bei 50 bis 60 Prozent Aufwand gegenüber zwei nativen Codebasen.

Flutter ist Googles Cross-Platform-Antwort, eigene Sprache (Dart), eigenes Rendering. Liefert pixel-genaue UIs auf iOS und Android und auf Wunsch auch Web und Desktop. Vorteil: konsistente Optik über Plattformen, sehr gute Performance bei Animationen. Nachteil: Dart ist eine Nischensprache, kleinerer Talentpool als React Native, weniger Drittanbieter-Bibliotheken.

Capacitor (Ionic) packt eine Webanwendung in einen nativen Container. Geeignet, wenn Sie eine Webanwendung haben und sie ohne große Umbauten in die App Stores bringen wollen. UX-Qualität ist deutlich unter Native und React Native, aber der Aufwand ist minimal. Sinnvoll für interne Tools, Informations-Apps oder als Brücke zu einem späteren echten Mobile-Build.

Unsere Empfehlung: PWA als Default, React Native mit Expo bei echtem Mobile-Bedarf, Native nur bei Premium-Consumer-Apps oder starken Plattform-Integrationen. Flutter ist eine valide Wahl, aber selten der wirtschaftlichste Default in DACH.

Datenbanken — Postgres, MySQL, MongoDB, SQLite, ClickHouse, Vector-DBs

Die Datenbankwahl hat langfristige Folgen — Wechsel sind aufwändig und riskant. Drei Klassen, jede mit eigenem Einsatzfeld.

Relationale Datenbanken bleiben der Default für 90 Prozent aller Geschäftsanwendungen. PostgreSQL ist 2026 die richtige Wahl für nahezu jedes neue Projekt: ACID-Transaktionen, JSON-Unterstützung über JSONB, Volltext-Suche, Geo-Daten über PostGIS, Vektor-Suche über pgvector. Managed-Hosting über Neon, Supabase, AWS RDS oder Hetzner Cloud-Postgres. MySQL bleibt relevant in bestehenden Stacks, hat aber gegenüber Postgres an Funktionsvorsprung verloren. Für Neuprojekte empfehlen wir Postgres. SQLite ist die richtige Wahl für eingebettete Anwendungen, Desktop-Software (mit Better-SQLite3 in Electron-Apps) und kleine SaaS-Anwendungen mit wenig Schreiblast (Turso, Cloudflare D1).

Dokumentenorientierte Datenbanken (MongoDB) sind 2026 deutlich weniger gerechtfertigt als noch vor fünf Jahren — Postgres mit JSONB deckt 80 Prozent der MongoDB-Use-Cases ab, bei besserer Datenkonsistenz. MongoDB lohnt sich nur noch, wenn Ihr Datenmodell wirklich dokumenten-zentrisch ist und keine relationalen Beziehungen abbildet.

Spezialisierte Datenbanken ergänzen den relationalen Kern. ClickHouse für Analytics-Workloads mit Milliarden von Events und Sub-Sekunden-Aggregationen, Redis für Caching und Session-Speicher, Elasticsearch oder OpenSearch für Volltext-Suche bei hohem Volumen (für moderate Volumina reicht oft die Postgres-eigene Suche). Vektor-Datenbanken wie Qdrant, Weaviate, Pinecone oder pgvector werden für RAG-Architekturen und semantische Suche relevant — für die meisten Mittelstands-Use-Cases reicht pgvector als Erweiterung der bestehenden Postgres-Datenbank.

Unsere Default-Empfehlung: PostgreSQL als Single Source of Truth, Redis für Caching wenn nötig, pgvector für semantische Suche wenn nötig, ClickHouse erst wenn Postgres-Analytics-Queries wirklich zu langsam werden. Vermeiden Sie Polyglot-Persistence (mehrere DB-Systeme parallel) so lange wie möglich — jedes zusätzliche System kostet Betrieb, Monitoring und Konsistenz-Aufwand.

Architektur — Monolith, Modular Monolith oder Microservices

Die Architekturfrage ist 2026 für die meisten Mittelstands-Projekte einfacher zu beantworten als die Branche es darstellt. Drei Stufen, klare Entscheidungspunkte.

Monolith: eine Codebasis, ein Deployment, eine Datenbank. Der schnellste, einfachste und für 70 Prozent aller Projekte richtige Ansatz. Kein Latenz-Overhead durch interne Service-Aufrufe, einfache Transaktionen, geringer Betriebsaufwand. Skaliert mit moderner Hardware bis weit über die Anforderungen typischer Mittelstands-Anwendungen.

Modular Monolith: eine Codebasis und ein Deployment, aber mit klaren Modul-Grenzen, sauberen Abhängigkeiten und domänen-orientierter Struktur. Vorbereitung auf den möglichen späteren Schritt zu separaten Services, ohne die Komplexitäts-Kosten heute zu zahlen. Unsere Standard-Architektur für neue Mittelstands-Projekte — Komplexität bleibt beherrschbar, der Migrationspfad bleibt offen.

Microservices: mehrere separate Deployments, jedes mit eigener Datenbank, kommunizierend über APIs oder Events. Lohnt sich erst, wenn unabhängige Deployment-Zyklen pro Domäne wirtschaftlich wertvoll werden — typisch ab 30 oder mehr Entwicklern, organisiert in mehreren Teams. Vorteile: unabhängige Skalierung, Sprachvielfalt möglich, klare Team-Grenzen. Nachteile: Netzwerk-Latenz, verteilte Transaktionen, höherer Betriebsaufwand, schwierigere Fehlersuche über Service-Grenzen hinweg.

Der häufigste Fehler 2026: Microservices werden gewählt, weil sie modern klingen, nicht weil die Organisation sie wirtschaftlich braucht. Ein Team von fünf Entwicklern mit acht Microservices verbringt 30 bis 50 Prozent seiner Zeit mit Infrastruktur-Themen statt mit Geschäftsfunktionen. Unsere Empfehlung: Starten Sie mit einem Modular Monolith. Wenn Sie in drei Jahren wachsen und einzelne Domänen wirklich getrennt skalieren müssen, lassen sich Module zu Services ausgliedern — die Vorbereitung steckt schon in der Modul-Struktur.

Reepa Solutions Approach — wir bauen unsere Plattformen selbst

Für Kundenprojekte arbeiten wir mit einem festen Vorgehensmodell, das wir aus über zehn Jahren Projekterfahrung destilliert haben. Phase 1: Discovery in zwei Wochen. Wir verstehen den Geschäftsprozess, identifizieren die wirklich differenzierenden Bestandteile, skizzieren die Architektur, klären Datenmodell und Integrationen, definieren den MVP-Scope mit klaren Abbruchkriterien. Phase 2: Bauphase in zwölf Wochen. Inkrementelle Auslieferung in Zwei-Wochen-Sprints, frühe Nutzer-Tests ab Woche sechs, kontinuierliche Demo-Termine mit dem Fachbereich. Phase 3: Roll-out und Übergabe in vier Wochen. Schulung der Anwender, Übergabe an internen Betriebs-Eigner, Monitoring-Aufbau, Dokumentation für Audit und Weiterentwicklung.

Dieser Aufbau ist nicht akademisch — er ist genau das Vorgehen, mit dem wir unsere eigenen Produkte bauen und mit dem wir Kundenprojekte vom MVP bis zur produktiven Plattform begleiten.

Testing-Strategie — Unit, Integration, E2E, Visual, Load

Testing ist kein Nebenprodukt der Entwicklung, sondern die Voraussetzung für Wartbarkeit und Änderbarkeit. Eine professionelle Testing-Strategie folgt der Pyramiden-Logik: viele schnelle, billige Tests an der Basis, wenige langsame, teure Tests an der Spitze.

Unit-Tests prüfen einzelne Funktionen und Module isoliert, laufen in Millisekunden, sollen 60 bis 80 Prozent Coverage in der Kern-Geschäftslogik erreichen. Werkzeuge 2026: Vitest für TypeScript-Stacks (deutlich schneller als Jest), Pytest für Python, Go testing für Go. Jede Pull Request prüft die Unit-Tests automatisch in der CI.

Integration-Tests prüfen das Zusammenspiel mehrerer Module gegen eine echte Datenbank, echte HTTP-Schnittstellen oder echte Message Queues. Werkzeuge: Testcontainers für isolierte Datenbank-Instanzen, MSW für HTTP-Mocking auf der Client-Seite. Diese Tests sind langsamer (Sekunden), aber unverzichtbar, weil sie die echten Integrations-Risiken abdecken, die Unit-Tests nicht sehen.

End-to-End-Tests prüfen den vollständigen Nutzer-Fluss durch die Anwendung. Werkzeuge: Playwright (unsere Default-Empfehlung — schnell, stabil, gute Tools), Cypress (etabliert), Detox für Mobile-Apps. Halten Sie diese Tests bewusst klein — die zehn wichtigsten Nutzer-Pfade abdecken, nicht jede Sub-Funktion. Sie sind die teuersten Tests im Setup und Wartungsaufwand.

Visual-Regression-Tests erfassen UI-Komponenten als Screenshots und alarmieren bei unbeabsichtigten visuellen Änderungen. Werkzeuge: Chromatic, Percy, Argos. Sinnvoll für Design-System-Komponenten und kritische UI-Bereiche, nicht für jede Seite.

Load-Tests prüfen das Verhalten unter Last vor dem Produktivstart. Werkzeuge: k6 (unsere Empfehlung — JavaScript-Skripte, gute Skalierung), Artillery, Gatling. Definieren Sie konkrete Lastziele (z. B. 500 gleichzeitige Nutzer, 95. Perzentil unter 800 Millisekunden) und prüfen Sie diese vor jedem Major-Release.

Praktische Faustregel: Wer eine Testing-Pyramide aus Unit + Integration + zehn E2E-Tests pflegt, kann mit drei Entwicklern eine Anwendung wartbar halten, die ohne Tests fünf Entwickler binden würde. Tests sind die wichtigste Investition in Geschwindigkeit jenseits der ersten zwölf Wochen.

Sicherheit by Design — OWASP-Awareness, SCA, DAST in der CI

Sicherheit ist 2026 keine optionale Zusatzleistung am Projektende, sondern ein Querschnitts-Thema durch die gesamte Entwicklung. Drei Ebenen müssen strukturiert abgedeckt sein.

Anwendungs-Sicherheit nach OWASP Top 10. Die OWASP Top 10 sind seit Jahren die etablierte Liste der häufigsten Schwachstellen-Klassen: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, Server-Side Request Forgery. Jedes Entwickler-Team sollte diese Klassen aktiv kennen und in Code-Reviews adressieren. Standardbibliotheken decken 80 Prozent ab — Helmet für HTTP-Security-Header, ORM mit Prepared Statements gegen Injection, JWT-Bibliotheken mit Default-sicherer Konfiguration.

Software Composition Analysis (SCA). Drittanbieter-Bibliotheken sind 2026 die häufigste Quelle für Schwachstellen — eine Anwendung hat typisch 800 bis 2.500 transitiven Abhängigkeiten. Werkzeuge: Snyk, Dependabot, Renovate, npm audit, OSV-Scanner. Jeder Pull Request prüft die Abhängigkeiten gegen aktuelle Schwachstellen-Datenbanken, kritische Befunde blocken den Merge. Bei aktiver Pflege liegt die durchschnittliche Patch-Zeit für kritische Schwachstellen unter sieben Tagen.

Dynamic Application Security Testing (DAST) in der CI. Automatisierte Sicherheits-Scans gegen die laufende Anwendung in der Staging-Umgebung. Werkzeuge: OWASP ZAP, Reepa Security (unser eigenes Tool mit über 100 Detektoren), Acunetix. Diese Scans laufen typisch wöchentlich oder vor jedem Release, finden Konfigurations-Schwächen, fehlende Header, exponierte Debug-Endpunkte und einige Klassen von Injection-Schwachstellen. Sinnvoll ergänzt durch jährliche manuelle Reviews und Audits durch externe Spezialisten.

Faustregel: Wer SCA und DAST in seine CI integriert und seine Entwickler einmal pro Jahr in einem zweitägigen OWASP-Top-10-Workshop schult, deckt 90 Prozent der praktisch relevanten Anwendungs-Sicherheitsrisiken ab. Die verbleibenden 10 Prozent (Geschäftslogik-Schwächen, Spezialitäten der Branche) brauchen einen jährlichen externen Audit.

Performance und Core Web Vitals

Performance ist 2026 ein hartes Geschäfts-Kriterium, kein Wohlfühl-Thema. Google-Ranking, Conversion-Raten und Nutzer-Bindung hängen messbar an Core Web Vitals. Drei Metriken stehen im Mittelpunkt.

Largest Contentful Paint (LCP) misst, wie schnell das größte sichtbare Element geladen ist. Ziel: unter 2,5 Sekunden im 75. Perzentil aller Nutzer. Haupthebel: Server-Response-Zeit, Bild-Optimierung (next/image, AVIF/WebP), Critical-CSS-Inlining, CDN-Nutzung, serverseitiges Rendering oder Pre-Rendering.

Interaction to Next Paint (INP) hat 2024 First Input Delay als Reaktivitäts-Metrik abgelöst. Misst die Reaktionszeit auf Nutzer-Interaktionen. Ziel: unter 200 Millisekunden. Haupthebel: JavaScript-Bundle-Größe reduzieren, Main-Thread-Arbeit aufteilen (requestIdleCallback, Web Workers), Hydration-Strategie optimieren (Islands Architecture, partielles Hydrating).

Cumulative Layout Shift (CLS) misst visuelle Stabilität — wie stark sich das Layout während des Ladens verschiebt. Ziel: unter 0,1. Haupthebel: feste Abmessungen für Bilder und Iframes, Skeleton-Loader statt nachträglich eingefügter Inhalte, Vorsicht bei Webfont-Loading.

Werkzeuge: Lighthouse für lokale Audits, PageSpeed Insights für reale Felddaten, Web Vitals JS-Library für eigenes Monitoring, Vercel Analytics oder Sentry Performance für Production-Tracking. Wir empfehlen, Core Web Vitals als harte Build-Schwelle in der CI zu hinterlegen — wer die Schwelle unterschreitet, kann nicht in Production deployen.

Legacy-Modernisierung — Strangler-Fig und Anti-Corruption-Layer

Viele Mittelstands-Unternehmen sitzen auf alter Software, die seit zehn bis zwanzig Jahren läuft, schwer wartbar geworden ist, aber zentrale Geschäftsprozesse trägt. Big-Bang-Ablösung (komplette Neuentwicklung, dann Cut-over) scheitert in der Praxis sehr häufig — zu groß, zu lang, zu risikoreich. Drei moderne Muster machen Legacy-Modernisierung beherrschbar.

Strangler-Fig-Pattern. Sie bauen neue Module schrittweise um die Altanwendung herum und leiten den Verkehr über einen Routing-Layer (Reverse Proxy, API-Gateway) schrittweise auf die neuen Komponenten um. Die Altanwendung wird Stück für Stück „umrankt", bis am Ende nur noch die neue Software übrig bleibt. Dauer für mittlere Legacy-Systeme: 12 bis 36 Monate, dafür kontinuierlicher Geschäftswert über die gesamte Laufzeit und kein einziger Big-Bang-Moment.

Anti-Corruption-Layer (ACL). Eine Übersetzungsschicht zwischen Alt- und Neu-System sorgt dafür, dass die neue Software das saubere, moderne Datenmodell hat und nicht die Designschwächen des Altsystems erbt. Der ACL übersetzt zwischen alten und neuen Datenstrukturen, kapselt die Eigenheiten der Altanwendung und kann bei vollständiger Ablösung einfach entfernt werden. Ohne ACL erbt jede Modernisierung die Probleme, die sie eigentlich beheben wollte.

Branch-by-Abstraction. Bei kleineren Komponenten-Wechseln (z. B. Wechsel der Datenbank, eines Frameworks oder einer Drittbibliothek) führen Sie eine Abstraktionsschicht ein, lassen Alt- und Neu-Implementierung parallel laufen, schalten den Verkehr per Feature-Flag stufenweise um und entfernen am Ende die alte Implementierung. Diese Methode ist die sichere Wahl für interne technische Umbauten ohne Geschäfts-Sichtbarkeit.

Was Sie nicht tun sollten: eine Neuentwicklung zwei Jahre im Stealth-Modus laufen lassen und dann an einem Wochenende umschalten. Diese Strategie ist verantwortlich für die meisten Modernisierungs-Desaster der letzten zwanzig Jahre. Inkrementell, mit klaren Zwischenständen, ist langfristig schneller und sicherer.

Kosten und Timeline einer Custom-Software

Realistische Zahlen aus echten Projekten, kein Marketing-Optimismus. Drei Größenklassen.

MVP-Klasse (40.000 bis 80.000 Euro, 3 bis 4 Monate). Ein klar abgegrenzter Anwendungsfall, ein primärer Nutzer-Typ, zwei bis vier Kern-Workflows, ein bis zwei externe Integrationen. Team: ein Senior-Full-Stack, ein Mid-Level-Full-Stack, ein Product-Owner anteilig, ein UX-Designer anteilig. Ergebnis: produktiv nutzbare Anwendung für eine erste Nutzergruppe, ausbaubar auf Basis echter Nutzungsdaten.

Mittlere Geschäftsanwendung (120.000 bis 280.000 Euro, 5 bis 9 Monate). Kundenportal mit Authentifizierung, internes Tool mit Rollen-Konzept, fachspezifische Plattform mit moderater Komplexität. Mehrere Nutzer-Rollen, fünf bis zehn Kern-Workflows, vier bis acht Integrationen (ERP, CRM, Buchhaltung, externe APIs), mobile-responsive Web-Oberfläche. Team: zwei bis drei Entwickler, ein Architekt, ein Product-Owner, ein UX-Designer, anteilig ein DevOps.

SaaS-Plattform oder Branchenlösung (350.000 bis 900.000 Euro im ersten Jahr). Mehrmandantenfähigkeit, mehrere Nutzer-Rollen pro Mandant, Self-Service-Onboarding, Billing-Integration, mobile App oder PWA, umfangreiches Integrations-Ökosystem, hohe Performance- und Verfügbarkeits-Anforderungen. Team: vier bis acht Entwickler, ein Architekt, ein Tech-Lead, ein Product-Owner, ein UX-Designer, ein DevOps-Engineer, ein QA-Engineer.

Laufende Betriebskosten: 15 bis 25 Prozent der Initialinvestition pro Jahr. Hosting, Monitoring, Sicherheits-Updates, Bibliotheks-Upgrades, kleinere Feature-Anpassungen. Wer diese Pflege nicht einplant, hat in drei Jahren eine veraltete, schwer wartbare Software — der häufigste Grund für vorzeitige Neuentwicklungen, die eigentlich vermeidbar gewesen wären.

Anbieter-Auswahl-Checkliste — Nearshore, Offshore vs Inhouse

Drei Beschaffungs-Optionen, jede mit klarem Kosten-Risiko-Profil.

Inhouse-Entwicklung ist sinnvoll, wenn Software Ihr Kernprodukt ist und Sie das Wissen langfristig binden wollen. Kosten pro Senior-Entwickler in DACH: 90.000 bis 130.000 Euro Jahresgehalt plus 25 bis 30 Prozent Nebenkosten, also realistisch 115.000 bis 170.000 Euro vollkostenbasiert. Plus Personalsuche (12 bis 24 Wochen Time-to-Hire), Einarbeitung (3 bis 6 Monate bis zur vollen Produktivität), Personalrisiken (Krankheit, Kündigung, Elternzeit).

Nearshore (Portugal, Polen, Rumänien, Spanien, Bulgarien) ist 2026 die häufigste Wahl im Mittelstand. Stundensätze 50 bis 65 Euro für Senior-Entwickler, gleiche Zeitzone, ähnliche Arbeitskultur, Englisch als gemeinsame Arbeitssprache, EU-Datenschutz-Niveau. Vorteile gegenüber Inhouse: schnellere Verfügbarkeit, flexible Team-Größe, kein Personalrisiko. Nachteile: geringere Wissensbindung im Unternehmen, höherer Kommunikations-Aufwand als bei Inhouse.

Offshore (Indien, Vietnam, Lateinamerika, Ägypten) startet bei Stundensätzen von 25 bis 45 Euro. Erfordert deutlich straffere Spezifikation, mehr Review-Aufwand, gute technische Führung auf Ihrer Seite. Zeitzonen-Unterschied kann je nach Region Vor- oder Nachteil sein (Lateinamerika gut zu DACH-Zeiten, Asien für 24/7-Setups interessant). Risiko-Faktor: Qualitäts-Streuung ist groß, mit einem guten Anbieter sehr produktiv, mit einem mittelmäßigen Anbieter schnell teurer als Nearshore.

Hybrid-Modell ist 2026 die häufige Wahl im Mittelstand: Architektur, Lead-Entwicklung und Product-Owner-Funktion inhouse oder Nearshore, Umsetzungs-Teams im günstigeren Offshore-Setup. Diese Kombination liefert die Wissensbindung im Kern und die Kosten-Effizienz in der Breite.

Auswahl-Checkliste für externe Anbieter: Referenzen aus vergleichbaren Branchen und Größenordnungen, Code-Probe aus einem laufenden Projekt (mit Erlaubnis des Auftraggebers), klare Rollen-Definition (wer ist Tech-Lead, Architekt, Senior, Junior), dokumentierte Test- und Review-Praxis, vertragliche IP-Übertragung an Sie, Datenschutz-Konformität mit DSGVO-Auftragsverarbeitungsvertrag, klare Eskalations- und Kündigungs-Regelungen, monatliche Festpreis-Komponente plus stundenbasierter Anteil für Klarheit.

Häufige Fragen

Vertiefende Artikel & Cases

Dieser Pillar deckt den Überblick ab — für die operative Tiefe verweisen wir auf die spezialisierten Artikel pro Themenbereich. Jeder Artikel ist eigenständig nutzbar und greift wieder auf diesen Software-Guide zurück.

Aus unseren Projekten

Hakan Akcan · Gründer & Geschäftsführer Reepa Solutions

IT-Sicherheits- und Cloud-Architekt mit über zehn Jahren Erfahrung. Entwickelt mit seinem Team die Reepa-Plattformen (Reepa Security, Reepa Web Builder) auf modernen TypeScript-Stacks und betreibt sie produktiv. Schreibt regelmäßig über Software-Architektur, Stack-Wahl und Build-vs-Buy-Entscheidungen für den Mittelstand.

Geprüft am: 22. Mai 2026 · Mehr über Hakan