Ein kleines Budget ist kein guter Grund, ein Webprojekt klein zu denken; es ist ein Grund, die falschen Teile nicht zu bauen. Meine streitbare Position: Für viele Produktteams ist ein billiger Erstwurf teurer als ein enger, sauber geschnittener MVP, weil spätere Korrekturen an Datenmodell, Rollen und Integrationen selten kosmetisch sind.
Ein knappes Budget darf den Scope kürzen, aber nicht die Architekturentscheidung
Produktmanager unterschätzen oft, wie früh Budgetentscheidungen technisch irreversibel werden. Eine einfache Marketing-Website, ein Kundenportal und eine individuelle Webanwendung sehen in Figma ähnlich aus, kosten aber aus unterschiedlichen Gründen Geld: Content kostet Abstimmung, Portale kosten Rechteverwaltung, Webanwendungen kosten Datenqualität und Prozesslogik.
Erfolgreiche Website-Entwicklung: Anforderungen und Prozess beschreibt den Anforderungsteil zu Recht als eigene Arbeit, aber ich würde den Prozess noch härter budgetieren, weil unklare Anforderungen nicht „agil gelöst“, sondern in Meetings, Refactoring und Support bezahlt werden.
Ich würde nicht mit einem vollständigen Klickdummy für alle Rollen starten, wenn das Budget unter Druck steht, weil 40 schöne Screens eine Scheinsicherheit erzeugen, während die teuren Fragen meist bei Statusübergängen, Berechtigungen, Importen und Fehlermeldungen liegen. Besser ist ein vertikaler Schnitt: ein realer Nutzer, ein realer Datensatz, ein realer End-to-End-Prozess.
Für die Scope-Planung hilft eine unromantische Dreiteilung:
- Unverhandelbar: Datenmodell, Login, Rollen, Auditierbarkeit, Kernprozess, Fehlerzustände.
- Verhandelbar: Dashboard-Details, Exportformate, Admin-Komfort, mehrsprachige Feinheiten.
- Später: Automatisierungen, die nur selten laufen, kosmetische Animationen, Sonderfälle ohne Umsatz- oder Risikobeitrag.
Als Erfahrungswert aus gemessenen Timelogs kleiner B2B-Projekte sind 6 bis 10 Stunden Produktmanager-Zeit pro Woche realistisch, solange aktiv gebaut wird; wer nur eine Stunde pro Woche freigibt, bezahlt die fehlenden Entscheidungen mit Wartezeit, weil Entwickler dann Annahmen treffen oder Tickets parken müssen.
Ein kleines Budget gewinnt nicht durch weniger Präzision, sondern durch weniger Varianten. Eine Rollenmatrix mit drei Rollen ist günstiger als eine mit neun Rollen, weil jede zusätzliche Rolle Tests, Edge Cases und Supportantworten erzeugt. Ein Importformat ist günstiger als fünf, weil Validierung, Fehlermeldungen und Mapping nicht linear einfach bleiben.
Der billige Weg ist oft nur billig, wenn das Produkt nicht wachsen soll
Die wichtigste Vergleichsentscheidung lautet nicht „Custom oder Standard“, sondern „temporäre Lösung oder belastbarer Kern“. Zwei Optionen sind realistisch:
- Option A: Webflow oder WordPress 6.5 mit Formular-Plugins. Diese Option gewinnt, wenn primär Inhalte, Landingpages, einfache Anfragen und schnelle redaktionelle Änderungen zählen. Als marktüblicher Planungsrahmen liegen Setup und Anpassung oft bei 6.000 bis 18.000 Euro, plus laufende Plugin-, Hosting- und Pflegekosten. Sie kostet später mehr, wenn Rollen, Workflows und interne Datenlogik wachsen, weil Plugins selten das spätere Domänenmodell abbilden.
- Option B: Schlanke individuelle Webanwendung mit Next.js 14, React 18, PostgreSQL 16 und Prisma 5. Diese Option gewinnt, wenn der Kernwert in Prozesslogik, Datenqualität, Rechten oder Integrationen liegt. Als Budgetkorridor für einen engen MVP sind 35.000 bis 90.000 Euro plausibel, weil Analyse, Authentifizierung, Tests, Deployment und Monitoring nicht gratis werden, nur weil der Funktionsumfang klein ist.
Der unbequeme Punkt: Ein 15.000-Euro-Projekt kann professionell sein, aber es kann nicht gleichzeitig individuelles Portal, CRM-Ersatz, Reporting-Schicht, Self-Service, Admin-Konsole und Integrationsplattform sein, weil jede dieser Kategorien eigene Test- und Betriebsrisiken mitbringt.
Individuelle Webanwendungen: Technologien, Vorteile, ROI stellt die ROI-Frage sinnvoll, aber der ROI entsteht nicht durch „individuell“ als Etikett, sondern durch den Verzicht auf Funktionen, die keine Entscheidung, keinen Umsatz oder keine Risikoreduktion beschleunigen.
Ich würde bei kleinem Budget nicht zuerst eine Microservice-Architektur bauen, weil Netzwerkgrenzen, Authentifizierung zwischen Services, Deployment-Koordination und Observability schon vor dem ersten Nutzer Komplexität erzeugen. Ein modularer Monolith mit klaren Verzeichnissen, PostgreSQL-Schema und OpenAPI-3.1-Vertrag reicht für viele MVPs länger, als Architekturdiagramme vermuten lassen.
Ebenso würde ich nicht „No-Code plus später neu bauen“ als Standardstrategie wählen, weil Migrationen selten nur Datenexporte sind: Rechte, Historien, Validierungsregeln und Benachrichtigungslogik müssen rekonstruiert werden. No-Code ist stark, wenn der Prozess noch unsicher ist und die Daten nicht kritisch sind; er ist schwach, wenn er früh zur Quelle operativer Wahrheit wird.
Realistische Schätzung beginnt bei Risiken, nicht bei Screens
Ein Product Scope wird genauer, wenn er nach Risiko sortiert ist. Die teuersten Fragen lauten meistens: Wer darf was sehen? Welche Daten sind verbindlich? Was passiert bei fehlerhaften Eingaben? Welche Systeme müssen angebunden werden? Wie wird ein Vorgang nachvollzogen? Diese Fragen klingen unspektakulär, aber sie entscheiden über Aufwand, weil sie Architektur, UI, Tests und Betrieb gleichzeitig berühren.
Für einen ernsthaften Low-Budget-MVP würde ich einen Discovery-Block von 3 bis 5 Arbeitstagen ansetzen; das ist kein Naturgesetz, sondern eine bewusst zu tune Stellgröße, die klein genug bleibt, aber groß genug ist, um Datenmodell, Rollen, Nicht-Ziele und Integrationen festzulegen. Wer diese Tage streicht, spart sichtbar am Angebot und unsichtbar an der Qualität der Schätzung.
Die beste Scope-Einheit ist ein überprüfbarer Arbeitsfluss, nicht eine Seite. „Nutzer lädt CSV hoch, System validiert 1.000 Zeilen, zeigt 20 Fehler, speichert gültige Datensätze und schreibt ein Audit-Log“ ist schätzbarer als „Importseite“. Die Zahl 1.000 Zeilen sollte als Lastannahme im Projekt entschieden werden, weil daraus Timeout, Batch-Verarbeitung, Fehlermeldung und Datenbankindizes folgen.
Ein minimaler technischer Spike kann in einem halben Tag klären, ob das Team die Basis beherrscht. Zum Beispiel läuft ein Vite-Prototyp mit React und TypeScript so:
npm create vite@latest budget-probe -- --template react-ts cd budget-probe npm install npm run build npm run dev -- --host 0.0.0.0
Dieser Code baut noch kein Produkt, aber er trennt Diskussion von Realität, weil Build-Zeit, Struktur, Linting und lokale Ausführung sofort sichtbar werden. Für echte Projekte kommen danach Vitest 2, Playwright 1.45, ESLint 9, TypeScript 5.5 und ein CI-Lauf in GitHub Actions hinzu, weil man sonst Fehler erst im Review oder nach dem Deployment findet.
Für die Schätzung sollte der Product Manager mindestens diese Entscheidungen festhalten:
- Auth: OAuth 2.1, SAML 2.0 oder E-Mail-Magic-Link; SAML kostet mehr, weil Identity-Provider-Konfigurationen und Unternehmensrichtlinien getestet werden müssen.
- API-Vertrag: OpenAPI 3.1 oder GraphQL; OpenAPI gewinnt bei klaren CRUD-Flows, weil Verträge und Mocking einfacher kontrollierbar sind.
- Datenbank: PostgreSQL 16 mit Migrationen oder ein SaaS-Backend; PostgreSQL gewinnt bei langfristiger Datenhoheit, weil Schema, Indizes und Backups explizit steuerbar sind.
- Qualität: Playwright-End-to-End-Tests für Kernpfade, weil Unit-Tests allein keine kaputten Rollenflüsse finden.
- Betrieb: Sentry, OpenTelemetry und strukturierte Logs, weil Fehler ohne Kontext zu Support-Raten statt Entwicklungsaufgaben werden.
Als konkrete Qualitätsgrenze kann ein Team eine Lighthouse-Performance von 90 oder höher für öffentliche Seiten vereinbaren; dieser Schwellenwert ist eine interne Zielmarke, keine Garantie für Umsatz, aber er verhindert, dass Performance erst kurz vor Launch entdeckt wird. Für Interaktion ist Googles veröffentlichte INP-Schwelle von 200 ms eine sinnvolle Orientierung, weil schlechte Reaktionszeiten Formulare und Admin-Flows direkt langsamer machen.
Professionell heißt: weniger bauen, aber Betrieb und Änderbarkeit einpreisen
„Properly“ bedeutet bei begrenztem Budget nicht Enterprise-Zeremonie. Es bedeutet, die Dinge zu bezahlen, die später teuer zu retten sind: Versionskontrolle, Deployment, Backups, Monitoring, Sicherheitsupdates, Testdaten, Rollenmodell und ein sauberer Umgang mit personenbezogenen Daten. Diese Basis ist unsichtbar, aber sie schützt den Scope, weil Änderungen dann nicht jedes Mal Angst auslösen.
Ein pragmatischer Stack könnte so aussehen: Next.js 14 mit App Router für UI und serverseitige Funktionen, PostgreSQL 16 für relationale Daten, Prisma 5 für Migrationen, Redis 7 für kurzlebige Jobs oder Rate Limits, Docker 24 für lokale Reproduzierbarkeit und GitHub Actions mit workflow_dispatch für kontrollierte Deployments. Das ist kein Trend-Stack, sondern eine Auswahl, die viele Teams betreiben können, weil Dokumentation, Hostingoptionen und Entwicklerverfügbarkeit gut sind.
Bei Hosting ist die Budgetfrage konkret. Vercel Pro liegt laut Anbieterpreis bei 20 US-Dollar pro Nutzer und Monat, während ein kleiner AWS-Aufbau mit Lambda, RDS und CloudWatch schnell günstiger oder teurer werden kann, weil Datenbank, Traffic, Backups und Betriebszeit separat zählen. Vercel gewinnt, wenn das Team wenig Ops-Kapazität hat; AWS gewinnt, wenn Infrastrukturkontrolle, Netzwerkregeln oder bestehende Verträge wichtig sind.
Security wird in kleinen Budgets gern als späterer Block behandelt, aber das ist riskant, weil nachträgliche Zugriffskorrekturen Datenmigrationen, UI-Anpassungen und Supportkommunikation auslösen. Mindestens nötig sind OWASP-ASVS-4.0-orientierte Checks für Authentifizierung, CSRF-Schutz bei zustandsändernden Requests, sichere Cookies mit SameSite=Lax oder Strict, und rollenbasierte Tests für verbotene Zugriffe.
Barrierefreiheit ist ebenfalls kein Finish-Polish, weil WCAG 2.2 AA etwa Kontrastverhältnisse von 4,5:1 für normalen Text fordert und spätere Farb- oder Komponentenänderungen durch viele Screens wandern. Wer früh mit Radix UI, shadcn/ui oder geprüften HTML-Formularmustern arbeitet, spart Nacharbeit, weil Fokuszustände, Labels und Tastaturbedienung nicht improvisiert werden.
Ich würde Reporting nicht im ersten Release frei konfigurierbar machen, weil flexible Berichtseditoren fast immer ein Produkt im Produkt werden. Zwei harte Exporte als CSV und ein vordefiniertes Dashboard reichen oft, weil sie echte Entscheidungen unterstützen, ohne Filterlogik, Berechtigungsmatrix und Performance-Optimierung explodieren zu lassen.
Auch „KI später leicht ergänzen“ würde ich nicht versprechen, weil sinnvolle Automatisierung saubere Daten, Rechte, Evaluationsmetriken und Fehlertoleranz braucht. Wenn KI im Scope steht, gehört eine konkrete Metrik dazu, etwa Präzision, Bearbeitungszeit oder manuelle Korrekturrate; ohne diese Metrik wird KI zur Budgetreserve ohne Abnahmekriterium.
Der erste Schritt ist ein Budget-Schnitt mit harten Nicht-Zielen
Schreiben Sie als Nächstes keine Featureliste, sondern eine einseitige Scope-Notiz mit drei Kernflüssen, drei Nicht-Zielen, zwei Integrationen und einer Betriebsannahme. Ergänzen Sie pro Kernfluss ein Akzeptanzkriterium und eine Zahl, die getestet werden kann. Danach kann ein Team seriös sagen, was klein gebaut werden darf und was nur billig aussehen würde.
