Billing for Outcomes, Not Hours: Das Ende der "Time-and-Materials"-Entwicklung

In der etablierten IT-Landschaft hat das Geschäftsmodell der "Billable Hours" – die Abrechnung nach Zeitaufwand – jahrzehntelang für Stabilität gesorgt. Es war eine rationale Antwort auf die Unvorhersehbarkeit komplexer Softwareprojekte: Da der Weg zum Ziel oft unklar war, wurde der Aufwand vergütet.

Doch technologische Fortschritte haben die Rahmenbedingungen verändert, während die vertraglichen Strukturen oft gleich geblieben sind. Das Resultat ist ein struktureller Fehlanreiz: Das klassische Agenturmodell profitiert finanziell davon, wenn Lösungen lange dauern und komplex sind.

Wir steuern auf eine Marktkorrektur zu. Es etabliert sich eine neue Klasse von Architekturen, deren ökonomischer Vorteil nicht im "Verkaufen von Zeit", sondern im "Verkaufen von Lösungen" liegt. Wir nennen dies Software-Arbitrage: Die Diskrepanz zwischen dem hohen Wert einer geschäftlichen Lösung und den drastisch gesunkenen Kosten, diese technisch umzusetzen.

Das Missverständnis moderner Stacks

Für Stability-Focused Architects und Entscheidungsträger in der klassischen Enterprise-IT wirken moderne Stacks (Next.js, Vercel, Serverless) auf den ersten Blick oft wie reine Frontend-Spielereien. Diese Skepsis ist verständlich: Wer jahrzehntelang Verantwortung für Supply-Chain-Sicherheit und Long-Term-Maintenance getragen hat, vertraut nicht blind jedem neuen Framework.

Doch der strategische Vorteil dieser Technologien liegt nicht in der Oberfläche, sondern in der Orchestrierung.

Betrachten wir ein konkretes Beispiel: Die Implementierung einer mehrsprachigen Lokalisierung in einem Webshop.

• Der klassische Ansatz ("Time-and-Materials"): Es werden Tickets erstellt, Datenbank-Schemata erweitert und Interfaces für Übersetzer gebaut. Ein Team ist zwei Wochen beschäftigt. Die Rechnung ist hoch, der Umsatz für die Agentur gesichert.
• Der Outcome-basierten Ansatz: Die Middleware fängt den Request ab, nutzt eine AI-API (wie DeepL oder OpenAI) und cached das Ergebnis in Millisekunden an der Edge (z.B. via Upstash). Implementierungsdauer: Ein Nachmittag. Laufende Kosten: Minimal.

Für den Endnutzer ist das Ergebnis identisch. Für das Unternehmen ist der Unterschied jedoch fundamental: Der klassische Weg bezahlt für den Prozess des Tippens. Der moderne Weg bezahlt für das Ergebnis der Intelligenz.

Der Incentive-Gap: Warum "Building from Scratch" ein Risiko wird

Das Problem liegt nicht bei den Entwicklern oder den Agenturen selbst, sondern im Anreizsystem. Wenn ein Dienstleister nach Stunden bezahlt wird, ist "Building from Scratch" – also das manuelle Bauen von Datenbank-Wartungsskripten oder Server-Patching – wirtschaftlich sinnvoll. Es generiert Umsatz.

In einer Welt von Managed Services und AI-APIs entsteht hier jedoch ein Efficiency Gap.

Ich beobachte Projekte, in denen fünfstellige Budgets für Features veranschlagt werden, die durch intelligente API-Orchestrierung ("Composing Intelligence") zu einem Bruchteil der Kosten realisierbar wären. Wer heute noch primär manuelle Implementierung als Wertschöpfung verkauft, gerät unter Druck – nicht weil die Qualität schlecht ist, sondern weil die Time-to-Value nicht mehr wettbewerbsfähig ist.

Software-Arbitrage bedeutet hier: Ich berechne Ihnen nicht die 4 Stunden, die ich für die Implementierung brauche. Ich berechne Ihnen den Wert der Lösung, die früher 4 Wochen gedauert hätte. Das aligniert meine Incentives mit Ihren: Je schneller und stabiler die Lösung, desto besser für beide Seiten.

Sicherheit durch Architektur, nicht durch Isolation

Ein häufiger Einwand gegenüber modernen PaaS-Lösungen betrifft die Datensouveränität. Fragen wie "Ist das Secret in der Middleware sicher?" oder "Warum hosten wir das LLM nicht On-Premise im Keller?" sind absolut legitim. Datensicherheit und Compliance sind in Deutschland nicht verhandelbar.

Es ist jedoch wichtig, das Sicherheitskonzept neu zu bewerten. Traditionell bedeutete Sicherheit oft physische Kontrolle ("Ich kann den Server anfassen"). Im Jahr 2025 ist physische Kontrolle jedoch nicht mehr gleichbedeutend mit Sicherheit. Oft führen "Legacy Habits" – wie manuelles Patch-Management durch überlastete Infrastructure Manager – zu größeren Sicherheitslücken als moderne Cloud-Umgebungen.

Moderne Architektur schafft Sicherheit durch Standardisierung und Reduktion der menschlichen Fehlerfläche. Managed Services eliminieren ganze Kategorien von Wartungsrisiken. Wir tauschen die gefühlte Sicherheit der eigenen Hardware gegen die tatsächliche Sicherheit einer gehärteten, automatisierten Infrastruktur.

Fazit: Code ist eine Verbindlichkeit

Mein architektonischer Leitsatz mag kontraintuitiv klingen, ist aber die Basis für effiziente Skalierung: Code is Liability (Verbindlichkeit).

Jede Zeile Code, die wir schreiben, muss gewartet, getestet und gesichert werden. Jeder eigene Server ist eine potenzielle Fehlerquelle. Deshalb ist das Ziel der Software-Arbitrage nicht "mehr Code", sondern "mehr Ergebnis".

• Weniger eigene Infrastruktur.
• Weniger Boilerplate.
• Mehr Managed Services und Intelligence-as-a-Service.

Wir bewegen uns weg von statischer Software-Entwicklung hin zu dynamischer Orchestrierung. Wer dieses Mindset adaptiert, zahlt nicht mehr für die Anwesenheit von Entwicklern, sondern für die Geschwindigkeit der Innovation.

Marco Patzelt Full-Stack Engineer | Building the Future of Agentic Orchestration