Von der Idee zur Python-Webanwendung: So läuft ein Agenturprojekt ab

Von der Idee zur Python-Webanwendung: So läuft ein Agenturprojekt ab

Die meisten Unternehmen wissen, dass sie eine neue Webanwendung brauchen. Aber viele sind unsicher, wie das funktioniert. Wie läuft ein Agenturprojekt ab? Wie lange dauert es? Wann ist mein Produktteam involviert? Wann kann ich launch?

Wir machen die Agentur-Realität transparent. So läuft ein Python-Webanwendungs-Projekt von der Idee bis zur Production und darüber hinaus.

Phase 1: Anforderungsanalyse & Briefing (1-2 Wochen)

Bevor code geschrieben wird, muss klar sein, was gebaut wird.

Was passiert in dieser Phase?

Discovery-Gespräche:

Die Agentur sitzt mit Ihrem Team zusammen und versteht:

• Was ist das Business-Problem, das gelöst werden soll?
• Wer sind die Nutzer der Anwendung?
• Wie wird Erfolg gemessen? (KPIs)
• Gibt es bestehende Systeme, die integriert werden müssen?
• Was sind hard Requirements, was ist nice-to-have?

Beispiel Frage:

"Sie sagen, Sie brauchen ein Kundenportal. Aber was ist der konkrete Schmerz heute? Wie viele Support-Anrufe könnten reduziert werden? Wie viel Zeit sparen Ihre Mitarbeiter?" → Das bestimmt später die Priorisierung.

Anforderungs-Dokument:

Am Ende dieser Phase gibt es ein Dokument, das alle Anforderungen zusammenfasst. Nicht 500 Seiten Prosa, sondern eine pragmatische Specification:

• User Stories ("Als Kundenservice-Mitarbeiter möchte ich Bestellungen einsehen, damit ich schneller antworten kann")
• User Flows (Wireframes oder einfache Sketches)
• Non-Functional Requirements (Performance, Security, Skalierbarkeit)
• Integration Punkte (mit welchen Systems muss verbunden werden?)

Ihr Part als Unternehmen:

• Verfügbarkeit: 2-3 Key Stakeholder sollten verfügbar sein für Interviews
• Entscheidungskompetenz: Jemand muss das ok geben
• Kontext: Bereiten Sie Infos vor (bestehende Systeme, Datenschleifen, etc.)

Das Deliverable:

Ein Anforderungs-Dokument und ein grobes Abschätzung von Zeitaufwand und Budget.

Phase 2: Konzept & Architektur (1-2 Wochen)

Jetzt wird der technische Bauplan erstellt.

Was passiert in dieser Phase?

Technologie-Auswahl:

Die Agentur entscheidet:

• Welches Web Framework? (Django für größer, FastAPI für schneller/moderner)
• Wo wird gehostet? (AWS, Google Cloud, PythonAnywhere – je nach Anforderungen)
• Welche Datenbank? (PostgreSQL für robust, SQLite für klein)
• Frontend-Technologie? (React, Vue, oder Django-Templates für einfacher)
• Mobile? (Web-App, Progressive Web App, oder native?)

System-Architektur:

Ein einfaches Diagram, das zeigt:

┌─────────────────┐
│   Web Browser   │
│  (Frontend)     │
└────────┬────────┘
         │ HTTPS
┌────────▼────────┐
│  Python API     │
│  (Backend)      │
└────────┬────────┘
         │ SQL
┌────────▼────────┐
│   PostgreSQL    │
│   (Datenbank)   │
└─────────────────┘

Oder komplexer:

┌──────────┐     ┌─────────────┐     ┌──────────┐
│  Website │     │ Mobile App  │     │ Admin UI │
└────┬─────┘     └──────┬──────┘     └────┬─────┘
     │                  │                   │
     └──────────────────┼───────────────────┘
                        │ REST API
                ┌───────▼────────┐
                │ Python Backend │
                └───────┬────────┘
                        │
        ┌───────────────┼───────────────┐
        │               │               │
    ┌───▼────┐    ┌──────▼──┐    ┌─────▼──────┐
    │  DB    │    │  Redis  │    │  3rd API   │
    │        │    │ (Cache) │    │  (Payment) │
    └────────┘    └─────────┘    └────────────┘

API-Design:

Welche Endpoints brauchen Sie? Die Agentur skizziert:

GET  /api/orders/          → Alle Bestellungen
GET  /api/orders/{id}/     → Einzelne Bestellung
POST /api/orders/          → Neue Bestellung erstellen
GET  /api/customers/{id}/  → Kundendaten

Datenbank-Schema:

Welche Tabellen, welche Relationen? Das ist wichtig, damit keine "Oops, wir müssen umgestalten" passiert.

Security Plan:

• Wie werden Benutzer authentifiziert? (JWT Token, Session Cookies?)
• Welche Daten sind sensibel? (Verschlüsslung nötig?)
• DSGVO/Datenschutz-Anforderungen?

Ihr Part:

• Feedback: Sie bekommen Mockups und System-Diagramme, geben Feedback
• Integrationen: Klären, wie Third-Party-Systeme angebunden werden
• Sign-off: Alle Stakeholder müssen dem Plan zustimmen

Das Deliverable:

Ein Architektur-Dokument mit:

• System-Diagramm
• Technologie-Auswahl + Begründung
• API-Endpoints
• Datenbank-Schema
• Security-Plan
• Detaillierte Zeitschätzung

Phase 3: Agile Entwicklung in Sprints (4-12 Wochen, je nach Größe)

Nun wird es konkret. Code wird geschrieben.

Sprint-Struktur (typisch 2 Wochen pro Sprint)

Sprint Planning (Montag morgens):

Das Team (Agentur + Ihr Produkt-Manager) definiert, was in den nächsten 2 Wochen gebaut wird:

• Story 1: "Benutzer-Login implementieren"
• Story 2: "Bestellungs-Übersicht UI bauen"
• Story 3: "Daten von altem System migrieren"

Daily Standup (10 Min, täglich):

Jedes Team-Mitglied berichtet: Was habe ich gestern gemacht? Was mache ich heute? Gibts Blockers?

Entwicklung (Mittwoch-Donnerstag):

Developer schreiben Code. Designer feinschleifen UI. Tester schreiben Test-Cases.

Sprint Review (Freitag Nachmittag):

Das Team zeigt, was gebaut wurde. Feedback von Stakeholdern.

Sprint Retrospective (Freitag später):

Das Team reflektiert: Was funktionierte? Was nicht? Wie verbessern wir uns nächste Woche?

Continuous Integration / Continuous Deployment (CI/CD)

Jede Codeänderung wird automatisch:

1. Getestet (Unit Tests, Integration Tests)
2. Auf Code Quality geprüft (Linting, Security-Scans)
3. In Staging deployiert (eine Kopie der Production zum Testen)
4. Nach Genehmigung in Production deployiert

Das bedeutet: Neue Features erscheinen mehrmals pro Woche – nicht erst nach 6 Monaten.

Ihr Part in jedem Sprint:

Wöchentliche Demo (Freitag):

Sie sehen, was gebaut wurde. Feedback geben.

Feedback Loop:

"Die Bestellungs-Übersicht sieht gut aus, aber können wir die Suchfunktion auch nach Kundennamen erlauben?" → Das geht in den nächsten Sprint.

Availability for Testing:

Wenn es Integrationen mit bestehenden Systemen gibt (z.B. ERP), können Sie testen, dass es funktioniert.

Beispiel-Sprint Ablauf (2 Wochen):

Woche 1:

• Backend-Entwickler: APIs implementieren
• Frontend-Entwickler: UI bauen
• Tester: Test Cases schreiben

Woche 2:

• Alle arbeiten an Integrationen
• Bug Fixes
• Performance-Optimierung
• Review & Deployment zu Staging

Am Ende: Eine funktionierende, getestete neue Version im Staging-Umfeld.

Phase 4: Testing & QA (1-2 Wochen)

Bevor Launch, müssen wir sicherstellen, dass es funktioniert.

Was wird getestet?

Functional Testing:

Tut das System, was es soll?

• Kann ich mich einloggen? ✓
• Kann ich eine Bestellung aufgeben? ✓
• Wird die Bestellung in der Admin-Ansicht angezeigt? ✓

Integration Testing:

Funktionieren alle Systeme zusammen?

• Wenn ich eine Bestellung erstelle, wird sie automatisch ins ERP-System synchronisiert? ✓
• Wenn ich einen Kunden im CRM aktualisiere, erscheint die Änderung im Portal? ✓

Security Testing:

• Kann jemand ohne Login auf sensitive Daten zugreifen? ✗ (Good, das sollte nicht funktionieren)
• Sind Passwörter properly gehasht? ✓
• Sind API-Keys sicher? ✓

Performance Testing:

• Lädt die Seite unter 2 Sekunden? ✓
• Kann das System 1000 gleichzeitige Benutzer handhaben? ✓
• Wie sieht die Database Performance unter Last aus?

User Acceptance Testing (UAT):

Echte Benutzer testen das System:

• "Ist die UI intuitiv?"
• "Fehlt etwas?"
• "Gibt es Bug?"

Often passiert hier noch kleine Pivots: "Können wir die Reihenfolge dieser Buttons ändern?"

Ihr Part:

Test Cases bereitstellen:

Ihr Domain-Knowledge ist wertvoll. "Bitte testet diesen spezifischen Workflow, der heute oft schief geht."

UAT durchführen:

Echte Endnutzer (Support-Team, Sales, etc.) sollten testen und Feedback geben.

Go/No-Go Entscheidung:

Wenn alles funktioniert, geben Sie grünes Licht zum Launch.

Das Deliverable:

Test Report mit allen gefundenen Issues, Fixes und Final Sign-Off.

Phase 5: Deployment & Launch (1-2 Tage)

Der große Moment: Live gehen.

Was passiert?

Vorletzter Tag:

• Finale Checks
• Backup von alt-System erstellen (falls Rollback nötig)
• Launch-Plan durchgehen

Launch-Tag:

• Früh morgens: Deployment zu Production
• Intensives Monitoring (ist alles stabil?)
• Support-Team on standby (falls Issues auftauchen)
• Schrittweise Rollout (nicht alle Nutzer auf einmal, falls Problem auftritt)

Nach Launch:

• 24-48h intensive Überwachung
• Hotfixes für kritische Issues
• Messaging an Benutzer ("Hey, wir haben eine neue Plattform!")

Contingency Plan:

"Was passiert, wenn etwas schief geht?"

Option 1: Quick Fix (Minor Bugs) → Agentur fixt es in Stunden

Option 2: Rollback (Critical Issue) → Zurück zur Alt-Version, Analyse, Re-Launch nächster Tag

Ihr Part:

Kommunikation:

Benachrichtige Kunden / Endnutzer von der neuen Plattform.

On-site Support (optional):

Wenn viele Nutzer helfen brauchen, kann das Agentur-Team vor Ort sein für Live-Support.

Feedback sammeln:

First Impressions von echten Nutzern sind wertvoll.

Phase 6: Wartung & Weiterentwicklung (Ongoing)

Launch ist nicht das Ende – es ist der Anfang.

Was ist Support?

Bug Fixes:

"Ich kann mich nicht einloggen wenn mein Name Umlaute hat" → Fixed in 1 Woche

Performance Tuning:

"Die Admin-Seite lädt langsam wenn es viele Benutzer gibt" → Optimiert in 2 Wochen

Security Updates:

Eine neue Sicherheitslücke wird entdeckt → Agentur patcht sofort

Feature Requests:

"Können wir auch CSV-Export hinzufügen?" → In nächsten Sprint, wenn Zeitbudget

Support Modelle:

Option 1: Dedicated Support Contract

"Wir zahlen X € pro Monat, und die Agentur ist verfügbar für Fixes & Improvements"

Gut für: Lange Partnerschaft, kontinuierliche Verbesserungen

Option 2: Time & Material

"Agentur fixed Bugs zum Standard-Stundensatz"

Gut für: Weniger regelmäßige Arbeit

Option 3: In-House Handover

"Agentur trainiert Ihr Team, damit Ihr Team es selbst warten kann"

Gut für: Langfristige Unabhängigkeit

Die Timeline: Wie lange dauert so ein Projekt?

Sehr einfach (Kundenportal, CRUD):

• Anforderungen: 1 Woche
• Design & Architektur: 1 Woche
• Entwicklung: 4 Wochen
• Testing & Launch: 1 Woche
• Total: 8 Wochen (2 Monate)

Mittel (E-Commerce mit Zahlungsintegration):

• Anforderungen: 2 Wochen
• Design & Architektur: 2 Wochen
• Entwicklung: 8 Wochen
• Testing & Launch: 2 Wochen
• Total: 14 Wochen (3-4 Monate)

Komplex (ERP-Integration, Real-time Features, vieles):

• Anforderungen: 2-3 Wochen
• Design & Architektur: 2-3 Wochen
• Entwicklung: 12-16 Wochen
• Testing & Launch: 2-3 Wochen
• Total: 20-25 Wochen (5-6 Monate)

Kosten-Struktur (typisch):

Anforderungen + Design: 10-15% Budget Entwicklung: 60-70% Budget Testing + Launch: 10-15% Budget Contingency (Überraschungen): 5-10% Budget

Ein Projekt mit 40 Development-Wochen und €100/h kostet also im Schnitt €40.000.

Red Flags: Woran erkenne ich eine schlechte Agentur?

❌ "Wir können alles in 2 Wochen fertig haben." → Unrealistisch

❌ "Keine User-Feedback nötig, wir wissen wie's gemacht wird." → Arroganz

❌ "Wir schreiben keine automatisierten Tests." → Risk für Bugs

❌ "CI/CD? Das brauchen Sie nicht für ein kleines Projekt." → False Economy

❌ "Sie können während des Projekts nicht sehen, was wir machen." → Black Box, zu viel Risk

Green Flags: Eine gute Agentur...

✅ Versteht Ihr Business, nicht nur die Technologie

✅ Zeigt Ihnen arbeits-in-progress regelmäßig

✅ Gibt realistische Schätzungen (mit Buffer für Unbekanntes)

✅ Hat klare Kommunikations-Prozesse (Weekly Updates, Sprint Reviews)

✅ Hat Erfahrung mit ähnlichen Projekten

✅ Hat einen klaren Plan für Security, Performance, Skalierbarkeit

✅ Bietet nach-Launch Support & Maintenance

Fazit: Transparenz macht den Unterschied

Ein gutes Agenturprojekt ist kein "Black Box". Sie sollten verstehen:

• Wer macht was, wann?
• Wie wird Fortschritt gemessen?
• Wann kann ich Feedback geben?
• Wann ist Launch?
• Was passiert danach?

Eine erfahrene Python-Agentur macht all das transparent. Von der ersten Idee bis zum erfolgreichen Launch – und darüber hinaus.