You already have a production pipeline. Then you add an external art team. Suddenly there are more people, more files, more feedback, and more chances for something to get lost.
The goal is simple: the external team should feel like part of your team, not a separate company sending files over a wall. The first two weeks usually decide whether that happens. This guide explains how to make it work without creating a second, disconnected production process.
If you are still deciding what kind of help you need, start with our guide to game art outsourcing and co-development. This article starts after that decision has been made.
Do not build two pipelines
Most studios are trying to add capacity. The mistake is accidentally adding a second pipeline instead.
It happens quietly. The external team uses different folders, different file names, and a different review process. Their work looks good in a screenshot, but something breaks when it reaches the engine. Materials are missing. Lighting changes the look. Nobody knows who should fix the last details.
Then everyone blames the artwork. Usually the real problem is much simpler: the two teams never agreed on one way of working.
Before production starts, write down what both teams will share. Use one tracker, one naming system, one source tree, and one clear review process. Keep it boring. Boring is good here.
What usually breaks first
The same problems show up again and again. They are rarely about artistic skill.
| Rank | What breaks | How it shows up | What fixes it |
|---|---|---|---|
| 1 | Reviews happen outside the game | An asset is approved in a screenshot, then looks wrong in the engine. | Review real work inside the build from the first week. |
| 2 | Files are organised differently | Names and folders do not match, so assets get lost or break tools. | Agree on one structure before the first delivery. |
| 3 | Tools and standards drift | Software versions, texture rules, LODs, or materials stop matching. | Lock the versions and check them together every month. |
| 4 | Nobody owns the final step | The asset is almost done, but collision, materials, or setup are missing. | Name the person who takes approved work into the final build. |
| 5 | Feedback becomes messy | Notes are late, repeated, or understood differently by each team. | Keep one thread and record one clear decision after each review. |
Four of those five problems come down to communication and ownership. Better artists cannot fix a process nobody owns.
It is often a management problem
This may sound uncomfortable, but it matters: when an external team appears to be failing, the problem is often on the client side.
Maybe feedback arrives a week late. Maybe the visual direction changes but nobody records it. Maybe the external team cannot access the latest build or speak to the people responsible for lighting and animation. They are expected to deliver, but they are missing the information needed to deliver well.
That is not a talent problem. It is a management problem.
A good setup feels almost uneventful. Everyone uses the same tracker. Reviews happen on time. Notes are specific. Decisions stay decided. Nobody reaches a milestone and discovers that the two teams were building different things.
You get the quality you enforce, not the quality you describe. A beautiful reference deck is useful. A clear review process is what gets the project shipped.
Decide who owns each part
Make this clear before the first asset moves. Use people's names where you can, not only job titles.
| Decision | Yours | Theirs | Shared |
|---|---|---|---|
| Visual direction | Set the target and approve it | Work toward that target | Solve unclear areas together |
| Technical rules | Define the standards | Follow them and flag problems early | Check them at each milestone |
| Reviews | Give final approval | Review work before submitting it | Meet regularly inside the build |
| Project tracker | Provide the system | Keep work and status updated | Use one board as the source of truth |
| Source control | Set permissions and policy | Work inside the agreed area | Agree on branch and merge rules |
| Final implementation | Name the internal owner | Provide clean files and support | Agree on exactly what a handoff includes |
If two people appear to own something and neither person is named, nobody owns it. That is where a milestone usually slips.
Use the first two weeks to connect the teams
Do not expect full production speed on day one. The first two weeks should be about integration.
Start by checking the folder structure, file names, software versions, engine access, source control, and review schedule. Let the external artists study the actual project, not a random folder of references. Then take one small, real asset through the entire process, from the brief to the final build.
That first asset is a test of the pipeline, not a test of who can make the prettiest image. It should expose missing access, unclear standards, and slow feedback while those problems are still cheap to fix.
Once that works, settle into a predictable rhythm. Review the work in the build every week. Agree on how quickly both sides will answer. Check once a month that the tools and standards still match.
What your team needs to provide
An external team cannot join a pipeline it cannot see. Before production starts, make sure your side provides the basics.
- One person who owns the integration. Usually this is an art director or technical artist who understands the project and has time reserved for the external team.
- Real access. Give the team access to the tracker, source control, current build, and reference library. Do not call them onboarded while they are still waiting for permissions.
- A clear definition of done. Write down what an approved asset includes: source files, LODs, collision, materials, names, folders, and engine setup.
- Useful feedback. Give specific notes, include references, and send them on time. "It doesn't feel right" is not enough.
- A short decision log. When the direction changes, write down what changed and when. It saves arguments later.
- Real security rules. NDA first, clear access levels, and controlled handling of source files. Good security makes long-term collaboration easier, not harder.
Ask one simple question
Before work begins, ask: Who takes this asset from approved to shipped?
That person fixes the collision, assigns the material, checks the LODs, and makes sure the asset really works in the game. If nobody can answer the question, stop and choose an owner. Otherwise the external team may be blamed for a final step it was never asked to handle.
Send a brief people can actually use
A useful brief does not need to be long. It needs to be specific.
- What you need and why you need it
- Engine, platform, and software versions
- Where the work will be reviewed
- File names and folder structure
- Texture, LOD, material, collision, and performance rules
- What is already decided and what is still open
- The name of the person who owns final integration
- Where feedback will live and how quickly both sides should answer
- What must be included before an asset is considered approved
- Security and access requirements
"Please add more detail" is not a brief. This is:
Mid-production action RPG. Unreal 5.4, PC and current-gen console. 14 modular dungeon kits to match our existing language. Texel density 10.24 px/cm on hero surfaces, three LODs, collision per module, materials in the existing master. Source in Perforce under the folder structure attached. We have one technical artist, name here, who owns final implementation. Review is Tuesday, 60-minute turnaround from their side, notes in the shared tracker within 24 hours.
That takes about an hour to write and can save weeks of confusion.
A few things to avoid
- Do not assume integration is included. If somebody needs to put the work into the build, name that person.
- Do not review only screenshots. Check the work where it will actually be used.
- Do not keep two trackers or two file structures. Pick one system and use it.
- Do not send feedback from five people. Choose one person who can make the final call.
- Do not treat the external team like a ticket machine. Give them the context behind the work.
What good integration feels like
When integration works, it is not dramatic. Work appears in the build. Reviews happen on time. Problems are raised early. The internal team does not need to rebuild everything that comes back.
That is how external teams can contribute to large productions such as Diablo 4, Halo Infinite, and Fortnite. The challenge is not simply making excellent art. The challenge is making excellent art that fits an existing game, pipeline, and schedule.
The same applies to VR and live-service projects. The artwork has to work in the headset, in the engine, and in the next update. It cannot live beside the production. It has to live inside it.
NUARE has worked this way since 2006. We use the same principles in our own production systems and in Picrowd, the studio operations platform we build. One board, one clear source of truth, and fewer opportunities for two teams to become two separate productions.
The short version
- Use one pipeline, one tracker, and one review process.
- Spend the first two weeks connecting the teams before chasing full speed.
- Test the process with one real asset inside the build.
- Name the person responsible for final integration.
- Give clear feedback quickly and record important decisions.
- Check access and management before assuming there is a talent problem.
If you are still choosing a partner, our guide to choosing a game outsourcing studio covers the questions worth asking before production begins.
If you are preparing to add an external art team, talk to us at contact@nuarestudio.com. Send the engine, the schedule, the scope, and the main production gap. We can usually tell in the first conversation what needs to be connected before the real work begins.