Should You Hire, Insource, Outsource, or Something In-Between?

As a game studio grows, so does the question of how to build what's next. Every hire, every partnership, and every external team you bring in shapes more than just the project. It can define the studio itself.

So how do you make the right decisions on how to build and scale your team?

It comes down to what you're optimising for – speed, quality, flexibility, or long-term ownership. There are five common engagement models, and each offers unique advantages and trade-offs. Knowing which fits starts with understanding your priorities:

1. Hiring builds permanent capability in-house.
2. Insourcing brings external specialists into your existing team.
3. Outsourcing hands a defined scope to an external partner.
4. Co-development puts an external team alongside yours, sharing the work and its ownership.
5. Full development places the whole game with an external partner, from concept to launch.

Video game outsourcing isn't a last resort, and hiring isn't always the safe default. The right approach isn't about which is “best” – it's about which fits the problem in front of you.

Hiring: Building Long-Term Capability

Some roles exist to serve a single project. Others serve the company as a whole. When you need a leader whose remit crosses several projects, or someone working toward the studio's long-term goals, that's a role to keep in-house. The same goes for core infrastructure, supporting functions, and senior leadership: the roles that hold the company together rather than ship one title.

Hiring is the slowest route to capacity. If you need people fully working and onboarded within weeks, this isn't the easiest move. But it's the only model where the capability stays with you after the project ships, which is why it's the right call for roles that outlast any single title.

Building an internal team deepens your long-term capability and ownership, but every permanent head brings overhead beyond salary – recruitment, full internal onboarding, and the ongoing load on functions like IT and HR. Hiring can often look cheaper on paper when comparing salaries directly with external partner costs. But that calculation leaves out the overhead costs, along with the institutional risk you take on with each hire.

Insourcing: Bringing Specialists Into Your Team

Insourcing brings external specialists into your existing team without adding permanent headcount. They work inside your pipeline, using your processes. In the day-to-day, they're nearly indistinguishable from your own staff.

It's how studios cover the heavy stretches of a dev cycle with planned, temporary capacity. The specialists brought in this way tend to be roles whose full capacity isn't needed at every phase: gameplay and systems programmers, technical designers, level designers, You get the expertise exactly when the workload demands it, and you're not carrying the role once the cycle eases.

But insourcing isn't free capacity. External specialists still need direction, which means day-to-day leadership and project management remain with your team. If your leads are already stretched, bringing in more people to direct won't lighten their load.

Oa Side specialist worked inside Firaxis's proprietary engine on UI, input systems, and technical animation across console and PC – building on a relationship that started back on Civilization VI. Embedded that closely, they operated less like an outside supplier and more like an extension of Firaxis's own team.

Outsourcing: Handing Off Defined Work

Outsourcing hands a defined scope to an external partner who owns execution and delivery. You set the requirements, your partner delivers against them.

Game development outsourcing works best on the parts of the project that sit off the critical path – work with stable technical requirements, clear deliverables, and measurable acceptance criteria. Porting projects are a classic fit. So are specific tools or art packages built to exact specs: self-contained scopes with a clear definition of done, where creative iteration isn't part of the job.

The clearer the brief, the better the fit. A port that needs to run cleanly on new hardware has an unambiguous bar to clear. When the target is fixed and the path to it understood, handing it off is often the most efficient route.

Where it goes wrong is the assumption underneath it – that you outsource to save money on something cheap. You outsource to add capacity, not to cut costs. Getting defined work delivered well so your internal team stays focused on the parts of the game only they can build.

Co-development: Building Together

Co-development puts an external team alongside your own, sharing the work and its ownership.

Technically, it's a form of outsourcing. But where outsourcing hands off a defined scope and returns assets built to spec, co-development shares the process of building. The external team works inside your pipeline – your version control, your QA process, your sprints – making daily decisions alongside your own people rather than delivering to a brief from the outside. Much of the value comes from that collaboration, not just the final output.

That's why co-development suits work that's integrated, evolving, and central to the game – player-facing features, engine work, and ongoing optimisation. The kind of work that crosses disciplines and needs daily calls with your internal team. When what you're building is likely to change as you build it, a partner inside the process is worth more than a deliverable handed back at the end.

It's also a model to plan for, not one to reach for in a crisis. A common misconception treats co-development as the rescue option when a project is already in trouble. But bringing in an embedded team mid-emergency puts both sides in a difficult position. You're asking them to solve problems they didn't help create, with relationships that haven't had time to form. Used well, co-development is a deliberate choice made early, matched to the work it's suited to. On NFL Pro Era, the NFL and NFLPA's VR title developed by StatusPRO, Side's Codev team worked across animation, technical art, stadium and crowd creation, and game design – shaping the experience itself rather than delivering a single defined asset.

Feature Teams: Co-Development At Smaller Scale

But co-development doesn't always have to mean a large, embedded team. The same model works through focused feature teams, or pods, built to tackle a specific system or challenge rather than a whole slice of the game.

A pod is purpose-built around what a project actually needs, not a fixed service package. One pod might own a single player-facing feature. Another might handle a port or a defined area of engine work. The configuration follows the problem.

As the work changes, the team can change with it – scaling up, narrowing focus, or running several pods in parallel.

A single boss encounter is a good example of pod-shaped work: a self-contained challenge a focused team can own end to end. On the Silent Hill 2 remake, Side's co-development team took on exactly that – rebuilding one pivotal boss battle with Bloober Team, from animation and AI behaviour through to the level itself.

Full development: Handing Off The Entire Production

Full development places the entire build with an external partner. You set the vision and keep the IP; the partner takes it from concept through to launch. It's designed for those who own a concept but don't have the team to build it – an IP holder from outside the games industry, say a film, TV, or publishing brand looking to turn their world into a game. You get a complete production and a title you couldn't have shipped in-house, with your control shifting from daily decisions to milestone reviews and final sign-off.

The trade-off is commitment. A partner running your whole production is deeply embedded, so switching midway is far more disruptive than replacing a bounded outsourcing job. That puts the weight on getting it right upfront – the brief, the IP terms, and above all a partner whose judgement you trust to carry the vision.

Which Model Is the Best Fit?

The right model depends on your goals, timeline, budget, and the expertise you already have. A few questions can help determine what that means for you:

• What's the time frame of the need? Permanent capability points towards internal hiring; temporary coverage often points towards outsourcing, insourcing, co-development, or full development.
• How much management can you provide? Every model demands direction – some more than others. Be honest about what your team can take on.
• What does the company need versus the project? A role serving long-term company goals belongs in-house. Project-specific work has more options.
• How much operational risk can you take on, and how fast do you need to move? A defined handoff limits risk, while an embedded team moves quickly but asks more of you upfront.
• What infrastructure does the work require? Different models have different setup requirements, from straightforward asset handovers to deeper integration with your tools and pipelines.

Work through these, and one factor usually rises to the top: how much of the creation process you want to share. The more the work depends on daily collaboration and shared decisions, the further you move from a clean handoff toward co-development. The more self-contained and defined the work is, the more outsourcing makes sense.

Few studios pick one model and stop there – most end up combining several across a project's lifecycle. A common path starts with insourcing to add specialists, then expands into co-development as collaboration deepens.

As a starting point, matching what you need to how each model works can point you in the right direction:

Choosing The Right Model for Your Studio

There's no single right way to scale a development team. Hiring, insourcing, outsourcing, co-development, and full development each solve a different problem – defined by how permanent the need is, how much collaboration it demands, and how much of the creation process you want to share.

Side works with studios across each of these models – from embedded specialists and defined outsourcing scopes to Codev teams and full development. That means we can help shape the right setup around the project, rather than forcing the work into a fixed delivery model.

If you’re weighing how to add capacity or structure your next phase of development, talk to our team about what your project needs.

Frequently Asked Questions

What is the difference between hiring, insourcing, and outsourcing?

 The difference between each model comes down to how long the arrangement lasts, who owns the work, and who directs it. Hiring builds permanent capability inside your studio. Insourcing brings external specialists into your existing team for a fixed period, working under your direction. Outsourcing hands a defined scope to an external partner who owns delivery and returns finished work to your specification. Co-development puts an external team alongside yours, sharing both the building process and its ownership. Full development places the entire build with a partner, with your control shifting to milestone sign-off. In short, hiring and insourcing add capacity you direct, while outsourcing, co-development, and full development hand increasing ownership to a partner.

What's the difference between game development outsourcing and co-development?

What the external team is working toward. In outsourcing, the partner delivers work built to your specification – a defined scope with a fixed definition of done. In co-development, the partner works inside your project and shares the process of building it, contributing to decisions as the work evolves. Outsourcing gives you a deliverable. Co-development gives you a team building alongside your own. Outsourcing suits stable, well-defined work. Co-development suits work that's evolving and creatively central to the game.

When should a studio outsource instead of hiring?

Outsource when the work is defined, self-contained, and off the critical path – a port, a tools job, a bounded deliverable with measurable acceptance criteria. Hire when the role serves the company's long-term goals rather than a single project. The deciding factor shouldn't be cost. Studios often outsource to save money, but that's usually a mistake – outsource to add capacity and get defined work delivered well, so your internal team stays focused on the parts of the game only they can build.

What is co-development in game development?

Co-development is a model where an external team works alongside a studio's internal team to build part of a game together, sharing the work and its ownership. The external team operates inside the studio's pipeline, making daily decisions with internal staff rather than delivering to a fixed spec. It suits work that crosses disciplines or changes as it's built – player-facing features, engine work, optimisation.

What is a pod-based co-development model?

A pod-based co-development model delivers co-development through small, purpose-built teams – pods – each shaped around a specific feature, system, or challenge. A studio can bring in a focused pod to own a defined area, scale it as needs change, or run several pods in parallel. The configuration follows the problem, not a fixed service package.