Portal in 12 Wochen: wie eine V1 trägt

Ein Kundenportal-V1 in 12 Wochen ist machbar, wenn der Scope diszipliniert geschnitten ist und die Phasen sauber aneinandergefügt sind. Wer in 12 Wochen alles bauen will, baut nichts; wer 24 Wochen für eine V1 braucht, hat den Scope zu früh aufgemacht. Hier ist der Phasen-Plan, mit dem ein Portal in 12 Wochen vom Spec ins Live-Betrieb geht, und wo die häufigsten Reibungspunkte sitzen.

Was in 12 Wochen passt und was nicht

Eine 12-Wochen-V1 trägt einen klar abgegrenzten Funktionsumfang:

• Login mit 2FA, einfaches Rollen-Modell (1–2 Rollen).
• Dashboard mit Status-Sicht.
• Fünf bis sieben Self-Service-Aktionen.
• Datei-Up- und Download mit Versionierung.
• Eine Pflicht-Integration plus Basis-Reporting.

Was in 12 Wochen nicht trägt: Multi-Tenant mit Whitelabel pro Kunde, drei oder mehr Pflicht-Integrationen, SSO mit branchenspezifischem Identity-Provider, Audit-Trail für regulierte Branchen, vollständiges Reporting mit Export-Funktionen. Wenn dein Vorhaben dort liegt, ist die ehrliche Antwort: 18–24 Wochen, nicht 12. Mehr zu Scope-Disziplin im Sub-Guide MVP oder direkt komplett.

Phase 1: Discovery: Wochen 1 bis 2

Die ersten zwei Wochen klären, was gebaut wird. In dieser Phase passieren drei Dinge:

• Endkunden-Interviews. Drei bis fünf Stamm-Endkunden werden gefragt: was kommt heute manuell zu dir, was nervt am meisten, was wäre die größte Erleichterung? Ohne diese Interviews entstehen Portale, die intern entworfen sind und extern nicht genutzt werden.
• Top-5-Aktionen-Schnitt. Aus den Interviews und der internen Sicht entsteht eine MoSCoW-Liste: Must-have, Should-have, Could-have, Won’t-have-this-time. Verhältnisse von etwa 60/20/0/20 sind ein gesunder V1-Start.
• Architektur- und Datenfluss-Spec. Welcher Datensatz lebt im CRM, welcher im Portal, wer ist Master? Hosting-Region, Auftragsverarbeiter, DSGVO-Bestandsaufnahme, siehe DSGVO bei der App-Entwicklung.

Häufiger Reißpunkt: Discovery wird auf eine Woche komprimiert oder ganz weggelassen. Eine Woche reicht für ein Standard-Portal selten, zwei Wochen sind die Untergrenze, in der ein belastbarer V1-Schnitt entsteht.

Phase 2: Sprint Zero: Woche 3

Sprint Zero ist die Woche zwischen Spec und erstem Feature-Code. Was darin passiert:

• Repos und CI/CD aufsetzen. Build-Pipeline, automatisierte Tests, Code-Review-Prozess.
• Designsystem. Komponenten-Bibliothek mit Farben, Typografie, Buttons, Formularen. Im Idealfall in Figma plus eine erste Code-Übersetzung im Portal.
• Datenmodell-Erstentwurf. Entitäten, Relationen, Lifecycle-States. Erste Sync-Logik zum CRM dokumentiert.
• Auth-Setup. Identity-Provider gewählt und integriert (Auth0, Clerk, Supabase Auth, Keycloak), 2FA aktiviert, erste Rollen angelegt.

Häufiger Reißpunkt: Auth wird mit „bauen wir später” verschoben. Auth ist nicht später. Auth-Architektur trägt das ganze Portal. Wer hier schludert, baut die Hälfte der App in V1.5 wieder um.

Phase 3: Build: Wochen 4 bis 11

Acht Wochen iterativer Build mit wöchentlichen Demos. Drei Eigenschaften, die einen guten Build-Modus auszeichnen:

Wöchentliche Endkunden-Demos

Idealerweise nicht nur interne Demos, sondern Demos mit einem oder zwei Endkunden, die in der Discovery befragt wurden. Frühes Endkunden-Feedback rettet drei Iterationen nach Launch und ist im Portal-Kontext wichtiger als bei einer App, weil Workflows hier oft branchenspezifisch sind.

Iterativer Scope, harte Won’t-have-Liste

Was nicht in der Must-have-Spalte steht, kommt nicht in V1, auch wenn theoretisch Zeit übrig ist. Die Zeit gehört in Stabilität, Performance und Polish der Must-haves. Eine harte Won’t-have-Liste schützt das Team vor Mittelweg-Features, die niemand wirklich nutzt.

Integration früh, nicht spät

Die Pflicht-Integration zum CRM oder ERP wird in Woche 5 oder 6 getestet, nicht erst in Woche 10. Integrationen sind die häufigste Quelle für Last-Minute-Verzögerungen. APIs reagieren langsamer als erwartet, Auth-Flows sind komplexer als dokumentiert, Daten-Formate weichen vom Schema ab. Wer Integrationen erst am Ende anfasst, schiebt jede Verzögerung in den Go-Live-Termin.

Häufiger Reißpunkt: Auftraggeber-Feedback erst in Woche 8. Bis dahin ist der Stack zementiert, und Korrekturen werden teuer. Wöchentlicher Rhythmus mit kurzen Demo-Checks ist die wichtigste Disziplin.

Phase 4: Hardening und Go-Live: Woche 12

Die letzte Woche ist nicht „Polish”, sondern eine eigene Disziplin. Was darin passiert:

• Penetrationstest oder Security-Review. Mindestens ein externer Blick auf Auth, Daten-Pfade und Berechtigungslogik. Bei DSGVO-relevanten Portalen ist das nicht optional.
• Performance-Test. Datenbank-Queries unter realistischer Last, Frontend-Loadtest mit den größten zu erwartenden Daten-Volumina, Cache-Verifikation.
• Backup- und Restore-Test. Tägliche Backups laufen, und der Restore-Pfad wurde in dieser Woche tatsächlich einmal durchgespielt. DSGVO-Art. 32 verlangt nicht ein Backup, sondern den nachweisbaren Recovery-Pfad.
• Beta mit zwei bis drei Endkunden. Soft-Launch, drei bis fünf Tage Endkunden-Feedback einsammeln, kritische Bugs beheben, erst dann Public-Go-Live.

Häufiger Reißpunkt: das Team plant Hardening und Go-Live als denselben Tag. In der Realität läuft Hardening selten ohne Findings, eine Woche Puffer ist Pflicht.

Was bewusst NICHT in V1 ist

Drei Klassen, die wir aktiv aus jeder 12-Wochen-V1 streichen:

• Multi-Tenant mit Whitelabel. Wenn das Portal später für mehrere Standorte oder Reseller laufen soll, wird die Tenant-Schicht in V1.5 oder V2 nachgezogen, sauber, in einem dedizierten Sprint. Multi-Tenant in V1 reinzudrücken bedeutet, jede Architektur-Schicht zu verdoppeln.
• Komplexes Reporting mit Export. Basis-Dashboard reicht. Endkunden-spezifische, konfigurierbare Reports, geplante Mail-Reports und CSV/Excel-Export sind ein eigenes Sub-Projekt.
• Tiefe SSO-Integration. SAML, OIDC mit branchenspezifischem Identity-Provider, Just-in-Time-Provisioning, das passt nicht in eine V1-Woche. Standard-Auth (Email + 2FA) trägt V1, SSO kommt in V1.5, wenn ein Großkunde es verlangt.

Mehr Kontext zu diesen Trade-offs im Sub-Guide Was kostet ein Kundenportal?, die ausgegrenzten Features sind exakt die Treiber, die V1 von einer 24-Wochen-Version unterscheiden.

Trigger für V1.5

Was nach dem Go-Live kommt, hängt nicht an einem Datum, sondern an Triggern. Drei typische:

• Mindestens 30 % der Endkunden nutzen V1 aktiv (mehr als ein Login pro Monat). Das ist die Schwelle, ab der V1.5-Investitionen in zusätzliche Self-Service-Aktionen sich rechnen.
• Top-3-Support-Anfragen wiederholen sich und sind Self-Service-fähig. Diese drei werden V1.5.
• Ein Großkunde verlangt ein Feature (typisch: SSO, eigenes Branding, ein neues Reporting). Das löst eine Sub-Discovery für V1.5 aus.

Was nicht V1.5 auslöst: interne Wunsch-Listen ohne Endkunden-Bezug. Sie wandern in die Could-have-Backlog-Spitze und werden bei der nächsten V2-Discovery neu bewertet.

Wenn du ein Portal in 12 Wochen planst und unsicher bist, ob dein Scope passt: beschreib uns über das Kontaktformular, wie viele Endkunden es gibt, welche fünf Self-Service-Aktionen Top-Prio sind und welche Pflicht-Integration im Spiel ist. Wir antworten zeitnah mit einer ehrlichen Einschätzung, ob 12 Wochen reichen oder ob 18 Wochen die realistische Zahl sind. Sovion-AppCare nach Go-Live beginnt bei 59 €, 149 € oder 349 € netto/Monat, sauberer Ausstieg jederzeit. Mehr Kontext: Wann löst ein Portal ein CRM ab?, Eigene Plattform bauen vs. SaaS mieten.