Im November 2024, zwei Wochen vor Weihnachten, rief mich ein Gründer an – außer sich vor Wut. Eine Web-Agentur hatte ihm £14.000 für ein maßgeschneidertes Logistik-Dashboard angeboten. Er hatte unterschrieben. Sechs Monate später kam die Schlussrechnung über £61.000. Niemand hatte ihn belogen, technisch gesehen. Aber niemand hatte ihm die Wahrheit gesagt – weil niemand die Arbeit getan hatte, vorher ordentlich zu schätzen, bevor man sein Geld nahm.
Wichtigste Erkenntnis: Bei individueller Software scheitern Angebote in der Scope-Definition, nicht in der Entwicklung; kalkulieren Sie anhand der Komplexität des Datenmodells, Integrationen und Review-Zyklen, und bewerten Sie die Discovery-Phase separat.Custom software quotes go wrong at scoping, not building; estimate from data model complexity, integrations, and review cycles, and price the discovery phase separately.
Ich baue seit über zwölf Jahren Software. Seahawk allein hat mehr als 12.000 Websites und Anwendungen ausgeliefert. Und der einzige konsistente Fehler, den ich sehe – bei Gründern, bei Freelancern, bei Agenturen, die Projekte kalkulieren – ist, dass niemand eine rigorose Methode hat, um die Kosten zu schätzen, bevor eine einzige Codezeile geschrieben wird. Die Leute raten. Sie orientieren sich an Gefühlen. Sie nehmen das letzte Projekt als Referenzpunkt, ohne zu überprüfen, 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 (meist). Es ist, dass Software-Schätzung wirklich schwer ist, und die meisten Menschen unterschätzen, wie schwer – deshalb greifen sie zu Abkürzungen, die sich rigoros anfühlen, es aber nicht sind.how hard -- so they reach for shortcuts that feel like rigour but aren't.
Ein Entwickler gibt dir eine Bauchzahl. Eine Agentur multipliziert ihren Tagessatz mit einer geschätzten Sprint-Anzahl. Ein Freelancer schaut sich einen ähnlichen Auftrag auf Upwork an und rechnet rückwärts. Keine dieser Methoden ist genau falsch, aber keine berücksichtigt die echten Kostentreiber: Integrationskomplexität, Entscheidungsverzögerungen auf Kundenseite, Scope Creep bei Features, die nebensächlich wirkten, Test-Overhead und der stille Killer – Environment-Setup und DevOps, die niemand einkalkuliert.
2021 leitete ich ein Projekt für einen Property-Tech-Kunden in Manchester. Auf dem Papier einfach genug: ein Tenant-Portal mit Dokument-Uploads, Mietzahlungs-Tracking und einen Maintenance-Request-Workflow. Die ursprüngliche Schätzung war £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. Die Integration allein zog sich um drei Wochen hin. Endkosten: £47.500. Der Kunde war damit einverstanden, weil wir es sofort flaggt hatten, als wir die API-Docs fanden – aber die ursprüngliche Schätzung war immer noch Fiktion, und dafür trage ich die Verantwortung.
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., popularised by Steve McConnell, describes how project estimates get more accurate as you get closer to delivery. At ideation, you might be off by 4x in either direction. After detailed design, maybe 1.25x. Most founders are getting quotes at the ideation stage and treating them like signed contracts.
Die praktische Konsequenz: Jedes Angebot, das du erhältst, bevor detaillierte Specs geschrieben sind, sollte als Spanne behandelt werden, nicht als Zahl. Wenn eine Agentur dir eine einzelne Ziffer gibt, bevor sie dein Datenmodell, User Flows und Third-Party-Dependencies gesehen hat – diese Zahl ist rein kosmetisch.range, not a number. If an agency gives you a single figure before they've seen your data model, user flows, and third-party dependencies -- that number is decorative.
---
Die vier echten Kostenkategorien
Bevor ein Schätzer arbeiten kann, musst du das Projekt in die richtigen Kategorien aufteilen. Nicht „Frontend, Backend, QA" -- das sind Rollen, keine Kostentreiber. Die echten Kategorien:
1. Greenfield vs. Integrations-Arbeit
Greenfield -- etwas von Grund auf gegen deine eigene Datenbank und Geschäftslogik aufzubauen -- ist die billigere, vorhersagbarere Hälfte fast jedes Projekts. Die Integrations-Arbeit ist das Problem. Jede externe API, jedes Legacy-System, jeder Payment-Prozessor oder Third-Party-Auth-Provider fügt nicht-lineare Komplexität hinzu. Ich addiere typischerweise eine 30-40%-Rückstellung auf jede Umfangsposition, 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 Entwicklungsschätzung einzurechnen. Fehler. Design, das richtig gemacht ist -- Wireframes, interaktive Prototypen in Figma, eine getestete Component Library -- läuft typischerweise auf 15-25% der Gesamtprojektkosten. Skippt man es, zahlt man doppelt: einmal in Developer-Überarbeit, wenn sich die Anforderungen als mehrdeutig herausstellen, und nochmal in User Research später, wenn das Produkt nicht konvertiert.Figma, a tested component library -- typically runs 15-25% of total project cost. Skip it and you'll pay twice: once in developer rework when requirements turn out to be ambiguous, and again in user research later when the product doesn't convert.
3. Infrastruktur und DevOps
Niemand kalkuliert das richtig. Staging-Umgebungen, CI/CD-Pipelines (wir nutzen GitHub Actions für fast alles inzwischen), Containerisierung mit Docker, Cloud-Hosting auf AWS oder GCP -- das sind echte Kosten, die nicht verschwinden, weil sie niemand kalkuliert hat. Für ein mittelmäßig komplexes SaaS solltest du ein Minimum von £3.000-£6.000 für das initiale Infrastruktur-Setup einplanen, plus laufende monatliche Kosten, die typischerweise £200-£800 je nach Nutzung betragen.
4. Testing, QA und Launch-Overhead
Automatisierte Test-Suites, manuelle QA-Durchläufe, Performance-Tests, Sicherheitsprüfungen für alles, das Zahlungen oder persönliche Daten verarbeitet – das sind normalerweise 20% der gesamten Entwicklungszeit, wenn es richtig gemacht wird. Die meisten Agentur-Angebote enthalten "Testing" als Posten und meinen damit "ein Entwickler hat sich am Nachmittag vor dem Handover-Call ein bisschen umgesehen."
---
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: Listet jede Funktion als User Story auf. Nicht "User-Verwaltung" – das ist zu vage. "Ein Benutzer kann sich mit E-Mail und Passwort registrieren, seine E-Mail verifizieren, sein Passwort zurücksetzen und sein Profilbild aktualisieren." Vier Stories. Jede hat einen Kostenaufwand.Not "user management" -- that's too vague. "A user can register with email and password, verify their email, reset their password, and update their profile photo." Four stories. Each one has a cost.
Schritt 2: Ordnen Sie jede Story nach Komplexität ein. Ich verwende drei Stufen:I use three tiers:
- Simple (S): Reines CRUD, keine externen Abhängigkeiten, Standard-UI-Muster. Denken Sie an: eine Einstellungsseite, ein Profilaktualisierungsformular, eine Datentabelle mit Sortierung.(S): Pure CRUD, no external dependencies, standard UI patterns. Think: a settings page, a profile update form, a data table with sorting.
- 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.(M): Some business logic, one external integration, or non-standard UI. Think: a filtered search with saved queries, a webhook handler, a Stripe subscription flow.
- Complex (C): Mehrere Integrationen, Echtzeit-Funktionen, algorithmische Logik oder umfangreiche Infrastruktur. Denken Sie an: ein Live-Chat-System, eine Empfehlungsmaschine, ein Multi-Tenant-Berechtigungsmodell.(C): Multiple integrations, real-time features, algorithmic logic, or heavy infrastructure. Think: a live chat system, a recommendation engine, a multi-tenant permission model.
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, so 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 exzellente Arbeit bekommen, aber der Kommunikationsaufwand ist real und muss eingerechnet 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 ein konkretes Beispiel durchgehen. Ein Gründer kommt zu mir und möchte ein B2B-Analytics-Dashboard -- ein SaaS-Produkt, bei dem sich ihre Kunden anmelden, ihre Leistungsdaten sehen, die von Google Analytics 4 und einer benutzerdefinierten Event-Datenbank stammen, Berichte exportieren können und den Zugriff ihres eigenen Teams verwalten können.
So würde ich das aufschlüsseln:
- Auth-System (Email + Google SSO, rollenbasierter Zugriff): 2 Medium Stories = 48 Std.2 Medium stories = 48 hrs
- GA4-Integration + Datenpipeline: 1 Complex Story = 55 Std.1 Complex story = 55 hrs
- Benutzerdefiniertes Event-Datenbankschema + API: 2 Medium Stories = 40 Std.2 Medium stories = 40 hrs
- Dashboard-UI (Diagramme über Chart.js oder Recharts, responsiv): 3 Medium Stories = 65 Std.3 Medium stories = 65 hrs
- Report-Export zu PDF/CSV: 1 Medium Story = 18 Std.1 Medium story = 18 hrs
- Teamverwaltung (einladen, entfernen, Rollenzuweisung): 2 Simple + 1 Medium Stories = 28 Std.2 Simple + 1 Medium stories = 28 hrs
- Abrechnung über Stripe (Abos, Upgrade/Downgrade): 1 Complex Story = 45 Std.1 Complex story = 45 hrs
Rohe Entwicklungszeit insgesamt: ~299 Stunden
Anwendung eines blended UK-Agentursatzes von £95/Std.: £28.405£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.PCI DSS compliance adds overhead. If you're in health or finance, you're looking at additional audit costs that can run £5,000-£20,000 just for initial certification work. I've seen founders get genuinely blindsided by this. One fintech client of ours in 2023 had budgeted zero pounds for compliance work and then needed £14,000 of it before they could launch.
Übergabe und Dokumentation
Gute Dokumentation – API-Docs, Deployment Runbooks, Onboarding-Guides für zukünftige Entwickler – kostet echte Zeit. Budget 5–8 % der gesamten Projektstunden für Dokumentation ein, wenn du die Sache 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. has a genuinely useful framing for this: fixed time, variable scope. It's worth reading before you enter any agency negotiation.
---
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.
Meine grobe Erfahrung: Starke KI-unterstützte Entwickler arbeiten bei Greenfield-CRUD-Arbeiten etwa 20-30% schneller. Dieser mittlere Bereich von Standardfunktionen – Formulare, Tabellen, einfache Auth-Flows – wird schneller umgesetzt. Aber komplexe Integrationsarbeit, architektonische Entscheidungen, das Debuggen subtiler Race Conditions und alles, das tiefes Produktdenken erfordert? Dabei hilft KI nicht, und in manchen Fällen generiert sie plausibel aussehender 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?
Nicht sehr genau. Rechnen Sie in der Ideenphase mit einer Abweichung von ±40–60 %. Sobald Sie detaillierte User Flows, ein Datenmodell und eine Liste aller Third-Party-Abhängigkeiten haben, können Sie auf ±20 % kommen. Nach einem Discovery Sprint mit Wireframes und technischer Architektur: ±10–15 %. Investieren Sie in ein ordentliches Discovery Engagement, bevor Sie sich auf ein volles Build-Budget festlegen – das kostet typischerweise £2.000–£6.000 und ist das beste Geld, das Sie für das Projekt ausgeben werden.
Sollte ich mich für einen Festpreis oder Time-and-Materials entscheiden?
Festpreis gibt dir Budgetsicherheit, verlagert das Risiko aber auf die Agentur – was bedeutet, dass sie die Schätzung aufpolstern und sich mit Change-Order-Klauseln absichern werden. Time-and-Materials ist ehrlich, erfordert aber von dir aktives Scope-Management. Meine Präferenz für die meisten Gründer: Festpreis pro Sprint (typischerweise 2 Wochen), mit Scope, der zu Beginn jedes Sprints definiert ist. Du bekommst Planbarkeit ohne das Polster-Spiel.
Ist Nearshore- oder Offshore-Entwicklung wirklich billiger, wenn man den Management-Overhead einrechnet?
Oft ja, aber nicht immer. Der Overhead ist real – mehr PM-Zeit, mehr asynchrone Kommunikation, gelegentliche Nacharbeiten durch unterschiedliche Erwartungshaltungen. Bei einem gut definierten Projekt mit starken Specs bietet Nearshore (besonders Osteuropa) echten Mehrwert. Ich habe erfolgreiche Projekte mit polnischen und ukrainischen Teams bei £40/Std. durchgeführt. Für etwas Mehrdeutiges und schnelllebiges würde ich es näher zur Heimat halten.
Was ist ein Warnsignal in einem Softwareangebot?
Ein einfaches Angebot in einer Zeile ohne Aufschlüsselung. Ein Zeitplan, der QA oder Deployment nicht beinhaltet. Keine Erwähnung, wie Change Requests behandelt werden. Und ehrlich gesagt – jede Agentur, die dich nicht hart nach deiner bestehenden Infrastruktur befragt, bevor sie ein Angebot macht. 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.