Choosing a European game co-development partner: scope, ownership and evidence

The question behind the shortlist

Most producers do not struggle to find game co-development studios; they struggle to compare them. Every partner has a portfolio and a confident sales call. What is harder to see is who will own which part of the game, how that work will reach your build, and what happens when the plan changes.

This guide is written for producers, publishers and studio heads who are comparing external partners for a game production. It works the same way whether you end up hiring Sourcegarden Studio, another European studio or a team on a different continent. The goal is a decision you can defend: one based on scope, ownership and evidence rather than on the most polished pitch.

At the end there is a scorecard you can copy into your own evaluation.

Start with the ownership model, not the vendor

Before you compare partners, decide what kind of responsibility you are buying. In practice, external game development tends to fall into three ownership models:

Full-cycle development. The partner takes responsibility for an agreed production scope, from discovery and architecture through gameplay, optimisation and release preparation. You get one accountable technical production partner.
Co-development. Your internal team keeps control of the wider product, while the partner owns defined features, systems or technical workstreams with explicit interfaces and acceptance criteria.
Dedicated engineering capacity. Senior developers join your repository, backlog and review process. You keep technical ownership; the partner adds experienced people without imposing its own workflow.

These are the three engagement models Sourcegarden Studio offers, but the distinction is useful for any shortlist, because the models carry different risks. With full-cycle work, the risk sits in the partner's architecture and production judgment. With dedicated capacity, it sits in your own technical leadership, because the external developers follow your direction. Co-development sits in between: success depends on how well the boundary between the two teams is drawn.

A useful rule is to choose the smallest ownership model that can produce a complete, testable outcome. If you need a networking layer, you probably do not need a full-cycle partner. If nobody in-house can own the architecture of that networking layer, adding capacity alone will not solve the problem.

Ask every partner which model they think fits your situation, and why. A partner who proposes the largest possible engagement for every problem is telling you something.

Bound the scope before you compare estimates

Co-development fails most often at the edges: good work lands in a build that has moved on, depends on a system nobody agreed to change, or meets an acceptance test that was never written down.

A bounded co-development scope should answer at least these questions:

What exactly is owned? A feature, a system, a technical workstream or a vertical slice — named precisely enough that two people would draw the same boundary.
What are the interfaces? Which existing systems, data formats, assets and services the work depends on, and which of them the partner may change.
Who integrates? Whether the partner merges into your main branch, delivers into a separate branch or module, or hands over packages that your team integrates.
What does "done" mean? Acceptance criteria that can be tested in your build: functional behaviour, performance budgets on target hardware, test coverage, documentation.
What stays with you? Product vision, IP, final creative approval, release decisions and access to the people who can make them.

If a partner cannot help you write this down before work starts, the estimate they give you is a guess about an undefined scope. Comparing such estimates across partners compares their optimism, not their capability.

A practical way to test this is to ask each partner to describe how their first two weeks of integration would look in your project. Good answers are specific: repository access, a build they need to reproduce, a first small change merged and reviewed, the person on your side they need to talk to.

Communication and review: how decisions actually get made

Integration problems are usually communication problems that surfaced late. Look past the promise of "regular updates" and ask how decisions are made day to day.

Useful questions:

Which hours overlap with your team? Overlap matters more than distance. A partner in a nearby time zone can review a build, discuss a blocker and agree a fix on the same day. With little or no overlap, the same loop can take a day or more, and that cost compounds across a production.
Who attends reviews? The person presenting progress should be the person accountable for the technical decisions, not only an account manager.
How is code reviewed? In co-development, review rules should be agreed in both directions: who reviews the partner's merges, and whether the partner reviews changes that touch its systems.
Where do risks go? A partner should surface risks and change impact at each milestone, not only at the end of a phase.

As one reference point: Sourcegarden Studio is based in Budapest and works on Central European Time, inside the European Union. For European partners this gives same-day overlap across the continent, practical travel and a familiar EU business framework for contracts and invoicing. For teams elsewhere, the overlap is narrower, and that should be planned explicitly rather than assumed. The location itself is not a quality guarantee — what you are evaluating is whether the partner's working rhythm fits yours. More context on working with a Budapest team is on Why Budapest.

Technical evidence: how to verify a partner's claims

Portfolios are where comparison gets difficult, because the industry has no single convention for crediting work. A studio might show a game it built entirely, a game where it supplied one system, or a game delivered by people who worked somewhere else at the time.

None of these is a problem in itself. A problem appears only when the attribution is unclear. When you review a partner's portfolio, ask for each relevant project:

Who delivered it? The current company, or current team members during previous roles at another studio?
Which part did they own? Full production, a named system, technical direction, or contracted support?
Is that person on your project? Experience only transfers if the people who have it will work on your scope.
What can be verified? A public store page, credits, a publisher reference, a technical talk, or a code walkthrough under NDA.
Which numbers are measured, and which are targets? "90 FPS" can mean a design target, a typical measurement or a worst-case result on specific hardware. Ask which, and on what build.

Sourcegarden Studio applies this distinction to its own portfolio. Bad Goons is presented as the studio's current original IP in active development, and its 64-player figure is labelled as a design target. Bean stalker and VOXSYS are presented as work delivered by current team members during their previous roles at VR Storm Studio, not as Sourcegarden Studio productions. You should expect the same clarity from every partner, and it is fair to ask for it directly.

Beyond the portfolio, the strongest evidence is usually a technical conversation about your project. Ask a senior engineer from the partner to walk through how they would approach your riskiest system. Generic answers that would fit any game are a weak signal. Questions about your constraints, target hardware and existing architecture are a strong one.

Estimation assumptions: compare the assumptions, not the totals

Two estimates for the same brief can differ widely for legitimate reasons. One partner may assume your engine version and build pipeline are stable; another may plan time to reproduce and stabilise them. One may assume your team integrates the work; another may include integration in its own scope.

When estimates arrive, ask every partner to list:

the scope included and explicitly excluded;
assumptions about your codebase, tools, assets and team availability;
dependencies on decisions or deliverables from your side;
what would change the estimate, and by roughly how much;
the milestone outputs you will receive, and how each can be tested.

If key assumptions are still open — for example, an unknown codebase or an unproven technical approach — a reasonable partner will propose a short discovery phase or risk prototype before quoting the full workstream. That is not a sales tactic; it is how you avoid paying for an estimate that was never grounded. Sourcegarden Studio works this way when the unknowns are significant: a focused discovery or prototype first, then a milestone plan built on what it showed.

Illustrative example: a studio asks three partners to quote a matchmaking and lobby integration. The lowest quote assumes the backend service is already configured; the highest includes configuring it and writing deployment documentation. On paper, one partner looks three times more expensive. In practice, the scopes are different. Only a side-by-side list of assumptions reveals it.

Handover and change management

Every co-development engagement ends or changes shape, so ask from the start how the work will be handed over:

Documentation. Architecture notes, setup instructions and known limitations written for the people who will maintain the system, not for the sales deck.
Build and pipeline. Whether your team can build, test and deploy the delivered work without the partner's involvement.
Knowledge transfer. Pairing sessions, recorded walkthroughs or a review period in which your engineers make changes while the partner is still available.
Ownership after release. Who fixes bugs, who answers live incidents and for how long.

Change management matters just as much. Scope will move during a production. The question is whether changes are visible, priced and agreed before they are implemented, or discovered later as overruns. Ask each partner to show how a scope change is proposed, how its impact on schedule and budget is shown, and who approves it on both sides.

The partner evaluation scorecard

Use this table during and after your partner calls. Score each row from 0 to 2: 0 — no evidence, 1 — claimed but not yet verified, 2 — verified with evidence you could show to someone else. The rows are deliberately about evidence; a partner with a strong pitch and weak evidence will score lower than its sales call suggests.

Criterion	What to ask	What good evidence looks like	Warning signs
Proven relevant experience	Which past projects resemble our scope, and what exactly did you own?	Named projects with clear attribution (current company vs previous roles), the owned part described precisely, verifiable sources	Logos without roles; "we worked on" without specifics; mixed company and personal credits
Accountable senior person	Who is technically accountable for our workstream, and how much of their time is on it?	A named senior engineer or lead who joins technical calls and stays on the project	Senior people only in the sales phase; accountability spread across "the team"
Ownership model fit	Which engagement model would you recommend for us, and why?	A reasoned recommendation, including when a smaller model would do	Every problem answered with the largest engagement
Bounded scope and interfaces	What do you own, what do you depend on, and what may you change?	A written boundary: owned systems, interfaces, dependencies and exclusions	Scope described only as a feature list
Integration plan	How will your work reach our build in the first two weeks?	Concrete steps: access, build reproduction, first reviewed merge, named contacts	"We'll adapt to your process" with no specifics
Communication and review	When do our hours overlap, who reviews what, where do risks go?	Agreed overlap hours, two-way review rules, a risk log or equivalent	Updates only as written reports; no review agreement
Milestone outputs	What will we receive at each milestone, and how do we test it?	Playable or measurable outputs tied to acceptance criteria	Milestones defined by elapsed time or hours spent
Estimation assumptions	What does your estimate assume, include and exclude?	An explicit assumptions list and the triggers that would change it	A single total with no assumptions
Technical understanding of our project	How would you approach our riskiest system?	Questions about our constraints and target hardware; options with trade-offs	Generic answers that would fit any game
Handover and change management	How do you hand over, and how is a scope change approved?	Documentation and knowledge-transfer plan; a visible change process	Handover treated as a final zip file

Score every partner on the same rows, with the same people in the room. A high total matters less than the rows that match your main risk. If your biggest worry is integration into a fragile codebase, the integration plan row should weigh more than the portfolio row.

Making the decision

A good co-development partner makes ownership visible: what they own, what you own, and how the two meet in your build. The best way to see that is not in a portfolio but in a short, specific conversation about your scope — followed by a written proposal you can check against the scorecard above.

If you are preparing that conversation, the game development services page describes how Sourcegarden Studio structures full-cycle, co-development and dedicated-capacity work. When you have a workstream in mind, you can share the brief and a senior team member will reply directly.