What Is Game Co-Development and How Does It Differ from Pure Outsourcing

Game co-development is not outsourcing with a better pitch deck. The distinction is operational, contractual, and structural — and confusing the two models is one of the more expensive mistakes a vendor manager can make when scoping an external engagement for a mid-core or AAA production.

Both models use external studios. Both involve contracts, milestones, and art or engineering deliverables. The difference is in what the external team is optimizing for. In structured outsourcing, the partner optimizes for delivery against a defined spec. In co-development, the partner optimizes for the game — which means they carry shared accountability for whether the output is right, not just whether it was delivered.

That accountability shift changes everything downstream: how the SOW is written, how IP ownership is structured, how long onboarding takes, how sprint cycles are managed, and what “a revision” means contractually.

If you are a vendor manager or head of outsource production at a mid-core or AAA studio, this guide covers the operational layer that most co-development marketing materials skip entirely.

About the author: Denys Zadoienyi is the founder of Nasty Rodent, a game art outsourcing studio based in Tallinn, Estonia. His team has delivered environment art, concept art, and production support for titles including Squad, Ready Or Not, Starship Troopers: Extermination, Miasma Chronicles, and La Quimera across both outsourcing and co-development engagements.

How game co-development differs from pure outsourcing — at the operational level

In a structured outsourcing engagement, the relationship between internal studio and external vendor is transactional at its core. The internal team defines what is needed — asset list, technical requirements, style guide, reference pack — and the external vendor produces it. The vendor’s success is measured by whether the deliverables match the spec. Their responsibility ends at the delivery boundary.

Co-development changes that boundary. The external team is integrated into the production pipeline itself — sharing sprint cadences, production reviews, and in many cases creative decision-making loops. They are not executing a document. They are participating in the process that produces the document.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

The operational difference is most visible in three places.

Communication structure. In outsourcing, communication happens at milestone gates — submission, review, feedback, revision. In co-development, communication is continuous, tied to sprint cadences that typically run one to three weeks. The external team participates in standup-equivalent syncs, accesses shared project management tools, and raises issues as they arise rather than at delivery. This is not a cultural preference — it is a structural requirement. A co-development partner who communicates only at milestone delivery is not operating as a co-development partner, regardless of what the contract says.

Accountability scope. A structured outsourcing vendor is accountable for the spec. If the spec changes, the SOW changes and the invoice adjusts. A co-development partner is accountable for the outcome — which means they are expected to flag when the spec is wrong, when upstream changes have made the current asset list outdated, or when a design decision will create downstream integration problems. This is the craft judgment dimension that outsourcing contracts do not purchase and co-development contracts must explicitly enable.

Decision-making participation. In outsourcing, production decisions are made internally and handed to the vendor as requirements. In co-development, the external team participates in a defined subset of those decisions — typically related to their discipline area. An art co-development partner might have standing input at creative reviews, not just at asset delivery. This changes the relationship from vendor to something closer to a remote studio division.

None of this is inherently better or worse than structured outsourcing. It is different — and requires different management infrastructure, different contract terms, and a different vendor onboarding investment.

What co-development changes in your SOW, MSA, and IP structure

The contractual difference between co-development and outsourcing is not a minor variation in payment terms. It affects how work is scoped, who owns what, and what happens when the engagement ends.

Statement of Work (SOW) structure. A structured outsourcing SOW is typically asset-list-based or milestone-based. It defines deliverables explicitly: X environment assets at Y fidelity by Z date, reviewed against the style guide. Acceptance criteria are objective and auditable.

A co-development SOW is more complex. Because the external team is participating in evolving production decisions, the scope cannot be fully fixed at contract signature. Co-development SOWs typically use time-and-materials or dedicated-team structures, with sprint-level planning documents defining the current sprint scope rather than a single upfront asset list. This is appropriate when production scope evolves — and it is a management overhead commitment that a fixed-scope SOW does not require.

The practical implication for a vendor manager: a co-development SOW requires active sprint governance on your side. Someone in your studio needs to own the week-to-week coordination with the external team. In outsourcing, the vendor manages their own production schedule against the spec. In co-development, you are co-managing the production schedule with them.

IP ownership. This is the most legally consequential difference between the two models, and the one most frequently handled poorly in early co-development negotiations.

In a standard outsourcing engagement, IP transfer is straightforward: the client owns everything the vendor produces, and the IP transfer clause in the MSA reflects that. The vendor retains rights to their pre-existing tools and internal processes; all created assets are client-owned on delivery.

In co-development, the IP picture is more complicated. The external team is contributing to creative and technical decisions, not just executing them. If they develop a custom pipeline tool to service your project, who owns it? If they contribute to the game design system that governs how environment assets are structured, are they contributing to the IP? If a co-development engagement ends mid-production, what happens to the shared repository, the build environment, and the production documentation the external team helped create?

These questions need explicit answers in the MSA before co-development starts. The standard IP transfer clauses in outsourcing templates do not cover them adequately. Specifically, a co-development MSA should address: the treatment of pre-existing IP each party brings to the engagement, the ownership of custom tools or workflows developed specifically for the project during the engagement, the scope of IP transfer for creative contributions versus execution contributions, and the data access and version control handoff protocol if the engagement terminates early.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

Exit provisions. Structured outsourcing ends when the deliverables are accepted. Co-development ends when the engagement terminates — which, for long-running AAA projects, may be months after the last milestone delivery and before the game ships. Exit clauses in co-development contracts need to specify: notice period (typically 30–90 days, longer than standard outsourcing), knowledge transfer obligations, repository access handoff, and personnel continuity provisions if key co-development team members are replaced during the notice period.

An exit clause that works for outsourcing will not work for co-development. A vendor manager discovering this mid-production is not in a good position.

The vendor onboarding gap: why co-development costs more to start

Every co-development engagement begins with a longer, more expensive onboarding than the equivalent outsourcing engagement. This is not a vendor inefficiency — it is a structural property of the model that should be in the budget from day one.

In structured outsourcing, onboarding is primarily administrative and technical: NDAs, access credentials, style guide delivery, reference pack transfer, a kickoff call. For a competent vendor with relevant portfolio experience, the production team can begin first deliverables within one to two weeks of contract signature.

Co-development onboarding is categorically different. The external team needs to understand not just what the game looks like but how your studio makes decisions. They need to be integrated into your project management tooling, your version control system, your review cadence, and your communication protocols. They need to understand the current state of production — what has already been decided, what is still in flux, and who internally has authority over which decision domains. Sprint 0 — the setup sprint before production begins — commonly ranges from several weeks to over a month depending on project complexity, team size, and how deeply the external team needs to be integrated into existing tooling and review processes.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

The onboarding delta has two practical consequences.

Time-to-first-delivery is longer. A vendor manager who scopes a co-development engagement expecting first-milestone deliverables in week three will be wrong. The production schedule needs to account for Sprint 0 as a genuine phase with its own resource requirements, not as administrative overhead to be done in parallel with production.

The cost of a failed engagement is higher. If co-development onboarding completes and the external team does not perform as expected, switching vendors means restarting the onboarding cycle from zero — with a different partner, while the production timeline continues running. Replacing a co-development partner in the middle of a project carries significantly more cost and disruption than replacing an outsourcing vendor, because the co-development partner has become embedded in the production process in ways that are hard to cleanly hand off.

This is not an argument against co-development. It is an argument for a paid trial sprint before committing to a full co-development engagement. A two-to-three-week paid discovery phase — real project work, not a portfolio exercise — gives you meaningful signal about whether the partner’s communication style, decision-making accountability, and sprint integration behavior will work at full production scale. It is the most efficient risk mitigation available before MSA signature.

Did you know that…?

The term “co-development” in the game industry predates the modern outsourcing ecosystem by several decades. Nintendo’s partnership with Rare in the early 1990s — covering Donkey Kong Country, GoldenEye 007, and Banjo-Kazooie — is one of the most frequently cited early examples of what would now be called a co-development model: an external studio integrated into first-party production pipelines with shared creative accountability, not simply contracted to deliver a product. The model existed before the industry had formal language for it; the current terminology arrived as the outsourcing market matured and studios needed to distinguish integrated partnerships from transactional vendor relationships.

When outsourcing outperforms co-development — and when it doesn’t

Co-development is not the right model for every production need. A vendor manager who defaults to co-development for all external engagements will create management overhead that costs more than it saves. The model choice should follow the production requirement, not the other way around.

Structured outsourcing is the correct model when:

The spec is stable. If you can write a complete asset list today and it is not going to change materially before delivery, structured outsourcing is faster, cheaper, and easier to manage than co-development. The external vendor needs a clear target; if that target exists, there is no benefit to integrating them into the decision-making process that produced it.

The work is discipline-isolated. Environment props, weapon meshes, background character variants, localization textures — these are categories of work with low interdependency on other production systems. An outsource vendor working against a well-defined technical spec for isolated deliverables does not need to participate in sprint reviews for systems they are not affecting.

The production stage is late. In the final months before certification, the production pipeline is typically locked. Creative decisions are not in flux. An external team brought in during this stage to handle polish pass volume, QA support, or platform-specific optimization is executing against a fixed target. Co-development governance at this stage adds process overhead without adding value.

You need geographic or timezone specialization. Bringing in a vendor for a specific window of a production cycle — to cover a timezone that provides near-24-hour coverage during crunch, or to handle a specific asset category where a region has competitive expertise — is a structured, time-bounded engagement. That structure is easier to manage as outsourcing than as co-development.

Co-development is the correct model when:

Creative direction is still evolving. If art direction, gameplay systems, or level design are in active development, an outsource team working against a fixed spec will generate rework every time the upstream decisions change. A co-development partner participates in the evolution and adjusts their work accordingly — reducing the rework cycle that is otherwise paid for in revision rounds.

The external team’s craft judgment matters. Some production problems require more than execution capability. If you are building a system — an environment set, a character pipeline, a UI design language — where the quality of the output depends on the external team understanding why the requirements are what they are, co-development provides the context that outsourcing does not.

The engagement will run for multiple production stages. A co-development partner who has been integrated since vertical slice understands the project’s history, the decisions that were made and why, and the system interdependencies that are not visible in any single deliverable. This accumulated context compounds over time. For a 12–18 month production engagement, the management overhead of co-development is amortized over a long runway.

You are running live service content. Live-service games require continuous parallel development — new content produced while existing content is in-game. The external team needs to understand the current game state, the live economy, the content calendar, and the production priorities that are visible only from inside the pipeline. This is co-development by operational necessity.

The hybrid model: running co-development and outsourcing in parallel

Most mid-core and AAA productions do not make a binary choice between co-development and outsourcing. They run both models simultaneously on different parts of the production.

The typical hybrid structure segments by integration depth. Core systems — level design, animation rigging, UI architecture, technical art — are handled by co-development partners integrated into sprint cycles and creative reviews. Asset production at volume — environment props, texture batches, background characters, UI icon sets — is handled by structured outsourcing vendors working against locked specs and milestone-based SOWs.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

This segmentation is not arbitrary. It maps directly to where integration depth adds value versus where it adds overhead.

For a vendor manager, the hybrid model creates a two-tier vendor management structure. Co-development partners require active governance: sprint planning participation, regular sync cadences, joint review sessions, and ongoing communication about production changes. Structured outsourcing vendors require delivery governance: milestone tracking, acceptance criteria checking, revision cycle management, and batch quality audits.

Mixing governance models — applying co-development process overhead to outsourcing vendors, or expecting co-development levels of accountability from outsourcing vendors — is where hybrid productions most commonly break down.

The key discipline is assignment clarity. Every external team in the production should have a documented engagement type (co-development or outsourcing), with governance protocols that match that type. A vendor who does not know whether they are expected to participate in sprint reviews or simply deliver to a milestone is a vendor who will either under-participate (missing the integration that co-development requires) or over-participate (creating communication overhead that structured outsourcing does not need).

The same logic applies to environment art production partnerships and concept art production partnerships specifically: the question of whether an external art team is brought in as a co-development partner or a structured outsourcer determines what the brief looks like, how reviews are structured, and how revisions are governed.

Technical matrix: co-development vs outsourcing by production stage and criteria

Dimension	Structured Outsourcing	Game Co-Development
SOW type	Asset-list or milestone-based; fixed scope	Time-and-materials or dedicated team; sprint-defined scope
IP ownership	Full transfer to client on delivery; clean	Requires explicit zoning: client-owned deliverables, vendor pre-existing IP, and project-specific tools or workflows whose ownership must be defined upfront
Onboarding duration	1–2 weeks (administrative + technical)	Commonly ranges from several weeks to over a month depending on production complexity; large-scale AAA engagements can run longer
Communication cadence	Milestone gates (submission → review → feedback)	Continuous: sprint syncs, shared tools, review participation
Revision accountability	Vendor revises to spec; client bears scope change cost	Partner flags spec problems; shared accountability for outcome
Exit complexity	Clean: deliverables accepted, engagement closes	Complex: notice period 30–90 days, knowledge transfer, repo handoff
Management overhead	Lower; vendor manages own production against spec	Higher; requires active sprint governance from client side
Ideal production stage	Late production, polish pass, locked spec	Pre-production through full production, evolving systems
Ideal scope type	Isolated, discipline-specific, high volume	Cross-discipline, interdependent, creatively evolving
Cost profile	Predictable per-asset or per-milestone	Higher initial (onboarding) + ongoing blended rate; lower rework cost over time
Vendor switch cost	Moderate; new vendor re-onboards to spec	High; replacement requires full Sprint 0 restart

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

How to evaluate whether a studio is genuinely built for co-development

Not every studio that markets co-development services is actually structured to deliver it. The operational requirements of co-development — sprint integration, continuous communication, shared accountability, IP zone management — require specific infrastructure and organizational behavior that service pages do not reveal.

When evaluating a potential co-development partner, the questions that reveal genuine readiness are not about portfolio quality. They are about process.

Sprint governance. Ask: how do you handle a sprint where the client’s internal team changes the direction mid-cycle? A co-development partner with real sprint experience will describe a specific process — a change request protocol, a scope adjustment mechanism, a communication escalation path. A vendor rebranding outsourcing services as co-development will describe their revision process, which is a different thing.

Single point of failure risk. Ask: who from your team leads this engagement, and what happens to production continuity if that person is unavailable for two weeks? A co-development partner should have an answer that involves team structure and documented processes — not a single senior lead whose presence is the entire continuity plan. As the vendor manager’s framing goes: when the vendor lead goes on leave at the third milestone, what happens? If there is no answer, you have found a single point of failure before the contract is signed.

IP zone readiness. Ask: what is your standard protocol for separating pre-existing tools and processes from client-owned deliverables in a co-development engagement? If they do not have a standard protocol — if this question has not been answered before — you are looking at a vendor who has not operationalized co-development at the contract level.

Communication infrastructure. Ask to see the tooling stack they use for embedded co-development clients. A partner integrated into real co-development engagements will have a clear answer: specific project management tools, shared repository access protocols, communication SLA documentation. A vendor without this infrastructure is selling integration without the operational foundation for it.

The paid trial criterion. Regardless of how strong the answers to the above are, the most reliable signal is a paid trial sprint on real project work. Two to three weeks of actual production, evaluated not just on output quality but on how the team communicates mid-sprint, how they handle ambiguity, and whether their accountability behavior matches what was described in the sales conversation. First-pass approval rate on a trial sprint is far more informative than any portfolio review.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”

As Game Developer explored in a recent discussion with co-development studio leaders, co-development’s role as a structural production strategy — rather than a tactical vendor arrangement — hinges on whether the external team is genuinely integrated into the production process or simply operating behind a co-development label. The distinction shows up in behavior, not in pitch decks.

About Nasty Rodent

Most mid-core and AAA productions run a combination of co-development and structured outsourcing rather than relying on a single model throughout. Some systems require tightly integrated co-development teams working inside sprint cycles and production reviews, while others are better served through milestone-based delivery against a locked spec. At Nasty Rodent, we support both approaches depending on project requirements, production stage, and ownership expectations. Whether a studio needs an embedded art team or a dedicated external production stream, the goal remains the same: predictable delivery, clear communication, and assets that integrate without friction.

Our clients include Offworld Industries, The Bearded Ladies Consulting, Reburn, Whimsy Games, Galaxy 4 Games, and Benner Games. If you are deciding between co-development and structured outsourcing for your next production phase — or need a partner who can operate in either model — get in touch.

For studios evaluating the co-development vs outsourcing decision specifically in UX/UI production, the mechanics differ in important ways from art-focused engagements — covered in depth in our piece on the UI/UX co-development model.