Ein Gründer rief mich im November 2024 an, zwei Wochen vor Weihnachten, absolut wütend. Eine Webagentur hatte ihm ein Angebot für ein maßgeschneidertes Logistik-Dashboard über £14.000 gemacht. Er hatte unterzeichnet. Sechs Monate später kam die Schlussrechnung über £61.000. Niemand hatte ihm technisch gesehen gelogen. Aber niemand hatte ihm die Wahrheit gesagt — weil niemand die Arbeit gemacht hatte, vorher richtig zu kalkulieren, bevor er sein Geld zahlte.
Ich baue Software seit über zwölf Jahren. Seahawk allein hat mehr als 5.000 Websites und Anwendungen ausgeliefert. Und der konsistenteste Fehlerpunkt, den ich sehe — bei Gründern, bei Freelancern, bei Agenturen, die Projekte anbieten — ist, dass niemand eine strenge Methode hat, um Kosten zu schätzen, bevor eine Zeile Code geschrieben wird. Menschen raten. Sie verankern sich an Gefühlen. Sie nutzen das letzte Projekt als Referenzpunkt, ohne zu prüfen, ob es auch nur annähernd vergleichbar war.
Also. Hier ist der Rahmen, den ich tatsächlich nutze. Nicht eine Spreadsheet-Vorlage mit Platzhalter-Zellen. Ein echtes mentales Modell, mit aktuellen 2026-Zahlen, spezifischen Tools und den Vorbehalten, die zählen.
---
Warum die meisten Software-Angebote Fiktion sind
Das Problem ist nicht Unehrlichkeit (normalerweise). Es ist, dass Softwareschätzungen genuinely schwer sind, und die meisten Menschen unterschätzen, wie schwer — also greifen sie zu Abkürzungen, die sich nach Genauigkeit anfühlen, es aber nicht sind.howhard — so they reach for shortcuts that feel like rigour but aren't.
Ein Entwickler gibt dir eine Bauchgefühl-Zahl. Eine Agentur multipliziert ihren Tagessatz mit einer geschätzten Sprint-Anzahl. Ein Freiberufler schaut sich einen ähnlichen Job auf Upwork an und rechnet rückwärts. Keine davon ist genau falsch, aber keine berücksichtigt die eigentlichen Kostentreiber: Integrationskomplexität, Entscheidungsverzögerungen auf Kundenseite, Scope Creep bei Features, die banal wirkten, Test-Overhead und der stille Killer — Environment-Setup und DevOps, das niemand kalkuliert.
2021 leitete ich ein Projekt für einen Property-Tech-Client in Manchester. Auf dem Papier einfach genug: ein Tenant Portal mit Document-Uploads, Rent Tracking und einen Maintenance-Request-Workflow. Erste Schätzung: £28.000. Wir hatten ähnliche Builds gemacht. Aber dieser Client nutzte ein Legacy Property Management System mit einer proprietären API, die vier Jahre lang niemand angefasst hatte. Die Integration allein hat drei Wochen überschritten. Endkosten: £47.500. Der Client war damit einverstanden, weil wir es gemeldet hatten, sobald wir die API-Docs gefunden haben — aber die erste Schätzung war trotzdem Fiktion, und ich trage dafür Verantwortung.
Der Cone of Uncertainty ist real
Der Cone of Uncertainty, popularisiert von Steve McConnell, beschreibt, wie Projektschätzungen genauer werden, je näher du der Lieferung kommst. In der Ideationsphase kannst du um den Faktor 4 daneben liegen — in beide Richtungen. Nach detailliertem Design vielleicht 1,25x. Die meisten Founder holen sich Angebote in der Ideationsphase 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 Folge: Jedes Angebot, das du erhältst, bevor detaillierte Specs geschrieben sind, sollte als Range 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 dekorativ.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 Kostengruppen
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 eigentlichen Gruppen:
1. Greenfield vs. Integration Work
Greenfield — etwas von Grund auf gegen die eigene Datenbank und Business-Logik aufbauen — ist der günstigere, vorhersehbarere Teil fast jedes Projekts. Die Integrationsarbeit ist das Problem. Jede externe API, jedes Legacy-System, jeder Payment-Processor oder Third-Party-Auth-Provider fügt nicht-lineare Komplexität hinzu. Ich rechne normalerweise 30–40 % Contingency auf jede Scope-Zeile, die externe Systeme betrifft.
2. UI/UX Design (überspringe diese Zeile nicht)
Viele Gründer behandeln Design als optional oder versuchen, es in die Development-Schätzung einzurechnen. Fehler. Design, das richtig gemacht wird — Wireframes, interaktive Prototypen in Figma, eine getestete Component Library — kostet typischerweise 15–25 % der Gesamtprojektkosten. Wenn du es überspringst, zahlst du doppelt: einmal in Developer-Rework, 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. Infrastructure und DevOps
Niemand kalkuliert das richtig. Staging-Umgebungen, CI/CD-Pipelines (wir nutzen GitHub Actions bei fast allem), Containerisierung mit Docker, Cloud-Hosting auf AWS oder GCP — das sind echte Kosten, die nicht verschwinden, weil sie niemand aufgelistet hat. Für ein SaaS mit mittlerer Komplexität mindestens £3.000–£6.000 für das initiale Infrastructure-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-Testing, Security-Review für alles, das mit Zahlungen oder persönlichen Daten umgeht — das sind typischerweise 20 % der gesamten Development-Zeit, wenn es richtig gemacht wird. Die meisten Agency-Angebote listet „Testing" als Zeile auf und meint damit „ein Dev hat vor dem Handover-Call einen Nachmittag rumgeklickt".
---
Ein funktionierender Estimator: Die Module-Methode
Hier ist das eigentliche Framework. Ich nenne es die Module-Methode, weil es dich zwingt, ein Projekt in diskrete, unabhängig schätzbare Chunks aufzubrechen, statt es als Monolith zu behandeln.
Schritt 1: Listen Sie jede Funktion als User Story auf. Nicht „Benutzerverwaltung" – das ist zu vage. „Ein Benutzer kann sich mit E-Mail und Passwort registrieren, seine E-Mail verifizieren, sein Passwort zurücksetzen und sein Profilfoto aktualisieren." Vier Stories. Jede hat einen Kostenpunkt.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: Bewerten Sie jede Story nach Komplexität. Ich nutze drei Stufen:I use three tiers:
- Simple (S): Reines CRUD, keine externen Abhängigkeiten, Standard-UI-Muster. Beispiele: 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. Beispiele: eine gefilterte Suche mit gespeicherten Abfragen, ein Webhook-Handler, ein Stripe-Abonnement-Flow.(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-Features, algorithmische Logik oder umfangreiche Infrastruktur. Beispiele: ein Live-Chat-System, eine Empfehlungs-Engine, 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, nicht Punkt-Schätzungen.
2026 würde ich mit einer Mid-Tier-Agentur aus dem UK oder einem starken Nearshore-Team so kalkulieren:
- Simple Story: 4–8 Stunden
- Medium Story: 12–24 Stunden
- Complex Story: 30–80 Stunden (ja, diese Bandbreite – Complex ist wirklich unvorhersehbar)
Schritt 4: Wenden Sie Ihren Satz an.
Aktuelle Marktpreise, die es zu kennen gilt:
- Londoner Senior-Developer (freiberuflich): £90–£140/Std.
- UK-Agentur (vollständiges Team, projektmanagiert): £80–£120/Std. gemischt
- Starker Nearshore (Osteuropa, LatAm): £35–£65/Std.
- Offshore (Südasien, Philippinen): £15–£35/Std. — und ja, Sie können hier hervorragende Arbeit bekommen, aber der Kommunikationsaufwand ist real und muss eingepreist werden
Schritt 5: Addieren Sie Gemeinkosten explizit.
Absorbieren Sie diese nicht. Rechnen Sie sie einzeln ab:
- Projektmanagement: 10–15% der Entwicklerstunden
- Design (falls nicht bereits berücksichtigt): 15–25% der Gesamtsumme
- DevOps/Infrastructure-Setup: 3.000–8.000 £ Pauschalgebühr je nach Komplexität
- QA: mindestens 20% der Entwicklungsstunden
- Puffer: 20% bei Greenfield-Projekten, 35% bei Arbeiten mit erheblicher Integration
---
Ein reales Beispiel: SaaS-Dashboard, Preisgestaltung 2026
Lass mich etwas Konkretes durchgehen. Ein Gründer kommt zu mir und möchte ein B2B-Analytics-Dashboard — ein SaaS-Produkt, bei dem sich seine Kunden anmelden, ihre Leistungsdaten sehen, die aus Google Analytics 4 und einer benutzerdefinierten Ereignisdatenbank abgerufen werden, Berichte exportieren können und den Zugriff ihres eigenen Teams verwalten können.
So würde ich es aufschlüsseln:
- Authentifizierungssystem (E-Mail + Google SSO, rollenbasierter Zugriff): 2 mittlere Stories = 48 Stunden2 Medium stories = 48 hrs
- GA4-Integration + Datenpipeline: 1 komplexe Story = 55 Stunden1 Complex story = 55 hrs
- Benutzerdefiniertes Ereignisdatenbankschema + API: 2 mittlere Stories = 40 Stunden2 Medium stories = 40 hrs
- Dashboard UI (Charts via Chart.js oder Recharts, responsive): 3 Medium Stories = 65 Std.3 Medium stories = 65 hrs
- Berichtexport 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 via Stripe (Abos, Upgrade/Downgrade): 1 Complex Story = 45 Std.1 Complex story = 45 hrs
Reine Entwicklung insgesamt: ~299 Stunden
Anwendung eines gemischten UK-Agentursatzes von £95/Std.: £28.405£28,405
Zuzüglich:
- Design (20%): £5.681
- DevOps-Setup: £4.500
- QA (20% der Entwicklungsstunden, gleicher Satz): £5.681
- PM (12%): £3.409
- Integrationspuffer (30% für GA4- und Stripe-Arbeiten): £3.000
Gesamtschätzung: ~£50.676
Das ist eine echte Zahl für ein echtes Produkt. Nicht schockierend, wenn du weißt, was darin steckt. Absolut schockierend, wenn du mit der Erwartung reingegangen bist, dass es £18.000 kostet, weil das jemand einem Gründer in deinem Netzwerk letztes Jahr für „etwas Ähnliches" erzählt hat.
---
Die versteckten Kosten, die niemand erwähnt
Lizenzen und Third-Party-Services
Mapbox für Kartenfunktionen. Twilio für SMS. SendGrid für transaktionale E-Mails. Algolia, wenn du eine richtige Suchfunktion brauchst. Das sind laufende Kosten, die Gründer routinemäßig komplett aus ihrem Software-Budget weglassen, weil sie diese als „einfach nur APIs" betrachten. Ein mittelgroßes SaaS mit 10.000 aktiven Nutzern könnte £800–£2.000/Monat an Gebühren für Third-Party-Services zahlen, bevor die erste Serverrechnung kommt.
Sicherheit und Compliance
Wenn du mit personenbezogenen Daten im Vereinigten Königreich umgehst, ist GDPR nicht optional. Wenn du Zahlungen verarbeitest, bringt PCI-DSS-Compliance zusätzliche Aufwände mit sich. Wenn du im Gesundheits- oder Finanzsektor tätig bist, zahlst du zusätzliche Audit-Kosten, die allein für die initiale Zertifizierungsarbeit £5.000–£20.000 betragen können. Ich habe schon Gründer sehen, die davon völlig überrascht wurden. Ein Fintech-Klient von uns 2023 hatte null Pfund für Compliance-Arbeiten eingeplant und brauchte dann £14.000 dafür, bevor sie starten konnten.PCI DSS complianceadds 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, wenn du das Ding jemals warten, erweitern oder verkaufen möchtest.
---
So überprüfst du ein erhaltenes Angebot unter Druck
Du hast einen Vorschlag vor dir. So prüfst du ihn vor der Unterzeichnung:
- Verlange eine Feature-Aufschlüsselung hinter der Zahl. Wenn sie dir keine Story-Level-Aufschlüsselung geben können, ist das Angebot eine Vermutung.
- Überprüfe, ob DevOps, QA und PM separate Positionen sind oder in einem Blended Rate versteckt. Versteckt bedeutet üblicherweise unterentwickelt.
- Frage, welche Contingency-Policy sie haben. Decken sie Überläufe ab? Time-and-Materials oder Festpreis? Jedes hat echte Auswirkungen.
- Finde heraus, welche Annahmen sie über Third-Party-Integrationen getroffen haben. Frage sie direkt: „Haben Sie die API-Dokumentation von [spezifischer Service] vor dem Angebot gelesen?"
- Frage, was passiert, wenn sich Anforderungen nach Sprint 2 ändern. Die Antwort sagt dir fast alles über die Arbeitsweise der Agentur.
Basecamps Shape Up Methodik hat einen wirklich nützlichen Rahmen dafür: feste Zeit, variables Scope. Es lohnt sich, das zu lesen, bevor du in Agentur-Verhandlungen gehst.has a genuinely useful framing for this: fixed time, variable scope. It's worth reading before you enter any agency negotiation.
---
AI-Tools 2026: Was sie verändern (und was nicht)
Alle wollen wissen, ob GitHub Copilot, Cursor oder die neue Welle von Agent-basierten Coding-Tools (Devin, Replit Agent) die Softwarekosten erheblich gesenkt haben. Ehrlich gesagt? Ja, ein bisschen. Aber weniger, als der Hype vermuten lässt.
Meine grobe Erfahrung: Starke KI-unterstützte Entwickler arbeiten bei Greenfield-CRUD-Arbeiten etwa 20–30% schneller. Das mittlere Segment Standard-Features — Formulare, Tabellen, einfache Auth-Flows — entsteht tatsächlich schneller. Aber komplexe Integrationsarbeiten, Architektur-Entscheidungen, Debugging subtiler Race Conditions und alles, das tiefes Produktdenken erfordert? Da hilft KI nicht, und in manchen Fällen erzeugt sie plausibel aussehenden Code, der neue Probleme mit sich bringt.
Ich würde für 2026 einen Effizienz-Rabatt von 10–15% auf einfache und mittlere Stories anwenden, wenn das Team nachweislich AI-Tools ernsthaft nutzt. Nicht mehr als das. Wer dir 50% Rabatt verspricht, „weil wir AI nutzen", führt entweder ein ganz anderes Projekt durch als du denkst, oder erzählt dir etwas, das zu schön ist, um wahr zu sein.
---
FAQ
Wie genau kann eine Software-Schätzung wirklich sein, bevor Specs geschrieben sind?
Nicht sehr. Rechne in der Idea-Phase mit einer Abweichung von ±40–60%. Sobald du detaillierte User Flows, ein Datenmodell und eine Liste aller Third-Party-Dependencies hast, kommst du zu ±20%. Nach einem Discovery Sprint mit Wireframes und technischer Architektur: ±10–15%. Zahle für ein ordentliches Discovery Engagement, bevor du dich auf ein volles Build-Budget festlegst — das kostet typischerweise £2.000–£6.000 und ist das beste Geld, das du ins Projekt investierst.
Sollte ich mich für Festpreis oder Time-and-Materials entscheiden?
Festpreis gibt dir Budgetsicherheit, verlagert das Risiko aber auf die Agentur — das bedeutet, sie werden die Schätzung aufpolstern und sich mit Change-Order-Klauseln absichern. Time-and-Materials ist ehrlich, erfordert von dir aber aktives Scope-Management. Meine Vorliebe für die meisten Gründer: Festpreis pro Sprint (typischerweise 2 Wochen), mit klar definiertem Scope zu Beginn jedes Sprints. Du bekommst Planungssicherheit ohne das Aufpolster-Spiel.
Ist Nearshore- oder Offshore-Entwicklung wirklich billiger, wenn man den Management-Overhead berücksichtigt?
Oft ja, aber nicht immer. Der Overhead ist real — mehr PM-Zeit, mehr asynchrone Kommunikation, gelegentliche Überarbeitungen wegen nicht übereinstimmender Erwartungen. Bei einem gut definierten Projekt mit starken Spezifikationen bietet Nearshore (besonders Osteuropa) echten Mehrwert. Ich habe erfolgreiche Projekte mit polnischen und ukrainischen Teams zu £40/Stunde gemischt abgerechnet. Bei etwas Mehrdeutigem und schnell Beweglichem würde ich es näher nach Hause holen.
Was ist ein Warnsignal in einem Software-Angebot?
Ein einzeiliges Angebot ohne Aufschlüsselung. Ein Zeitplan, der QA oder Deployment nicht einschließt. Keine Erwähnung, wie Change Requests behandelt werden. Und ehrlich gesagt — jede Agentur, die dich nicht mit schwierigen Fragen zu deiner bestehenden Infrastruktur löchert, bevor sie ein Angebot macht. Wenn sie sich nicht für deine Constraints interessieren, haben sie sich nicht ernsthaft mit deinem Projekt auseinandergesetzt.
Wie budgetiere ich Wartung nach dem Launch?
Faustregel: 15–20% der anfänglichen Build-Kosten pro Jahr für laufende Wartung, Bugfixes und kleinere Feature-Arbeiten. Ein £50.000-Build braucht ein £7.500–£10.000 jährliches Wartungsbudget. Wenn dir jemand sagt, Software sei beim Launch "fertig", suche 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.