Who owns the IP and the source files when you outsource game development?
Whoever the contract says, which is why this is settled before kickoff rather than at the final invoice. Assign all IP created under the agreement to you on payment, and require the working files at every milestone rather than at the end: layered art, project files, uncompiled source, build scripts. Name the formats. A studio that will only deliver flattened exports or compiled binaries leaves you unable to change the work without going back to them, which is a commercial position rather than a technical limit. Check separately what pre-existing tools or libraries the studio brings, and what licence you keep for them.
How do you stop quality dropping after the pilot team moves on?
Name the people in the contract and put a notice period on replacing them. Quality drift is usually staffing drift: the seniors who ran the pilot are the studio's strongest team, and once you sign they can move to the next prospect. Ask who would replace them and on what notice, require that substitutions are approved by you, and keep the first weeks of the full contract on the same kind of deliverable as the pilot so you can compare like with like. Review the first delivery after any staff change as carefully as you reviewed the pilot, because that is where the drop appears.
How much do time zones and slow reviews slip a game schedule?
With no working-hours overlap, every unanswered question costs a full day, and that compounds on work that needs several rounds of notes. Art is where it bites, because the answer to "is this right" is usually "not quite" and each round is a strict dependency. Well-specified engineering survives a reply lag, since the acceptance criteria are written down and testable. Mitigate by placing iterative work in a high-overlap region and specified work anywhere, by fixing a daily written hand-off, and by giving the studio acceptance criteria it can check without you. The time zone overlap guide has the region table.
What costs appear after the vendor quote?
The costs that break budgets sit on your side of the line. Someone has to write the briefs, review deliverables and run feedback rounds, which is a standing claim on a producer's week for every active vendor. Assets arrive correct and still need importing, tuning and bug fixing inside your build. Then come revision rounds beyond the contracted number, currency and transfer fees, contract and IP review, and the ramp-up weeks where a new team is slower than it will be later. Budget the pilot explicitly and add contingency for integration, because integration is real work that rarely appears in a vendor quote.
How do you avoid becoming dependent on an outsourcing vendor?
Require the knowledge to arrive with the work. Documentation, source files and a short handover note per milestone cost the vendor little while the project is live and are almost impossible to obtain afterwards. Keep architecture decisions and the core loop in house so nobody else holds the map of your game. Where one vendor owns a whole discipline, keep at least one person internally who can read and modify what they deliver. If that discipline is critical, run a second smaller vendor on adjacent work: the point is not to split the budget but to keep a tested alternative you could scale up.
When is outsourcing the wrong call?
Outsourcing is the wrong call when you cannot write down what done means. Work that is still being prototyped, systems that change weekly, and anything that defines the game's identity cost more in briefing and revision than they save. It is also wrong when nobody internally has time to run the vendor, because an external team without a producer answering it produces confident work in the wrong direction. And it is wrong as a rescue for a project that is already late, since a new team spends its first weeks learning your build. Fix the specification first, then decide what to send out.
