Product Engineering für Softwareunternehmen in den USA & der EU

Builds haben einen festen Scope und sind nach Typ gestaffelt, all-in und in USD kalkuliert. Ein Landing oder kleiner Build startet ab 1.100 $; eine Unternehmenswebsite oder ein internes System ab 2.900 $; ein Onlineshop oder Marktplatz ab 5.800 $; ein Portal oder Webservice ab 10.400 $. Die genaue Zahl hängt von der Anzahl der Bereiche und Rollen, der Anzahl der Integrationen (Zahlungen, Lieferung, CRM, Drittanbieter-APIs), der Komplexität der Geschäftslogik und dem Compliance-Scope ab. Sie sehen das Budget nach Positionen nach einer kostenlosen Scope-Bewertung und geben es frei, bevor eine Zeile Code geschrieben wird — kein Recruiting-Aufschlag, keine Tool-Zuschläge, und Cloud- und Drittanbietergebühren laufen über Ihre eigenen Konten.

Product Engineering ist ein ergebnisverpflichtetes Engagement: Ein funktionsübergreifender Pod (PM, Designer, Full-Stack-Entwickler, QA, DevOps, SRE) übernimmt die Verantwortung für eine Produktfläche oder ein gesamtes Produkt und wird an Produkt-KPIs gemessen — Aktivierung, Retention, NPS, Lead Time, Deploy-Frequenz. Staff Augmentation ist das Gegenteil: Sie mieten namentlich genannte Plätze, und Ihr Team besitzt Prioritäten, Design, QA und Betrieb. Product Engineering reduziert Übergaben und Managementaufwand auf Ihrer Seite; Staff Augmentation gibt Ihnen mehr direkte Kontrolle über den Arbeitsalltag jedes Entwicklers.

Im Discovery einigen wir uns auf zwei Ebenen von Metriken. Produkt-KPIs sind an den Nordstern des Produkts gebunden — Aktivierung, Retention, Conversion, NPS, Umsatz pro Nutzer, Time-to-Value. Engineering-KPIs decken die Lieferhygiene ab — Lead Time für Änderungen, Deploy-Frequenz, Change-Failure-Rate, MTTR. Wir berichten monatlich über beide und knüpfen Pod-Zusammensetzung und Roadmap-Entscheidungen an diese Zahlen. Der KPI-Satz wird gemeinsam mit Ihrer Produktführung verantwortet und jedes Quartal neu bewertet.

Standardmodell: Unser PM leitet den Pod und arbeitet in engem Gleichklang mit Ihrer Produktführung; unser Designer verantwortet UX und Design-System; unser Tech-Lead verantwortet die Architektur. Sie behalten das letzte Wort über Roadmap, Scope und Release. Wenn Sie bereits einen starken PM im Haus haben, können wir die PM-Rolle fallen lassen und den Pod unter Ihrem PM führen — in diesem Fall ersetzen wir den PM-Platz durch einen zusätzlichen Entwickler oder Designer zum gleichen Vollkosten-Satz.

Jedes Engagement beginnt mit einer ein- bis zweiwöchigen Discovery: Produkt-Narrative, Nordstern-Metrik, Zielnutzer, Scope des ersten Release, Erfolgskriterien, Architekturskizze und Risikoprotokoll. Das Ergebnis ist eine schriftliche Engagement-Charta, die wir beide unterzeichnen. Design läuft in einer gemeinsamen Figma-Bibliothek mit Design-Tokens einen Sprint vor dem Engineering. Die Discovery hat einen Festpreis; wenn Sie danach nicht fortfahren möchten, behalten Sie alle Arbeitsergebnisse und haben keine Verpflichtung zur Fortsetzung.

Die meisten Product-Engineering-Engagements laufen 9–24 Monate. Die kürzesten sind 6-monatige Neuprodukt-Builds — Discovery, MVP, öffentlicher Launch, erste 90 Tage Betrieb. Die längsten sind mehrjährige Plattformpartnerschaften, bei denen der Pod eine Produktfläche über mehrere größere Releases hinweg verantwortet. Wir nehmen keine Engagements unter sechs Monaten an, weil Produkt-KPIs in weniger Zeit nicht sinnvoll bewegt werden können und ein kürzeres Engagement durch unser dediziertes Team oder unser Individuelle-Softwareentwicklung-Angebot besser bedient wird.

Alle Pods sind standardmäßig DSGVO-konform: EU-Datenhaltung, EU-basierte Verträge, Auftragsverarbeitungsverträge auf Anfrage, Sub-Verarbeitungsregister. SOC 2 Type II ist in Vorbereitung. HIPAA-fähiges Scoping ist für Gesundheits-Workloads verfügbar — BAAs, verschlüsselte PHI-Verarbeitung, Audit-Trail. CCPA-Informationspflichten werden für US-Verbraucherdaten berücksichtigt, und wir stimmen uns mit Ihren Datenschutzhinweisen ab. ISO-27001-Kontrollen werden auf Repositories, Endpunkte und Zugriff angewendet. Bei Zahlungen agieren wir im PCI-DSS-Scope und stimmen uns mit Ihrem QSA ab.

Scope-Änderungen sind im Product Engineering normal; entscheidend ist der Prozess zu ihrer Handhabung. Zwischen Sprints können Sie das Backlog frei neu priorisieren — der Pod plant den nächsten Sprint gegen das, was gerade oben steht. Innerhalb eines Sprints akzeptieren wir grundsätzlich keine Scope-Änderungen: Mid-Sprint-Pivots zerstören den Flow, erhöhen die Fehlerquoten und machen die Velocity-Messung bedeutungslos. Für wirklich dringende Änderungen, die nicht ein bis zwei Wochen warten können, verwenden wir einen kontrollierten Sprint-Interrupt-Prozess: Der PM bewertet Impact-to-Effort, lässt gleichwertige Elemente aus dem Sprint fallen, und die Änderung wird in der Retrospektive als Sprint-Interrupt verfolgt, damit Muster in der Planung adressiert werden können.

Der minimale funktionsfähige Pod für ein Product-Engineering-Engagement umfasst vier Personen: einen PM, einen Designer, zwei Entwickler. Unterhalb dieser Kapazität kann ein Pod den Discovery-einen-Sprint-voraus-Rhythmus nicht aufrechterhalten, kein aussagekräftiges Code-Review durchführen oder die On-Call-Rotation handhaben. Wenn Sie einen oder zwei Entwickler benötigen, die gegen Ihren bestehenden PM und Ihr Design arbeiten, wird das besser durch unser dediziertes Entwicklungsteam-Angebot bedient. Der häufigste Start-Pod umfasst fünf bis sechs Personen und skaliert in Spitzen-Build-Phasen auf acht bis zwölf.

Wir schreiben keinen Stack vor. Wenn Sie eine bestehende Codebasis oder eine starke Technologiepräferenz haben, bauen wir darauf auf. Unsere Standardempfehlung für neue Produkte beginnt mit der Technologie, die der größte Pool an Senior-Entwicklern pflegen kann und die den geringsten operationellen Aufwand für das Produktskalenniveau hat. In der Praxis: React oder Next.js für Web-Frontends, React Native für plattformübergreifendes Mobile, Node.js oder Python für APIs, bei denen die Iterationsgeschwindigkeit zählt, Go für Services, bei denen der Durchsatz zählt, und PostgreSQL als Standard-Relational-Store. Wir vermeiden Framework-Churn; der Stack, mit dem der Pod im ersten Jahr ausliefert, sollte der Stack sein, in den ein neuer Entwickler im dritten Jahr eingestellt werden kann.

Die Übergabe ist ein strukturierter Prozess, kein Datei-Dump. Wir widmen die letzten 6 bis 8 Wochen eines Engagements dem Wissenstransfer: Architecture Decision Records dokumentiert im Repository, Runbooks von Ihrem Team gegen Live-Systeme getestet, On-Call-Shadowing, bei dem Ihre Entwickler gemeinsam mit unseren piepsen, und ein abschließendes Architektur-Review, bei dem Ihre Team-Leads die schwierigen Fragen stellen. Alle IP-Rechte gehen bei der Erstellung unter dem Master-Services-Agreement auf Sie über — wir behalten keine Retentionsrechte an Code, Daten oder Dokumentation. Das Ziel ist, dass Ihr Team am ersten Tag nach der Übergabe ausliefern, auf Vorfälle reagieren und Architekturentscheidungen treffen kann, ohne uns anrufen zu müssen.

Beides, aber die Engagement-Form unterscheidet sich. Bei frühen Startups ist die Discovery länger und die Charta leichter — wir helfen zu definieren, was der erste Release sein soll, nicht nur, wie das bereits Spezifizierte gebaut werden soll. Der Pod beginnt mit der Mindest-Vier-Personen-Konfiguration und skaliert, wie Finanzierung und Product-Market-Fit-Signal es bestimmen. Bei etablierten Unternehmen steigen wir typischerweise in ein bestehendes Produkt mit einem definierten Backlog, bestehender Infrastruktur und einem zu ergänzenden Team ein. Der häufigste Grund, warum ein etabliertes Unternehmen einen Product-Engineering-Pod hinzuzieht, ist die Beschleunigung einer bestimmten Produktoberfläche, während das interne Team auf Core-Platform-Arbeit fokussiert bleibt.