Ein Gründer rief mich im November 2024 an, zwei Wochen vor Weihnachten, absolut wütend. Eine Web-Agentur hatte ihm 14.000 £ für ein maßgeschneidertes Logistik-Dashboard kalkuliert. Er hatte unterschrieben. Sechs Monate später kam die Schlussrechnung: 61.000 £. Niemand hatte ihn angelogen, technisch gesehen. Aber niemand hatte ihm die Wahrheit gesagt, weil niemand die Arbeit gemacht hatte, vorher ordentlich zu kalkulieren, bevor man sein Geld nahm.
Kernproblem: Maßgeschneiderte Software scheitert fast immer bei der Scopefestlegung. Nicht in der Entwicklung selbst. Rechnen Sie mit der Komplexität des Datenmodells, den Integrationen und den Review-Zyklen. Die Discovery-Phase sollten Sie getrennt bewerten.
Ich baue Software seit über zwölf Jahren. Seahawk allein hat mehr als 12.000 Websites und Anwendungen ausgeliefert. Und der einzelne konsistenteste Fehlerpunkt, den ich sehe – bei Gründern, bei Freelancern, bei Agenturen, die Projekte kalkulieren – ist, dass niemand eine rigorose Methode hat, Kosten zu schätzen, bevor eine Zeile Code geschrieben wird. Leute raten. Sie ankern sich an Gefühle. Sie nutzen das letzte Projekt als Referenz, ohne zu checken, ob es überhaupt vergleichbar war.
Also. Hier ist das Framework, das ich tatsächlich nutze. Nicht eine Spreadsheet-Vorlage mit Platzhalter-Zellen. Ein echtes mentales Modell, mit aktuellen Zahlen von 2026, spezifischen Tools und den Einschränkungen, die zählen.
---
Warum die meisten Software-Angebote Fiktion sind
Das Problem ist nicht Unehrlichkeit (normalerweise). Es ist, dass Software-Estimation wirklich schwer ist, und die meisten unterschätzen, wie schwer, also greifen sie zu Abkürzungen, die sich rigoros anfühlen, es aber nicht sind.
Ein Developer gibt dir eine Bauchzahl. Eine Agentur multipliziert ihren Tagessatz mit einer geschätzten Sprint-Anzahl. Ein Freelancer schaut sich ein ähnliches Gig auf Upwork an und rechnet rückwärts. Keine dieser Methoden ist exakt falsch, aber keine berücksichtigt die echten Kostentreiber: Integrationskomplexität, Entscheidungsverzögerungen auf Kundenseite, Scope Creep bei Features, die unbedeutend wirken, Test-Overhead, und der stille Killer – Environment Setup und DevOps, die niemand einkalkuliert.
2021 lief ich ein Projekt für einen PropTech-Kunden in Manchester. Auf dem Papier einfach genug: ein Tenant Portal mit Document Upload, Miettracking und einen Maintenance-Request-Workflow. Erste Kalkulationen: 28.000 £. Wir hatten ähnliche Builds gemacht. Aber dieser Kunde nutzte ein Legacy-Property-Management-System mit einer proprietären API, die niemand seit vier Jahren angefasst hatte. Integration allein sprengte drei Wochen. Endsumme: 47.500 £. Der Kunde war ok damit, weil wir ihn gewarnt hatten, sobald wir die API-Docs fanden, aber die erste Kalkulationen war trotzdem Fiktion, und ich stehe dazu.
Der Cone of Uncertainty ist real
Der Cone of Uncertainty, popularisiert von Steve McConnell, beschreibt, wie Projekt-Schätzungen genauer werden, je näher man der Fertigstellung kommt. Bei der Ideenfindung kannst du um das 4-fache in beide Richtungen daneben liegen. Nach detailliertem Design vielleicht 1,25-fach. Die meisten Gründer bekommen Angebote in der Ideenfindungs-Phase und behandeln sie wie unterzeichnete Verträge.
Die praktische Konsequenz: Jedes Angebot, das du vor detaillierten Specs erhältst, sollte du als Range behandeln, nicht als Zahl. Wenn eine Agentur dir eine einzelne Ziffer gibt, bevor sie dein Datenmodell, User Flows und Third-Party-Abhängigkeiten gesehen hat, ist diese Zahl dekorativ.
---
Die vier echten Kostenkategorien
Bevor ein Estimator arbeiten kann, musst du das Projekt in die richtigen Kategorien aufteilen. Nicht „Frontend, Backend, QA", das sind Rollen, keine Kostentreiber. Die echten Buckets:
1. Greenfield vs. Integrations-Arbeit
Greenfield, etwas von Grund auf gegen deine eigene Datenbank und Business Logic bauen, ist die billigere, vorhersagbarere Hälfte fast jedes Projekts. Es ist die Integration-Arbeit, die dich erwischt. Jede externe API, jedes Legacy-System, jeder Payment Processor oder Third-Party-Auth-Provider addiert nicht-lineare Komplexität. Ich rechne typischerweise 30–40 % Puffer auf jede Scope-Zeile, die externe Systeme berührt.
2. UI/UX-Design (Überspring diese Position nicht)
Viele Gründer behandeln Design als optional oder versuchen, es in die Development-Kalkulationen zu rollen. Fehler. Design, ordentlich gemacht – Wireframes, interaktive Prototypen in Figma, eine getestete Component Library – läuft normalerweise 15–25 % der Gesamtprojektkosten. Skip es und du zahlst doppelt: einmal in Developer-Rework, wenn sich Anforderungen als mehrdeutig herausstellen, und nochmal in User Research später, wenn das Produkt nicht konvertiert.
3. Infrastruktur und DevOps
Niemand zitiert das richtig. Staging-Umgebungen, CI/CD-Pipelines (wir nutzen inzwischen GitHub Actions für fast alles), Containerisierung mit Docker, Cloud-Hosting auf AWS oder GCP – das sind echte Kosten, die nicht verschwinden, nur weil sie niemand aufgelistet hat. Für eine mittelmäßig komplexe SaaS solltest du mindestens £3.000–£6.000 für das initiale Infrastructure-Setup einkalkulieren, plus laufende monatliche Kosten, die typischerweise £200–£800 betragen, je nach Nutzung.
4. Testing, QA und Launch-Overhead
Automatisierte Test-Suites, manuelle QA-Durchläufe, Performance-Testing, Security-Review für alles, das Zahlungen oder persönliche Daten verarbeitet – das sind typischerweise 20% der gesamten Development-Zeit, wenn es richtig gemacht wird. Die meisten Agency-Angebote führen "Testing" als Posten auf und meinen damit "ein Dev hat sich ein paar Stunden lang rumgeklickt, bevor der Handover-Call war."
---
Ein funktionierendes Schätzverfahren: Die Module-Method
Hier ist das eigentliche Framework. Ich nenne es die Module Method, weil es dich zwingt, ein Projekt in diskrete, unabhängig schätzbare Teile zu zerlegen, anstatt es als Ganzes zu behandeln.
Schritt 1: Jedes Feature als User Story aufzählen. Nicht "User-Management", das ist zu vage. "Ein Nutzer kann sich mit E-Mail und Passwort registrieren, ihre E-Mail verifizieren, das Passwort zurücksetzen und ihr Profilbild aktualisieren." Vier Stories. Jede hat einen Kostenpunkt.
Schritt 2: Ordnen Sie jede Story nach Komplexität ein. Ich verwende drei Stufen:
- Simple (S): Reines CRUD, keine externen Abhängigkeiten, Standard-UI-Muster. Denken Sie an: eine Einstellungsseite, ein Profilaktualisierungsformular, eine Datentabelle mit Sortierung.
- Medium (M): Etwas Geschäftslogik, eine externe Integration oder nicht-standardisierte UI. Denken Sie an: eine gefilterte Suche mit gespeicherten Abfragen, einen Webhook-Handler, einen Stripe-Abonnementfluss.
- Complex (C): Mehrere Integrationen, Echtzeit-Funktionen, algorithmische Logik oder umfangreiche Infrastruktur. Denken Sie an: ein Live-Chat-System, eine Empfehlungsmaschine, ein Multi-Tenant-Berechtigungsmodell.
Schritt 3: Weisen Sie Stundenspannen zu, keine Punkt-Schätzungen.
2026 wird es mit einer mittelständischen UK-Agentur oder einem starken Nearshore-Team so aussehen:
- Einfache Story: 4–8 Stunden
- Mittlere Story: 12–24 Stunden
- Komplexe Story: 30–80 Stunden (ja, das ist eine große Spanne, komplex ist wirklich unvorhersehbar)
Schritt 4: Wende deinen Satz an.
Aktuelle Marktsätze, die du kennen solltest:
- Senior Developer in London (Freelance): £90–£140/Std.
- UK-Agentur (vollständiges Team, Projektmanagement): £80–£120/Std. im Blended Rate
- Starkes Nearshore (Osteuropa, LatAm): £35–£65/Std.
- Offshore (Südasien, Philippinen): £15–£35/Std., und ja, du kannst hier hervorragende Arbeit bekommen, aber der Kommunikations-Overhead ist real und muss eingepreist werden
Schritt 5: Overheads explizit hinzufügen.
Absorbiere diese nicht. Führe sie als einzelne Positionen auf:
- Projektmanagement: 10-15% der Entwicklungsstunden
- Design (falls nicht bereits erfasst): 15-25% der Gesamtsumme
- DevOps/Infrastruktur-Setup: pauschal £3.000-£8.000 je nach Komplexität
- QA: mindestens 20% der Entwicklungsstunden
- Contingency: 20% bei Greenfield-Projekten, 35% bei allem mit erheblicher Integration
---
Ein reales Beispiel: SaaS Dashboard, Preisgestaltung 2026
Lass mich durch etwas Konkretes gehen. Ein Founder kommt zu mir mit dem Wunsch nach einem B2B-Analytics-Dashboard, einem SaaS-Produkt, bei dem seine Kunden sich anmelden, ihre Leistungsdaten sehen, die aus Google Analytics 4 und einer Custom-Event-Datenbank gezogen werden, Reports exportieren können und den Zugang für das eigene Team verwalten können.
So würde ich das aufschlüsseln:
- Auth-System (Email + Google SSO, rollenbasierter Zugriff): 2 Medium Stories = 48 Std.
- GA4-Integration + Datenpipeline: 1 Complex Story = 55 Std.
- Benutzerdefiniertes Event-Datenbankschema + API: 2 Medium Stories = 40 Std.
- Dashboard-UI (Diagramme über Chart.js oder Recharts, responsiv): 3 Medium Stories = 65 Std.
- Report-Export zu PDF/CSV: 1 Medium Story = 18 Std.
- Teamverwaltung (einladen, entfernen, Rollenzuweisung): 2 Simple + 1 Medium Stories = 28 Std.
- Abrechnung über Stripe (Abos, Upgrade/Downgrade): 1 Complex Story = 45 Std.
Rohe Entwicklungszeit insgesamt: ~299 Stunden
Anwendung eines blended UK-Agentursatzes von £95/Std.: £28.405
Hinzufügen:
- Design (20%): £5.681
- DevOps-Setup: £4.500
- QA (20% der Dev-Stunden, gleicher Tarif): £5.681
- PM (12%): £3.409
- Integration-Contingency (30% auf GA4- und Stripe-Arbeit): £3.000
Gesamtschätzung: ~£50.676
Das ist eine echte Zahl für ein echtes Produkt. Nicht schockierend, wenn du weißt, was drin steckt. Absolut schockierend, wenn du mit der Erwartung reingehst, dass es £18.000 kostet, weil dir das letzte Jahr jemand aus deinem Netzwerk für „etwas Ähnliches" erzählt hat.
---
Die versteckten Kosten, die niemand erwähnt
Lizenzen und Drittanbieter-Services
Mapbox für Kartenfunktionen. Twilio für SMS. SendGrid für transaktionale E-Mails. Algolia, wenn du richtige Suche brauchst. Das sind laufende Kosten, die Gründer routinemäßig komplett aus ihrem Software-Budget weglassen, weil sie diese als „nur APIs" betrachten. Ein mittelgroßes SaaS mit 10.000 aktiven Nutzern könnte £800–£2.000/Monat an Drittanbieter-Gebühren zahlen, bevor die erste Serverrechnung kommt.
Sicherheit und Compliance
Wenn du personenbezogene Daten im Vereinigten Königreich verarbeitest, ist GDPR nicht optional. Wenn du Zahlungen verarbeitest, wird PCI DSS Compliance zum Overhead. Wenn du in Gesundheit oder Finanzen tätig bist, kommen zusätzliche Audit-Kosten auf dich zu, die £5.000–£20.000 nur für die anfängliche Zertifizierungsarbeit kosten können. Ich habe schon Gründer erlebt, die davon völlig überrascht wurden. Ein Fintech-Kunde von uns 2023 hatte null Pfund für Compliance-Arbeit budgetiert und brauchte dann £14.000 davon, bevor sie starten konnten.
Übergabe und Dokumentation
Gute Dokumentation, API-Docs, Deployment-Runbooks, Onboarding-Guides für zukünftige Devs – das kostet echte Zeit. Budget 5–8% der gesamten Project-Stunden für Dokumentation ein, wenn du das Ding jemals warten, erweitern oder verkaufen willst.
---
Wie du ein erhaltenes Angebot überprüfst
Du hast einen Vorschlag vor dir. So prüfst du ihn vor der Unterschrift:
- Verlange die Feature-Aufschlüsselung hinter der Zahl. Wenn sie dir keinen Story-Level-Aufschlüsselung geben können, ist das Angebot eine Schätzung.
- Überprüfen Sie, ob DevOps, QA und PM separate Positionen sind oder in einer Pauschalrate versteckt sind. Versteckt bedeutet normalerweise mangelhaft durchdacht.
- Fragen Sie, welche Contingency-Politik sie haben. Deckeln sie Kostenüberschreitungen? Time-and-Materials oder Festpreis? Jeder Ansatz hat echte Auswirkungen.
- Finden Sie heraus, welche Annahmen sie über Third-Party-Integrationen gemacht haben. Fragen Sie sie direkt: „Haben Sie die API-Dokumentation für [spezifischen Service] vor der Angebotsstellung gelesen?"
- Fragen Sie, was passiert, wenn sich Anforderungen nach Sprint 2 ändern. Die Antwort verrät Ihnen fast alles über die Arbeitsweise der Agentur.
Basecamps Shape Up Methodik bietet einen genuinen sinnvollen Rahmen dafür: feste Zeit, variables Scope. Es lohnt sich, das vor jeder Agentur-Verhandlung zu lesen.
---
KI-Tools 2026: Was sie ändern (und was nicht)
Jeder möchte wissen, ob GitHub Copilot, Cursor oder die neue Welle von Agent-basierten Coding-Tools (Devin, Replit Agent) die Softwarekosten wesentlich gesenkt haben. Ehrlich gesagt? Ja, ein bisschen. Aber weniger als der Hype suggeriert.
Aus meiner Erfahrung: Starke KI-gestützte Developer arbeiten bei Greenfield-CRUD-Aufgaben etwa 20–30% schneller. Dieser mittlere Teil standardisierter Features, Formulare, Tabellen, grundlegende Auth-Flows, geht schneller raus. Aber komplexe Integrations-Arbeit, architektonische Entscheidungen, Debugging subtiler Race Conditions und alles, das tiefes Product-Thinking erfordert? Da hilft KI nicht, und in einigen Fällen generiert sie plausibel aussehenden Code, der neue Probleme einführt.
Ich würde 2026 einen Effizienzrabatt von 10-15% auf einfache und mittlere Stories anwenden, wenn das Team bestätigt KI-Tools ernsthaft nutzt. Nicht mehr als das. Wer Ihnen 50% Rabatt anbietet „weil wir KI nutzen", führt entweder ein sehr anderes Projekt durch als Sie denken, oder erzählt Ihnen etwas, das zu schön ist, um wahr zu sein.
---
FAQ
Wie genau kann eine Softwareschätzung wirklich sein, bevor die Anforderungen festgelegt sind?
Nein, so funktioniert das nicht. In der Idea-Phase musst du mit Abweichungen von ±40–60% rechnen. Hast du dann User Flows, ein Datenmodell und eine Liste aller Third-Party-Dependencies, liegt die Abweichung bei ±20%. Nach einem Discovery Sprint mit Wireframes und technischer Architektur kommst du auf ±10–15%. Investier in ein solides Discovery-Engagement, bevor du dich auf ein Build-Budget festlegst. Das kostet typischerweise £2.000–£6.000 und ist das beste Geld, das du ins Projekt steckst.
Sollte ich mich für einen Festpreis oder Time-and-Materials entscheiden?
Festpreis gibt dir Budget-Sicherheit, verlagert aber das Risiko auf die Agency, was bedeutet, dass sie den Kostenvoranschlag auffüllen und sich mit Change-Order-Klauseln schützen werden. Time-and-Materials ist ehrlich, erfordert aber von dir aktives Scope-Management. Meine Vorliebe für die meisten Founder: Festpreis pro Sprint (typischerweise 2 Wochen), mit Scope klar definiert am Anfang jedes Sprints. Du bekommst Planungssicherheit ohne das Auffüll-Spiel.
Ist Nearshore- oder Offshore-Entwicklung wirklich billiger, wenn man den Management-Overhead einrechnet?
Oft, aber nicht immer. Der Overhead ist real – mehr PM-Zeit, mehr asynchrone Kommunikation, gelegentliche Nacharbeiten durch nicht abgestimmte Erwartungen. Bei einem gut definierten Projekt mit aussagekräftigen Spezifikationen bietet Nearshoring (besonders Osteuropa) echten Mehrwert. Ich habe erfolgreiche Projekte mit £40/Std. durchschnittlich mit polnischen und ukrainischen Teams durchgeführt. Bei etwas Mehrdeutigem und schnell Beweglichem würde ich es näher an die Heimat halten.
Was ist ein Warnsignal in einem Softwareangebot?
Ein einzeiliges Angebot ohne Aufschlüsselung. Ein Zeitplan, der QA oder Deployment nicht berücksichtigt. Keine Erwähnung, wie Change Requests gehandhabt werden. Und ehrlich gesagt, jede Agentur, die dir vor dem Angebot keine schwierigen Fragen zu deiner bestehenden Infrastruktur stellt. Wenn sie nicht neugierig auf deine Constraints sind, haben sie sich mit deinem Projekt nicht ernsthaft auseinandergesetzt.
Wie kalkuliere ich Budget für die Wartung nach dem Launch?
Faustregel: 15–20 % der initialen Entwicklungskosten pro Jahr für laufende Wartung, Bugfixes und kleinere Feature-Arbeiten. Ein Build zu £50.000 benötigt ein jährliches Wartungsbudget von £7.500–£10.000. Falls dir jemand sagt, dass Software beim Launch „fertig" ist, such dir andere Software-Leute.
---
Der Logistik-Gründer von November? Der ist zurück zu seiner Agentur gegangen, sie haben ihren Arbeitsprozess refaktoriert, und das Produkt ist im März live gegangen. Es läuft gut. Aber er hat mir gesagt, er hätte sich gewünscht, dass ihm jemand einen Framework wie diesen gegeben hätte, bevor er etwas unterschrieben hat. Also. Hier ist er.
Weiterführende Lektüre: Building a Real-Time Auction Site with Next.js & Supabase, maßgeschneiderte Webentwicklung und benutzerdefinierte Software.