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 die Situation in drei Sätzen — wie viele Endkunden, welche fünf Self-Service-Aktionen sind Top-Prio, welche Pflicht-Integration ist im Spiel — über das Kontaktformular. Wir antworten in 24 Stunden 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.