White-Label-Entwicklung für Agenturen in Deutschland: Entscheidungsrahmen, agile Abläufe und praxistaugliche Vorlagen

Wann Outsourcing sinnvoll ist

• Engpässe und Peaks: Wenn interne Entwicklerkapazitäten voll ausgelastet sind, aber Deadlines fix bleiben (Relaunches, Kampagnen, saisonale Spitzen).
• Spezial-Know-how: Für Technologie-Stacks oder Integrationen, die intern selten gebraucht werden (z. B. komplexe Shop-Checkout-Flows, Headless-Setups, API-Integrationen, Performance-Audits).
• Time-to-Market: Wenn ein schneller Markteintritt Priorität hat und der Aufbau interner Skills zu lange dauern würde.
• Risiko- und Qualitätsmanagement: Wenn Sie eine saubere Trennung zwischen Konzeption/Design und technischer Umsetzungsverantwortung wünschen.
• Wirtschaftlichkeit: Wenn der externe Stundensatz bei planbarer Auslastung günstiger ist als FTE-Kosten inkl. Overhead.
• White-Label-Anforderungen: Wenn Sie den Tech-Partner nahtlos in Ihr Agentur-Branding und Ihre Kundenkommunikation integrieren möchten.

Wann Outsourcing nicht sinnvoll ist

• Unklare Anforderungen, kein Product Owner auf Agenturseite, fehlende Entscheidungswege.
• Erwartung „Festpreis, unklarer Scope, starre Deadline“ ohne Puffer für Anforderungen und QA.
• Kritische Legacy-Systeme ohne Dokumentation, auf die kein externer Zugang möglich ist.

Auswahlkriterien für spezialisierte Programmier-Dienstleister (z. B. jar.media)

• Technologische Passung: Referenzen in CMS/Shop-Systemen und Frameworks, die Sie häufig verkaufen.
• Prozessreife: Nachweisbare Agile-Praxis, Code-Reviews, CI/CD, Regression-Strategien, Release-Management.
• White-Label-Fitness: Auftritt unter Ihrer Marke (Mail-Alias, Meeting-Etikette), Verfügbarkeit für Pitches und Reviews.
• Sicherheit & Compliance: DSGVO/TTDSG, AVV (Auftragsverarbeitungsvertrag), TOMs, Zugriffskonzepte, Logging und Backups.
• Qualität: Automatisierte Tests, Linting/Standards, Accessibility- und Performance-Kompetenz.
• Kalkulation & Transparenz: Stundensätze, Planbarkeit, realistische Schätzungen, klare Change-Mechanik.
• Zusammenarbeit in Teilprojekten: Fähigkeit, in bestehende Repos/Standards zu integrieren und mit internen Devs Hand in Hand zu arbeiten.

White-Label-Setup und rechtliche Grundlagen (Deutschland)

• NDA und AVV: Schließen Sie neben einem NDA stets eine AVV inkl. TOMs nach DSGVO ab (keine Rechtsberatung).
• Rollen & Kommunikationswege: Ein klarer Single Point of Contact (Agentur-PO) auf Ihrer Seite; Tech Lead beim Dienstleister.
• Markenneutralität: E-Mail-Aliasse, Tickets als „internal only“ markieren, definierte Eskalationswege.
• Zugriff & Datenschutz: Prinzip „least privilege“, getrennte Staging-/Produktivsysteme, Pseudonymisierung/Testdaten.
• SLAs: Reaktionszeiten (z. B. 4h bei P1), Lieferkorridore, Wartungsfenster, Notfall- und Rollback-Prozesse.

Hinweis zu Stundensätzen (Beispiel jar.media)

• 95 € pro Programmiererstunde
• 105 € pro Beraterstunde (jeweils netto, nur für Projekte mit deutschen Auftraggebern geeignet)

2. Von Budgetschätzung bis agilen Sprints: Ablauf & Tooling

Vom Briefing zur Schätzung 1) Discovery/Intake: Gemeinsamer Scope-Abgleich inkl. Risiken, Annahmen, Nicht-Ziele. 2) Grobkonzept und Epics: Zerlegung in Features/Epics; erste Akzeptanzkriterien definieren. 3) Aufwandsmodell: T-Shirt-Sizes → Stundenbandbreiten; Puffer für QA/Meetings (typ. 15–25 %). 4) Budget- und Kostenschätzung: Abgleich mit Zielbudget; Priorisierung nach Business Value. 5) Kick-off: Definition von Team, Tools, Kommunikationsrhythmus und Go-live-Kriterien.

Agile Umsetzung in Sprints

• Sprint-Länge: 1–2 Wochen; Planungsmeeting, Daily (15 Min), Review, Retro.
• Rollen: Product Owner (Agentur), Tech Lead/Dev-Team (Dienstleister), optional QA/Editoren.
• Backlog-Pflege: Tickets mit Akzeptanzkriterien, Definition of Ready (DoR) vor Sprintstart.

Tooling (Tickets, Repos, Environments)

• Ticketsystem: Jira, Linear, Asana oder Trello mit Statusflow (Backlog → In Progress → Code Review → QA → Ready for UAT → Done).
• Repositories: GitHub/GitLab/Bitbucket, Protected Branches, Code Owner Reviews, konventionelle Commits, Semver-Tags.
• Branching: trunk-based mit Feature-Branches oder Gitflow light; automatisierte Checks (CI).
• CI/CD: Build, Tests, Linting, Security-Checks, Deploy auf Dev/Staging, manuelles Gate zu Prod.
• Environments: Dev (Entwicklung), Staging (UAT), Prod (Live) mit identischen Konfigurationen; Feature Flags für inkrementelle Releases.
• Dokumentation: README, Tech-Notes pro Epic, ADRs bei Architekturentscheidungen.

Definition of Done (DoD) – Vorschlag

• Code: Peer-Review erfolgt; Linting und CI grün; keine kritischen Security-Findings.
• Tests: Unit- und Integrations-Tests vorhanden/passed; Smoke-Tests auf Staging erfolgreich.
• Qualität: Performance-Budgets eingehalten (z. B. LCP/CLS), Basis-SEO umgesetzt, WCAG 2.1 AA geprüft.
• Dokumentation: Technische Notizen aktualisiert; Redaktionsleitfaden/Changelogs gepflegt.
• Deployment: Auf Staging ausgerollt; UAT-Daten verfügbar; Rollback-Plan dokumentiert.

Akzeptanzkriterien (AC) – Best Practices

• Klar, testbar, fachlich formuliert; ideal als Given/When/Then.
• Abdeckung von Edge-Cases, Validierungen, Tracking/Consent, Fehlerzuständen.
• Einschluss von Messkriterien (z. B. „Page lädt LCP < 2,5 s auf 4G“).

3. Teilprojekte, Übergabe an Content-Teams, Freigabe- und Change-Prozesse

Zusammenarbeit neben eigenen Devs

• Verantwortlichkeiten: Komponenten-/Modul-Ownership festlegen; wer reviewed wessen Code?
• Standards: Gemeinsame Coding-Guidelines, Lint-Regeln, Branch-Namen, Commit-Konventionen.
• Schnittstellenverträge: API-Spezifikationen/versionierte Schemas; klare Fehler- und Timeout-Strategien.
• PR-Regeln: Mind. 1 interner Review + 1 externer Review bei kritischen Bereichen.
• Wissenstransfer: Pairing-Sessions, Brown-Bags, kurze Loom/Videonotizen zu komplexen Stellen.

Übergabe an Content- und Kampagnenteams

• Redaktionsrollen und -rechte im CMS, Asset-Spezifikationen, Bildkompression.
• Modularer Content: Komponentenbibliothek mit Beispielen; Vermeidung harter Layout-Abhängigkeiten.
• Datenmigration: Skripte/Mapper, Redirect-Plan, Content-Freeze-Fenster, QA der migrierten Inhalte.
• Schulung: 60–90 Minuten Enablement-Session, Cheat-Sheets, kurze GIFs/Clips zu Workflows.

Freigabe- und Change-Management

• UAT-Prozess: Testfälle durch Fachabteilung der Agentur; Abnahme per Ticketkommentar oder sign-off-Formular.
• Go-live-Check: DNS/SSL, Caching/CDN, Consent/Tracking, Error Monitoring, Backups, Rollback-Plan, Verantwortungsmatrix (RACI).
• Change Requests (CR): Bewertung Impact/Komplexität, Aufwandsschätzung, Budgetfreigabe; CRs getrennt versionieren.
• Versionierung: Releases taggen, Release Notes, Hotfix-Prozess mit klaren SLAs.

4. Qualitätssicherung: Akzeptanz, Tests und Betrieb

Mehrstufige QA

• Selbstprüfung (Dev): Checkliste pro Ticket vor PR.
• Peer Review (Code): Fokus auf Logik, Sicherheit, Lesbarkeit, Tests.
• Formelle QA (Tester/PO): Exploratives Testen, Cross-Browser/-Device, Accessibility.
• UAT (Agenturfachseite): Test der Business-Ziele; Freigabe für Go-live.

Testpyramide und Monitoring

• Unit-Tests: Kernlogik, Helper, Validierungen.
• Integrations-/API-Tests: Schnittstellen, Payment/Versand, Auth-Flows.
• E2E-Tests: Kritische Journeys (Checkout, Lead-Formulare) via Playwright/Cypress.
• Performance: Lighthouse-Budgets, Web Vitals Alerts; Bildoptimierung, Caching-Strategien.
• Sicherheit: OWASP Top 10-Checks, Dependency-Scanning, Header-Härtung, Rate Limiting.
• Datenschutz: DSGVO/TTDSG-konformes Consent-Management, Log-Rotation, Datenminimierung.
• Observability: Monitoring (Uptime), Logging, Alerting, Error-Tracking (z. B. Sentry), definierte SLOs.

5. Zahlen, Margenplanung und praxistaugliche Vorlagen

Kalkulatorische Beispiele mit 95 €/105 € (netto)

• Beispiel A: Website-Feature (z. B. modulare Landingpage)
  • Aufwand: 60 Std. Entwicklung, 8 Std. Beratung/PM
  • Kosten Dienstleister: 60 × 95 € = 5.700 €; 8 × 105 € = 840 €; Summe = 6.540 €
  • Weiterverkauf (z. B. 130 €/Std. Dev, 150 €/Std. Beratung):
  • Erlös: 60 × 130 € = 7.800 €; 8 × 150 € = 1.200 €; Summe = 9.000 €
  • Marge: 9.000 € − 6.540 € = 2.460 € ≈ 27,3 %
• Beispiel B: Teilprojekt in bestehendem Shop (zusätzlicher Checkout-Step)
  • Aufwand: 25 Std. Entwicklung, 4 Std. Beratung/PM
  • Kosten Dienstleister: 25 × 95 € = 2.375 €; 4 × 105 € = 420 €; Summe = 2.795 €
  • Weiterverkauf (z. B. 130 €/Std. Dev, 150 €/Std. Beratung):
  • Erlös: 25 × 130 € = 3.250 €; 4 × 150 € = 600 €; Summe = 3.850 €
  • Marge: 3.850 € − 2.795 € = 1.055 € ≈ 27,4 %
• Beispiel C: Retainer (monatlich, Kapazitätssicherung)
  • Aufwand: 30 Std. Entwicklung/Monat
  • Kosten Dienstleister: 30 × 95 € = 2.850 €
  • Weiterverkauf (z. B. 125 €/Std.): Erlös = 3.750 € → Marge = 900 € ≈ 24,0 % Hinweise:
• Berücksichtigen Sie zusätzliche interne Aufwände (Kreation, QA, Akquise).
• Planen Sie Puffer für CRs (z. B. 10–15 % Change-Budget).
• Dokumentieren Sie Annahmen in jeder Schätzung; halten Sie Bandbreiten transparent.

Briefing-Template (Kopievorlage)

• Projektname, Auftraggeber, Ansprechpartner (PO/Tech/QA), Kommunikationskanäle
• Business-Ziele und KPIs (z. B. Leads, Conversion, AOV)
• Zielgruppen, Devices, Barrierefreiheitsanforderungen (WCAG 2.1 AA)
• Scope und Nicht-Ziele; Milestones; Go-live-Fenster
• Systeme & Technologiepräferenzen (CMS/Shop, Hosting, CDN)
• Funktionen/Epics inkl. erste Akzeptanzkriterien (Given/When/Then)
• Integrationen (CRM, ERP, Payment, Versand, Analytics, Consent)
• Content-Strategie (Migration, Verantwortliche, Content-Freeze)
• SEO/Performance-Vorgaben (Core Web Vitals, Metadaten, Sitemap/Redirects)
• Datenschutz & Sicherheit (AVV, TOMs, Rollen/Rechte, Logs, Backups)
• Design-Assets (Styleguide, Komponenten, Figma-Links, Responsives)
• Teststrategie (Browser/Device-Matrix, Testarten, Budgets)
• Abnahme- und Freigabekriterien; Rollback-Plan
• Budgetrahmen, Abrechnungsmodus (Stunden 95/105 €, Retainer), Reporting
• Risiken/Annahmen, Definition of Ready, Definition of Done

AC-Checkliste (für jedes Ticket/Feature)

• Businessziel klar beschrieben und messbar
• Nutzerfluss inkl. Edge-Cases definiert
• Validierungsregeln und Fehlermeldungen spezifiziert
• Tracking/Consent berücksichtigt (TTDSG/DSGVO)
• Responsives Verhalten (Breakpoints) beschrieben
• Performance-Budget/Assetspezifikationen enthalten
• Accessibility-Kriterien (Fokus, Kontrast, ARIA) aufgenommen
• Fehlerzustände, Leere-Zustände, Ladeindikatoren definiert
• Testfälle (Given/When/Then) formuliert
• Abhängigkeiten/Integrationen (APIs, Events) benannt
• Übersetzungen/Internationalisierung (falls relevant)
• Akzeptanz durch PO: „Was ist Done?“ eindeutig

Handover-Checkliste (an Content/Betrieb/Agentur-IT)

• Repositories (Zugriff, Branch-Protection), Infrastruktur-Übersicht, Secrets-Management
• Deploy-Pipelines dokumentiert; Release- und Rollback-Prozesse
• Administrator- und Redakteursrollen eingerichtet; Berechtigungsmatrix
• Komponentenbibliothek mit Beispielen, Redaktionsleitfaden
• Monitoring/Alerting aktiviert; Error-Tracking verknüpft
• Backups/Restore getestet; Wartungsfenster definiert
• Performance-/SEO-Berichte (Lighthouse, Web Vitals), Accessibility-Report
• Testdokumentation (Automatisiert/E2E, Manuelle Cases), Abnahmedokument
• Lizenzübersicht (Themes, Plugins, Libraries), Urheberrechte/Asset-Quellen
• Übergabe-Workshop/Training durchgeführt; Ansprechpartner & SLAs dokumentiert

Mit diesem Playbook etablieren Sie eine wiederholbare, auditierbare und für Endkunden transparente Zusammenarbeit mit spezialisierten Programmier-Dienstleistern – ob als vollwertiges White-Label-Team oder als punktuelle Verstärkung neben Ihren eigenen Entwicklerinnen und Entwicklern. So sichern Sie Qualität, Planbarkeit und Marge – in Deutschland, DSGVO-konform und skalierbar.