Game Co-Development: Leitfaden zu Modellen, Kosten, Risiken und Partnerwahl

Der Begriff "Co-Development" wird in der Spielebranche sehr locker verwendet. Studios nutzen ihn für Outsourcing-Vereinbarungen, White-Label-Produktionen und alles dazwischen. Diese Unschärfe schafft reale Probleme für jeden, der eine echte Partnerschaft strukturieren will — denn das gewählte Modell bestimmt, wer das Risiko trägt, wer wirklich etwas zu verlieren hat und ob die Anreize tatsächlich gleichgerichtet sind.

Dieser Leitfaden räumt mit der Mehrdeutigkeit auf. Wir behandeln, was Co-Development bei Spielen wirklich bedeutet, wann es sinnvoll ist (und wann nicht), die vier wichtigsten Modelle, denen Sie begegnen werden, wie Kosten und Umsatzbeteiligung üblicherweise strukturiert sind und worauf Sie bei der Bewertung eines Partners achten sollten.

Das Kernargument: Game Co-Development funktioniert, wenn beide Seiten etwas Substanzielles zum Produkt beitragen und die Verantwortung für das Ergebnis teilen. Ist diese Bedingung nicht erfüllt, arbeiten Sie mit einem Dienstleister, nicht mit einem Partner. Diese Unterscheidung zählt mehr als das Etikett, mit dem Sie die Vereinbarung beschreiben.

Inhaltsverzeichnis

1. Was ist Game Co-Development?

2. Wann ist Co-Development sinnvoll?

3. Die wichtigsten Arten von Game Co-Development

4. Burn-Rate-Übernahme + Umsatzbeteiligung: eine andere Art von Partnerschaft

5. "Ich habe eine Idee. Baut ihr sie kostenlos?"

6. Wie Sie einen Co-Development-Partner bewerten

7. Wie kalkulieren Co-Development-Partner ihre Leistungen?

8. So wählen Sie das richtige Co-Development-Modell

9. Zusammenarbeit mit Galaxy4Games

Das alte Outsourcing-Modell — Stundensätze, definierter Umfang, liefern und fertig — ergibt für bestimmte Arbeitspakete weiterhin Sinn: Art-Produktion, QA, Lokalisierung oder ein klar abgegrenztes technisches Feature. Für diese Fälle wissen Sie genau, was Sie brauchen, und ein Dienstleister, der nach Spezifikation liefert, ist das richtige Werkzeug.

Für die vollständige Spieleentwicklung ist dieses Modell jedoch zunehmend unzureichend. Ein Spiel ist kein Liefergegenstand. Es ist ein Produkt, das gelauncht, gehalten, monetarisiert und betrieben werden muss. Studios, die es wie einen Liefergegenstand behandeln — in Stunden messen, übergeben und verschwinden — lassen genau den Teil des Lebenszyklus aus, der darüber entscheidet, ob das Spiel kommerziell funktioniert.

Was ist Game Co-Development?

Was ist Game Co-Development: eine Partnerschaft, in der Kunde und Entwicklungspartner gemeinsam Ressourcen zum Bau eines Spiels beitragen. Diese Beiträge können viele Formen annehmen: Expertise, Technologie, Produktionskapazität, Kapital, IP, Marktzugang oder eine Kombination aus alldem.

Die Frage Co-Development versus Outsourcing bei Spielen läuft auf die Natur der Beziehung zwischen beiden Parteien hinaus. Es gibt aber ein Spektrum, das man verstehen sollte, denn nicht jede starke Partnerschaft ist als Umsatzbeteiligung strukturiert — und nicht jedes Outsourcing-Mandat ist rein transaktional.

Co-Development versus Outsourcing

Diese Tabelle ist wichtig, weil sie zeigt: Die eigentliche Trennlinie verläuft nicht einfach zwischen "Outsourcing und Co-Development". Sie verläuft dort, wo ein Studio in Stunden oder in Ergebnissen denkt.

Die besten Entwicklungspartner — auch solche mit einem konventionellen bezahlten Mandat — bringen eine technische Basis mit, verfolgen Ihre KPIs, denken an Ihren ROI und kümmern sich darum, was nach dem Release mit dem Spiel passiert. Diese Haltung unterscheidet einen echten Partner von einem Studio, das Ihr Projekt als Zeile in einer Auslastungstabelle behandelt.

Bei reinem stundenbasiertem Outsourcing endet der Anreiz des Studios mit der bezahlten Rechnung. Bei einem ergebnisorientierten Partner reicht der Anreiz bis zur Frage, ob das Spiel tatsächlich performt. Beim Co-Development ist diese Ausrichtung strukturell — von Anfang an in den kommerziellen Bedingungen verankert.

Entscheidende Unterscheidung: Die Frage lautet nicht nur "Outsourcing oder Co-Development?". Sie lautet, ob das Studio, mit dem Sie arbeiten, in Stunden oder in Ergebnissen denkt. Dieser Unterschied in der Haltung bestimmt alles Weitere: Entscheidungsqualität, Launch-Reife, Engagement nach dem Launch und ob sie sechs Monate nach Release noch in Ihr Spiel investiert sind.

Wann ist Co-Development sinnvoll?

Co-Development ist nicht für jedes Projekt das richtige Modell. Es funktioniert am besten in bestimmten Situationen, in denen beide Seiten echte, sich ergänzende Beiträge leisten können.

Situationen, in denen Co-Development passt

• Ein Startup mit Produktvision, aber ohne Team. Sie verstehen den Markt, haben ein validiertes Konzept und kennen Ihre Zielgruppe. Was fehlt, ist die erfahrene Entwicklungskapazität, um es zu bauen. Ein Co-Development-Partner schließt diese Lücke, während Sie die Produktrichtung vorgeben.

• Ein Indie-Studio mit IP, aber begrenzter Produktionskapazität. Sie haben ein etabliertes Konzept oder eine Marke, können die Produktion intern aber nicht skalieren. Ein Co-Development-Partner erweitert Ihre Kapazität, ohne dass Sie ein größeres festes Team aufbauen und führen müssen.

• Ein Publisher, der einen neuen Titel ohne internes Team entwickelt. Sie wollen Produkt und IP besitzen, aber kein eigenes Studio aufbauen. Co-Development gibt Ihnen einen Partner, der die volle Produktionsverantwortung übernimmt, während Sie die strategische Kontrolle behalten.

• Ein etabliertes Studio mit einer Kapazitätslücke. Ihr internes Team ist an einen laufenden Titel gebunden. Ein Co-Development-Partner übernimmt das neue Projekt als Erweiterung Ihrer Organisation, nicht als externer Auftragnehmer.

• Ein Team mit Teilfinanzierung und einem soliden Business Case. Sie haben Kapital, aber nicht genug, um die gesamte Produktion zu Marktpreisen zu finanzieren. Ein Modell mit geteiltem Risiko kann diese Lücke schließen.

• Ein Produkt, das einen Partner nach dem Launch braucht. Ihr Spiel lebt oder stirbt mit dem Betrieb. Sie brauchen jemanden, der noch da ist, wenn die Events starten — und nicht beim letzten Meilenstein verschwindet.

Wann Co-Development wahrscheinlich nicht das richtige Modell ist

Seien Sie ehrlich zu sich selbst, ob Co-Development wirklich das ist, was Sie brauchen. Wahrscheinlich nicht, wenn:

• Sie nur ein klar abgegrenztes Feature oder eine definierte Entwicklungsaufgabe mit festem Liefergegenstand brauchen.

• Sie voll finanziert sind und schlicht Produktionskapazität benötigen — klassisches Outsourcing ist sauberer und schneller aufzusetzen.

• Sie erwarten, dass der Partner das gesamte Spiel finanziert, ohne dass Sie selbst einen substanziellen Beitrag leisten.

• Sie noch kein validiertes Konzept, keinen realistischen Entwicklungsplan und keinen belastbaren Business Case haben.

Der letzte Punkt verdient Nachdruck. Ein Entwicklungspartner, der bereit ist, Produktrisiko zu tragen, wird Ihr Projekt bewerten wie ein Investor — denn in einer Risikoteilung ist er faktisch genau das. Wenn Sie den Business Case für Ihr Spiel nicht formulieren können, sind Sie nicht bereit für Co-Development. Sie sind bereit für eine Discovery-Phase.

Die wichtigsten Arten von Game Co-Development

Wie funktioniert Game Co-Development in der Praxis? Das hängt von der gewählten Struktur ab. Co-Development ist kein einzelnes Modell: Die wichtigsten Game-Co-Development-Modelle bilden eine Kategorie von Partnerschaftsstrukturen, jede passend für andere Projektprofile, Finanzierungssituationen und Teamkonstellationen. Die Unterschiede zu verstehen hilft Ihnen, die richtige Struktur zu wählen, bevor Sie zu verhandeln beginnen.

Modell 1: Full-Cycle-Co-Development

Beide Seiten bringen Ressourcen und Expertise über den gesamten Produktionszyklus ein — von Konzept und Game Design über Engineering, Art, QA, Soft Launch bis zu LiveOps.

Beiträge des Entwicklungspartners können umfassen:

• Produktmanagement und Game Design

• Engineering und technische Architektur

• Art-Produktion (2D, 3D, Animation, UI)

• Analytics-Setup und -Interpretation

• Monetarisierungsdesign und -umsetzung

• LiveOps-Infrastruktur und Event-Management

• QA und Compliance

• Publishing-Unterstützung und Plattformbeziehungen

• Marketing- und UA-Unterstützung

Dieses Modell funktioniert am besten, wenn beide Parteien während der gesamten Produktion tief eingebunden bleiben wollen. Der Kunde bringt Produktvision, Marktkenntnis und strategische Richtung. Der Partner bringt Umsetzungskapazität und technische Tiefe. Keine Seite schreibt nur Schecks oder nimmt nur Anweisungen entgegen.

Modell 2: Dediziertes Co-Development-Team

Der Entwicklungspartner stellt ein dediziertes Team, das als eingebettete Erweiterung der Kundenorganisation arbeitet. Der Kunde behält die Produktführung; der Partner liefert die Produktionskapazität.

Dieses Modell ist üblich für:

• Publisher, denen die Produktvision gehört, die aber keine internen Produktionsteams haben

• Etablierte Studios mit einer Kapazitätslücke bei einem neuen Titel

• Unternehmen mit starker Produktführung, denen aber erfahrene Umsetzungsressourcen fehlen

Der zentrale Unterschied zum Full-Cycle-Co-Development: Der Kunde trifft die Produktentscheidungen. Aufgabe des Partners ist es, mit hoher Qualität zu liefern und sich reibungslos in Arbeitsweise und Kultur des Kunden einzufügen.

Modell 3: Hybrides Co-Development

Ein Teil des Projekts ist als konventionelles bezahltes Mandat strukturiert. Ein anderer Teil führt Elemente der Risikoteilung oder anreizbasierte Komponenten ein, etwa:

• Umsatzbeteiligung ab definierten Schwellenwerten

• Meilensteinvergütung gekoppelt an die Produktperformance

• Gestundete Zahlungen, die aus künftigen Erlösen zurückgeführt werden

• Performance-Anreize gekoppelt an KPIs (DAU, ARPU, Retention-Benchmarks)

Hybride Modelle sind nützlich, wenn der Kunde über etwas Finanzierung verfügt, aber nicht genug, um die Produktion vollständig zu Marktpreisen zu tragen, und der Entwicklungspartner bereit ist, gegen Upside einen Teil des Risikos zu übernehmen. Die Struktur erfordert sorgfältige Verhandlung — insbesondere dazu, was die Umsatzbeteiligung auslöst, wie die Rückführung berechnet wird und was passiert, wenn das Produkt hinter den Erwartungen bleibt.

Modell 4: Burn-Rate-Übernahme + Umsatzbeteiligung

Dieses Modell verdient einen eigenen Abschnitt, den wir als Nächstes vertiefen. Kurzfassung: Der Entwicklungspartner übernimmt einen vereinbarten Anteil der laufenden Entwicklungskosten des Teams im Austausch für einen Prozentsatz der künftigen Erlöse oder der Produktökonomie. Es unterscheidet sich strukturell am stärksten vom konventionellen Outsourcing und erzeugt die stärkste Anreizausrichtung aller Co-Development-Modelle.

Burn-Rate-Übernahme + Umsatzbeteiligung: eine andere Art von Partnerschaft

Die Wahl eines Game-Development-Partners mit Umsatzbeteiligung ist eine andere Entscheidung als die Beauftragung eines Dienstleisters. In diesem Modell verpflichtet sich der Entwicklungspartner, einen vereinbarten Anteil der monatlichen Entwicklungs-Burn-Rate des Teams zu tragen. Im Gegenzug erhält er einen Prozentsatz der künftigen Erlöse oder der Ökonomie des Produkts — strukturiert als Umsatzbeteiligung, Unternehmensanteil oder eine Mischung aus beidem.

Das ist keine Dienstleistungsvereinbarung. Es ist eine Co-Investition.

Wie sich die Anreizstruktur verändert

Der Unterschied zum konventionellen Outsourcing ist grundlegend, nicht kosmetisch:

Wenn ein Entwicklungspartner echtes finanzielles Exposure hat, ändert sich sein Verhalten. Er denkt über Retention nach, weil schlechte Retention Erlöse zerstört. Er denkt über Monetarisierung nach, weil sie seine Rendite bestimmt. KPIs sind ihm wichtig, weil diese Zahlen direkt seine Ökonomie beeinflussen. Er ist investiert in das, was nach dem Launch passiert — nicht nur in das, was am Meilensteintermin ausgeliefert wird.

Warum dieses Modell nicht der Branchenstandard ist

Die meisten klassischen Outsourcing-Studios sind nicht darauf ausgelegt, Produktrisiko zu tragen. Ihre Ökonomie basiert auf planbaren Serviceerlösen: Auslastungsquoten, Entwicklungshonorare und Vertragsmargen. Burn-Rate-Exposure zu übernehmen heißt, reale Kosten ohne Renditegarantie zu absorbieren. Das verändert das Risikoprofil des Geschäfts erheblich, und die meisten serviceorientierten Studios sind nicht dafür aufgestellt.

Die Studios, die an diesem Modell teilnehmen können, sind typischerweise jene, die auch eigene Produkte bauen und betreiben — weil sie bereits aus der Praxis wissen, wie Produktrisiko aussieht. Sie haben die finanzielle Infrastruktur, um Exposure zu tragen, die operative Erfahrung, um zu beurteilen, welche Projekte das Risiko wert sind, und das Produktwissen, um die kommerzielle Performance des Spiels tatsächlich zu verbessern.

Bei Galaxy4Games können wir uns an Burn-Rate-Vereinbarungen beteiligen, weil wir nicht ausschließlich ein Dienstleistungsgeschäft sind. Wir bauen und betreiben eigene Live-Titel im App Store und bei Google Play. Das heißt, wir verstehen die Produktseite der Gleichung ebenso wie die Produktionsseite — und wir wissen aus direkter Praxis, was es braucht, um ein Spiel in einem echten Markt zu launchen, zu halten und zu monetarisieren.

Wir arbeiten mit ausgewählten Kunden nach diesem Modell. Die Einstiegshürde ist hoch — wir bewerten diese Partnerschaften so, wie wir unsere eigenen Produkte bewerten würden — aber für das richtige Projekt ist es die am stärksten ausgerichtete Struktur, die wir anbieten können.

Der eigentliche Test für Ausrichtung: Fragen Sie Ihren potenziellen Co-Development-Partner, was mit seinem Geschäft passiert, wenn Ihr Spiel hinter den Erwartungen bleibt. Lautet die ehrliche Antwort "nichts, wir wurden bereits bezahlt", ist das Outsourcing. Beinhaltet die Antwort reales finanzielles Exposure auf seiner Seite, haben Sie echte Ausrichtung.

"Ich habe eine Idee. Baut ihr sie kostenlos?"

Das ist das häufigste Missverständnis über Co-Development, und es lohnt sich, es direkt anzusprechen.

Der Vorschlag klingt meist so: "Ich habe eine großartige Spielidee. Ihr entwickelt sie auf eure Kosten, und ich kümmere mich um Marketing, Investorenkontakte, Publisher-Beziehungen oder Reichweite." Die implizite Forderung ist, dass der Entwicklungspartner sämtliche Produktionskosten und -risiken im Austausch gegen ein Versprechen künftigen Werts übernimmt.

Das ist kein Co-Development.

Das Problem ist nicht, dass nicht-monetäre Beiträge wertlos wären. Manche sind wirklich wertvoll und können die Grundlage einer echten Partnerschaft bilden. Die Frage ist, ob der Beitrag konkret, messbar und proportional zu dem Risiko ist, das vom Entwicklungspartner verlangt wird.

Was als substanzieller Beitrag zählt

Das Muster ist eindeutig: Beiträge, die bereits real sind — bestehende Zielgruppen, unterzeichnete Verträge, gesichertes Kapital, erprobte Kanäle — können eine Co-Development-Partnerschaft tragen. Beiträge, die von künftigen Ereignissen abhängen oder vollständig davon, dass die Arbeit des Entwicklungspartners zuerst erfolgreich ist, verschieben das Risiko nur in eine Richtung.

Ein Entwicklungspartner, der Burn-Rate-Exposure übernimmt, geht eine echte finanzielle Wette ein. Er muss auf der anderen Seite einen echten Beitrag sehen. Das ist keine Verhandlungsposition, sondern die Grundlogik dessen, was eine Partnerschaft zur Partnerschaft macht statt zu einer Bitte um kostenlose Entwicklung.

Wenn Ihr aktueller Beitrag eine Idee und eine Vision ist: Das ist ein Ausgangspunkt, keine Partnerschaft. Validieren Sie das Konzept, bauen Sie einen Business Case, sichern Sie sich eine Form von Zusage — von einem Publisher, einer Plattform, Investoren oder einer bestehenden Zielgruppe — und gehen Sie dann auf einen Co-Development-Partner zu. Sie werden ein deutlich stärkeres Gespräch führen. Wenn Sie in der Konzeptphase sind, ist zu verstehen, was ein Game-MVP tatsächlich erfordert, der richtige Startpunkt, bevor Sie einen Entwicklungspartner ansprechen.

Wie Sie einen Co-Development-Partner bewerten

Wie Sie einen Game-Co-Development-Partner auswählen, ist nicht dieselbe Frage wie die Wahl eines Outsourcing-Dienstleisters. Sie bewerten nicht nur Produktionsfähigkeit, sondern ob diese Organisation als echter Partner beim Aufbau eines kommerziellen Produkts funktionieren kann.

Worauf Sie achten sollten

Produkterfahrung, nicht nur Projekterfahrung. Hat das Studio Spiele veröffentlicht, die live gingen und live blieben? Verstehen sie, was nach dem Launch passiert — Retention-Kurven, LiveOps-Zyklen, Plattform-Compliance-Updates, Monetarisierungsoptimierung? Studios, die nur Projekte abliefern und übergeben, haben einen grundlegend anderen Bezugsrahmen als Studios, die Produkte betreiben.

Veröffentlichte Spiele und Live-Titel. Fragen Sie nach konkreten Titeln. Suchen Sie sie im App Store und bei Google Play. Prüfen Sie, ob das Studio einen eigenen Entwickler-Account mit veröffentlichten Spielen hat oder nur unter Kunden-Accounts liefert. Ein Studio, das eigene Live-Titel betreibt, hat direkte Erfahrung mit allem, was nach dem Launch kommt.

Technische Basis und eigene Systeme. Bringt der Partner etwas über Entwicklungsstunden hinaus mit? Das ist eines der klarsten Signale für einen echten Partner gegenüber einem Dienstleister. Eigene Tools, produktionsreife Frameworks, wiederverwendbare Komponenten und LiveOps-Infrastruktur sind konkrete Beiträge, die Entwicklungszeit verkürzen, technisches Risiko senken und Ihre Gesamtkosten reduzieren. Ein Studio, das auf einer erprobten Basis aufbaut, startet bei Ihrem Projekt nicht bei null. Das hat reale ROI-Folgen: weniger Zeit für Grundgerüst bedeutet mehr Zeit für die Features, die tatsächlich Retention und Umsatz treiben.

ROI- und KPI-Orientierung. Ein starker Partner fragt nicht nur, was Sie bauen wollen. Er fragt, wie Erfolg in messbaren Größen aussieht. Was sind Ihre Ziel-KPIs? Wie muss Ihre Retention-Kurve an Tag 1, 7 und 30 aussehen? Welchen ARPU brauchen Sie, um Ihre UA-Ausgaben zu rechtfertigen? Ein Studio, das auf diesem Niveau mitreden kann — und Ihnen hilft, Ihr Spiel von Tag eins an für diese Metriken zu instrumentieren — agiert als Geschäftspartner, nicht als Feature-Fabrik. Fragen Sie direkt: Wie helfen Sie Kunden, die Spielperformance nach dem Launch zu messen und zu verbessern? Eine detaillierte Aufschlüsselung der KPIs je Phase finden Sie in unserem vollständigen Leitfaden zu Launch und Skalierung.

Seniorität des Teams und Beitrag über das Programmieren hinaus. Ein starker Co-Development-Partner trägt zu Produktentscheidungen bei, nicht nur zur technischen Umsetzung. Suchen Sie Partner, die über Monetarisierungsdesign, Analytics-Instrumentierung, Genre-Benchmarks und Retention-Mechaniken sprechen können — nicht nur über Sprint-Geschwindigkeit und Bug-Zahlen.

Bereitschaft, Risiko zu teilen. Ist ein Partner bereit, Burn-Rate-Exposure oder Umsatzbeteiligungen zu übernehmen, fragen Sie ihn, wie er Projekte für dieses Modell bewertet. Seine Antwort sagt viel über sein Produkturteil und sein tatsächliches Verständnis kommerzieller Spieleentwicklung. Aber: Die Bereitschaft, Risiko zu teilen, ist auch dann ein starkes Signal, wenn die kommerzielle Struktur konventionell ist. Ein Studio, das ernsthaft über die kommerzielle Entwicklung Ihres Produkts nachdenkt — unabhängig davon, wie es bezahlt wird — ist der bessere Partner.

Kommerzielles Modell und IP-Bedingungen. Verstehen Sie genau, wie IP-Eigentum, Umsatzbeteiligung, Rückführung und Ausstiegsbedingungen strukturiert sind, bevor Sie etwas unterschreiben. Diese Konditionen unterscheiden sich stark zwischen Partnern und Modelltypen, und Unklarheit hier schafft später Probleme.

Der Test: Stunden oder Ergebnisse

Eine praktische Methode, jeden potenziellen Partner zu prüfen: Fragen Sie ihn, was mit seinem Geschäft passiert, wenn Ihr Spiel nach dem Launch hinter den Erwartungen bleibt.

Ein Studio, das in Stunden misst, wird Ihnen ehrlich sagen, dass es das nicht betrifft — es wurde bereits bezahlt. Ein Studio, das in Ergebnissen denkt, wird sagen, dass es ihm wichtig ist, und erklären, wie es das Problem angehen würde. Ein Studio mit echtem finanziellem Exposure wird Ihnen genau sagen, was für sie auf dem Spiel steht und warum sie die Partnerschaft so strukturiert haben, dass dieser Fall vermieden wird.

Keine dieser Antworten ist automatisch falsch. Aber sie sagen Ihnen genau, auf welche Art von Beziehung Sie sich einlassen.

Bewerten Sie einen Co-Development-Partner nicht primär nach Stundensätzen. Satzvergleiche sind bei Commodity-Dienstleistern sinnvoll. Bei ergebnisorientierten Partnern lautet die relevante Frage, was sie zum Produkt beitragen — ihre technische Basis, ihr KPI-Denken, ihr Engagement nach dem Launch — und wie ihre Anreize mit Ihren übereinstimmen. Ein Partner mit höheren Sätzen, aber erprobter eigener Basis, echter ROI-Orientierung und ernsthaftem Engagement nach dem Launch ist ein grundlegend anderes Angebot als ein günstigeres Studio, das Stunden verkauft. Einen breiteren Vergleich, wie sich Studios in diesen Dimensionen unterscheiden, finden Sie in unserem Leitfaden zu den besten Spieleentwicklungsunternehmen 2026.

Wie kalkulieren Game-Co-Development-Partner ihre Leistungen?

Co-Development-Vereinbarungen nutzen je nach Modell, Projekt und Risikoprofil beider Seiten unterschiedliche kommerzielle Strukturen. Wie sich Produktionskosten nach Umfang, Genre und Plattform aufschlüsseln, zeigt unser vollständiger Leitfaden zu Spieleentwicklungskosten.

Gängige Kostenstrukturen

Festes Entwicklungshonorar. Ein definierter Preis für einen definierten Umfang. Üblich im Outsourcing und im bezahlten Teil hybrider Modelle. Bietet Budgetsicherheit, schafft aber keine Anreizausrichtung.

Monatliche Burn Rate. Der Kunde zahlt einen festen Monatsbetrag, der die Kosten des dedizierten Teams deckt. Üblich bei dedizierten Teams. Für beide Seiten planbar, aber der Anreiz des Studios bleibt lieferorientiert statt ergebnisorientiert.

Meilensteinzahlungen. Zahlungen gekoppelt an konkrete Produktionsmeilensteine (Alpha, Beta, Soft Launch, globaler Launch). Schafft Kontrollpunkte und senkt das Zahlungsrisiko für den Kunden, richtet die Anreize aber nicht per se an der kommerziellen Performance aus.

Burn-Rate-Übernahme durch den Partner. Der Entwicklungspartner absorbiert einen Teil oder alle monatlichen Teamkosten, typischerweise im Austausch gegen Umsatzbeteiligung oder Anteile. Das ist das oben beschriebene Burn-Rate-Modell — die strukturell am stärksten ausgerichtete verfügbare Vereinbarung.

Gestundete Zahlungen. Ein Teil oder das gesamte Entwicklungshonorar wird gestundet und aus künftigen Erlösen zurückgeführt, bevor die Umsatzbeteiligung beginnt. Reduziert den Liquiditätsbedarf zu Beginn, ohne dass der Partner das Kostenrisiko vollständig trägt.

Umsatzbeteiligung. Der Entwicklungspartner erhält einen Prozentsatz der Netto- oder Bruttoerlöse des Produkts, entweder ab Launch oder nach Erreichen einer Rückführungsschwelle. Die Konditionen variieren stark — Prozentsatz, Erlösbasis (netto oder brutto, Plattformgebühren bereits abgezogen oder nicht), Laufzeit sowie etwaige Deckelungen oder Rückkaufklauseln müssen ausdrücklich verhandelt werden.

Hybride Strukturen. Die meisten realen Co-Development-Vereinbarungen kombinieren Elemente des Obigen. Eine gängige Struktur: Der Kunde zahlt eine reduzierte Monatsrate, die einen Teil der Burn Rate deckt, der Partner trägt den Rest, und beide Seiten teilen die Erlöse nach einer definierten Rückführungsschwelle.

Investment plus Entwicklung. In manchen Vereinbarungen übernimmt der Entwicklungspartner statt (oder zusätzlich zu) einer Umsatzbeteiligung eine Beteiligung am Produkt oder an der Projektgesellschaft. Das ist komplexer zu strukturieren und erfordert meist einen formelleren rechtlichen Rahmen, kann aber für größere Projekte mit erheblichem Potenzial das richtige Modell sein.

Was Sie vor der Unterschrift festzurren sollten

Welche Struktur Sie auch vereinbaren: Stellen Sie sicher, dass die folgenden Punkte im Vertrag ausdrücklich definiert sind:

• Erlösbasis: Was zählt als Erlös (brutto, netto, nach Plattformgebühren, nach UA-Ausgaben)?

• Rückführung: Muss der Partner seinen Kostenbeitrag zurückführen, bevor die Umsatzbeteiligung beginnt?

• Laufzeit: Läuft die Umsatzbeteiligung unbefristet oder gibt es eine Deckelung oder Endklausel?

• Prüfrechte: Können beide Seiten die Erlöszahlen überprüfen, auf denen die Beteiligung beruht?

• IP-Eigentum: Wem gehören Spiel, Code, Art und die zugrunde liegende Technologie?

• Ausstiegsbedingungen: Was passiert, wenn die Partnerschaft vor dem Launch endet?

Unklarheit in einem dieser Punkte erzeugt Streit. Klären Sie sie schriftlich, bevor die Produktion beginnt.

So wählen Sie das richtige Co-Development-Modell

Nutzen Sie diesen Rahmen, um Ihre Situation der passenden Struktur zuzuordnen.

Ein paar zusätzliche Überlegungen, die Sie im Blick behalten sollten:

• Wählen Sie nicht automatisch das günstigste Modell. Die kostengünstigste Struktur ist oft die mit der geringsten Ausrichtung. Wenn Sie einen Partner wollen, dem die Performance Ihres Spiels wichtig ist, muss dieser Partner etwas zu verlieren haben.

• Passen Sie das Modell an Ihre Phase an. Frühphasenprojekte mit unerprobten Konzepten brauchen andere Strukturen als Projekte mit validiertem Design und klarem Weg in den Markt.

• Seien Sie ehrlich über Ihren Beitrag. Welches Modell Ihnen offensteht, hängt direkt davon ab, was Sie einbringen. Ein solider Business Case, eine bestehende Zielgruppe oder gesicherte Finanzierung öffnen Türen, die eine unvalidierte Idee nicht öffnet.

• Planen Sie die Zeit nach dem Launch. Welches Modell Sie auch wählen: Stellen Sie sicher, dass es abdeckt, was nach dem Release passiert. Eine Co-Development-Vereinbarung, die zum Launch endet, lässt genau den Teil des Lebenszyklus aus, der über den Erfolg entscheidet.

Zusammenarbeit mit Galaxy4Games

Galaxy4Games ist ein Boutique-Studio für Full-Cycle-Spieleentwicklung mit 40 erfahrenen Spezialisten. Wir haben über 15 Jahre Spiele in allen wichtigen Genres gebaut — Casual Puzzles, Match-3, Lerntitel, Mid-Core, MMORPGs und RPGs — und sind lange genug im Markt geblieben, um eigene Live-Titel im App Store und bei Google Play zu launchen und zu betreiben.

Diese Kombination ist gerade für Co-Development entscheidend. Wir verstehen die Produktseite der Spieleentwicklung, weil wir sie leben, nicht weil wir darüber gelesen haben. Wenn wir eine Co-Development-Gelegenheit bewerten, legen wir dieselbe Brille an wie bei unseren eigenen Produkten: Ist das Konzept tragfähig, ist der Business Case glaubwürdig, kann das Team liefern, und gibt es einen realistischen Weg zu kommerzieller Performance?

Was wir in jedes Projekt einbringen

Drei eigene Systeme tragen alles, was wir bauen:

• Game Application Template. Eine strukturierte Entwicklungsbasis mit Kernarchitektur, Plattformintegrationen, Store-Compliance und Analytics-Hooks. Das Grundgerüst, das üblicherweise die ersten Monate eines Projekts verschlingt, ist bereits gebaut und getestet. Jedes Kundenprojekt startet auf dieser Basis — Entwicklungszeit und Budget fließen also in Ihr Spiel und nicht in den Neubau bereits vorhandener Infrastruktur.

• Modular Solutions Library. Produktionsreife Spiel-Features und -Mechaniken, gebaut und in unseren eigenen Live-Produkten erprobt: UI-Systeme, Event-Engines, Monetarisierungsmodule, Progressions-Frameworks, LiveOps-Event-Tools. Jede Komponente hat sich in einer Live-Umgebung bewährt, bevor sie ein Kundenprojekt berührt. Sie zahlen nicht dafür, dass wir herausfinden, wie man ein Monetarisierungssystem baut: Sie bekommen eines, das bereits funktioniert.

• LiveOps-Framework. Eine Architektur, die von Tag eins an fortlaufende Content-Updates, In-Game-Events, Analytics-Integration und langfristige Spielerbindung trägt. Spiele auf dieser Basis sind ab dem Launch betriebsbereit — nicht nachträglich umgerüstet. Das zählt für Ihre KPIs: Retention, ARPU und Session-Frequenz hängen von einer operativen Infrastruktur ab, die die meisten Studios erst nachträglich anflanschen.

Zusammen verkürzen diese Systeme Entwicklungszeit und -kosten um 30-50 % gegenüber einem Start auf weißem Blatt. Das ist der ROI-Fall für die technische Basis. Wichtiger ist aber, was sie darüber aussagt, wie wir arbeiten.

Wir denken in Ergebnissen, nicht in Stunden

Wir verfolgen Ihre KPIs, weil uns wichtig ist, was nach dem Release mit dem Spiel passiert. Wir instrumentieren Analytics ab Tag eins, weil Entscheidungen nach dem Launch Daten brauchen, keine Vermutungen. Wir denken während der Produktion über Ihr Monetarisierungsdesign nach, weil eine nachträgliche Umrüstung teuer und meist wirkungslos ist. Wir bleiben über LiveOps engagiert, weil dort Retention tatsächlich entsteht.

Das ist kein Verkaufsargument. So arbeiten wir — weil wir eigene Live-Spiele betreiben und wissen, was die Zeit nach dem Launch wirklich verlangt. Studios, die in Stunden messen, hören in dem Moment auf, an Ihr Spiel zu denken, in dem der letzte Meilenstein abgerechnet ist. Wir arbeiten nicht so.

Wenn Sie eine Co-Development-Partnerschaft prüfen — ob als Full-Cycle-Mandat, dediziertes Team oder Modell mit geteiltem Risiko — nehmen Sie Kontakt mit uns auf. Wir sagen Ihnen direkt, ob Ihr Projekt passt, welches Modell sinnvoll ist und wie eine Partnerschaft in der Praxis aussähe.

Weiterführende Artikel

Falls dieser Leitfaden Fragen zu angrenzenden Themen aufgeworfen hat, gehen diese Beiträge bei den für Co-Development-Entscheidungen relevantesten Punkten in die Tiefe:

• Was kostet die Entwicklung eines Mobile Games 2026? — Eine Aufschlüsselung der Faktoren, die Entwicklungskosten treiben, nützlich, um einzuschätzen, was ein Co-Development-Modell abdecken muss.

• Launch und Skalierung: die vollständige Roadmap für Mobile- und PC-Studios — Das dreiphasige Launch-Framework: KPI-Validierung im Soft Launch, Infrastruktur für den globalen Launch und LiveOps-Betrieb nach dem Launch.

• Was ist ein Game-MVP? Warum es strategisch klug ist, klein zu starten — Wie Sie Ihr Konzept validieren, bevor Sie sich auf die volle Produktion festlegen, und was ein produktionsreifes MVP wirklich erfordert.

• Was umfasst Full-Cycle-Spieleentwicklung eigentlich? — Eine Aufschlüsselung jeder Phase vom Konzept bis zu LiveOps und was Sie von einem Full-Cycle-Partner in jedem Schritt erwarten können.

• Die besten Spieleentwicklungsunternehmen 2026 — Ein Vergleichsleitfaden zur Bewertung von Studios nach Kooperationsmodell, Genre-Erfahrung und Post-Launch-Fähigkeit.

• Welche Studios sind stark im datengetriebenen Game Design? — Wie die besten Studios Analytics, A/B-Tests und LiveOps-Daten nutzen, um die Produktperformance zu verbessern, und wie das in der Praxis aussieht.