Two things should end a deal on the spot. The first is a proposal whose first milestone contains no playable build, only documents, architecture, and “foundations.” The second is a team swap after signing, where the people who pitched you are not the people who show up for sprint one.
Both flags are cheap to spot and expensive to ignore. The rest of this article is about everything that comes before they appear: the clauses, the milestone wording, and the checks that decide if you ever see them. I go in the order a development agreement does, from scope down to money. I have hired outside teams for ports, co-development, art, and live-ops for about nine years as a producer and later as a small studio owner. I am not a lawyer, so read the sample wording below as a prompt for your own counsel, not as legal text.
Scope and model: which of the three deals did you buy?
The question this part of the contract answers is simple. Who decides what the game is? Plenty of bad outsourcing stories are scoping errors in disguise. A founder wanted a co-developer and signed with a work-for-hire vendor, or the reverse, and the partner was fine the whole time.
| Model | Who decides design | What you own | Where it breaks
|
|---|---|---|---|
| Work-for-hire (art, a port, one feature) | You, fully | Everything, if the contract says so | Spec drift. You receive exactly what you wrote, mistakes included |
| Co-development | Shared, with the partner owning whole systems or platforms | Your IP and shared repo, while their tooling often stays theirs | Integration debt, which tends to surface around month five |
| Full-cycle | Mostly them | IP and source, but the know-how leaves at handoff | You are buying judgment too, so the game is capped by their lead designer |
Engine depth matters inside whichever row you pick. Anyone can print Unity and Unreal on a capabilities slide. What I look for is a team whose Unity development services reach past gameplay scripting into render pipeline tuning, memory budgets on the weakest device you target, and a build pipeline that produces a console-ready package without a person babysitting it. If they cannot tell you when they last profiled a frame on low-end hardware, they have not done it lately.
The market is also less predictable than it was. The GDC State of the Game Industry 2026 report, a January 2026 survey of more than 2,300 professionals, found that 28 percent of respondents had been laid off in the previous two years, and 33 percent of US respondents. Unreal was the primary engine for 42 percent and Unity for 30 percent. Over on the supply side, the XDS26 Insights Report (more than 250 submissions, collected September 10 to November 30, 2025) put the share of service providers offering engineering at 34 percent, up from 10 percent a year earlier.
Now the inference, and it is mine, not the reports’. I read those two numbers as one story. Senior people who left large studios in 2024 and 2025 are regrouping as small co-development shops, which would explain engineering capacity more than tripling in a year. If that is right, buyers face a market with more genuine talent in it and more freshly printed websites too, and a portfolio page cannot separate the two.
Deliverables and milestones: what exactly do I get, and when?
This is the section where I spend most of my negotiating time, because milestone wording is where a vague partner shows up. A milestone is a sentence you may someday quote in a dispute. Write it like one.
Weak:
Milestone 1: Core combat system complete.
Strong:
Milestone 1: Combat playable end to end on the PS5 devkit at 30 fps, with the three enemy archetypes from the design document, delivered as an installable build by the 14th of the month.
The weak version can be “complete” in the partner’s head while you hold nothing. The strong version either runs or it does not.
That wording also rules out flag number one. If a partner’s proposed first milestone is documentation and foundations, I treat the proposal as dead. A competent team can get something ugly running within weeks. A team that cannot is usually hiding it, and I have never been wrong enough on this to regret walking.
Before I sign anything long, I buy a paid vertical slice under its own short contract. Fixed price, two to four weeks, a hard date, and it has to run on the real target hardware (for mobile, the worst device in your support matrix, not the Unity editor at 4K). Pay for it fully. A free pilot attracts the team’s B players, and an unpaid slice gives you no standing to be demanding.
What does a slice tell me that a reference call cannot? How they estimate. Whether the build is reproducible or lives on one engineer’s laptop. How they react when I change a requirement in week two, which I do on purpose. I have walked away from two partners after a slice and count both as the best money I spent in those years.
IP and source code: who owns the work if the relationship ends at milestone six?
Assignment language should be present tense and cover work in progress. I have read agreements where ownership moved “upon final payment,” which sounds harmless until things collapse at milestone six of nine and you own nothing you paid for.
Weak:
Upon final payment, Contractor shall assign to Client all rights in the Deliverables.
Strong:
Contractor hereby assigns to Client all right, title, and interest in the Work Product as it is created, whether or not delivered or paid for, excluding only the pre-existing tools listed in Exhibit B.
Exhibit B matters. Partners do bring their own tooling and they should keep it, but name it, in a list, so nobody argues later about whether the dialogue system was theirs.
On source, escrow is the old answer and a live mirror is the better one. Escrow means a third party holds a snapshot, which is only as fresh as the last deposit. A mirror means the repo copies to infrastructure you control from day one, nightly at minimum, with a short clause giving you read access to the partner’s build scripts and asset pipeline too. Code alone rarely rebuilds a game. I have inherited a repo that compiled on nobody’s machine but the vendor’s, and it took my team three weeks to find out why. In 2021 a partner on a mobile project of mine went silent for nine days over cash trouble. We had the mirror, so we kept working. A studio I shared a floor with had a different vendor and no mirror, and lost roughly four months.
Acceptance criteria: how will we both know it is done?
Acceptance language written as effort (“best endeavors,” “high quality”) leaves both sides free to be unhappy. Write behavior instead, and name the hardware.
Weak:
The build shall perform acceptably on target devices.
Strong:
The build holds 60 fps average and never drops below 45 on an iPhone 12 for a 20-minute scripted play session, reaches the main menu in under 12 seconds from cold start, and completes a four-hour automated soak test with zero crashes.
The numbers will differ for your game. The point is that a stranger could test them, on a device they could buy, using a script written before the build exists. Add a cure period too, say 10 working days to fix a failed acceptance test before payment is withheld, so a single bad Friday does not turn into a legal posture. I also add who runs the test, because two parties measuring on two devices is how you get a month of arguments over a number.
Communication and cadence: what does the daily update look like?
Founders fixate on the hour gap. I have run teams spread over nine time zones that felt closer than a vendor two floors down, so I stopped worrying about geography a long time ago. Cadence is the variable, and it needs to be agreed before kickoff.
My default is dull and it works. Every day the partner posts a written update in one channel, in a fixed shape: what changed, what is blocked, which build to play. Three days a week we hold a 30-minute call inside the overlap window. A playable build lands every Friday. Each side names one person who can say yes without escalating, and on the partner’s side that person must be a producer, not a sales lead.
The XDS26 report points the same way. It found that communication challenges rose about 15 percent year over year for studios hiring external teams and for the providers themselves. Both sides report it, which looks to me like a process gap and not a language one (that reading is mine).
This is also where flag number two lives. Put named people in the statement of work, with approval rights over replacements. On a 2022 Switch port, the senior engineer from our pitch calls turned out to be “on another engagement,” and the replacement had never shipped on Nintendo hardware. I should have paused the contract that week. I waited two months.
Certification and live-ops: who has been through the gate before?
My cheapest accepted bid ever was a 2019 console port, 30 percent under the others. It failed certification three times. The partner had shipped on PC and mobile and called console “similar.” It is not. Sony, Microsoft, and Nintendo each publish their own rules on suspend and resume, controller disconnects, and save data handling, and each failed submission cost us two to three weeks. The savings were gone by the second resubmission.
So the question goes into the contract as a representation: how many submissions did your last three console titles need per platform, and what failed? Ask for the rejection reports if they will share them, redacted. Teams that have done it answer in detail, often with a slightly haunted look. Teams that have not say “we have certification experience.”
Then comes launch day and the days after it, which a delivery-only partner treats as someone else’s problem. I write in a warranty period of 90 days at minimum, with the same named engineers on call for defects, covering the day-one patch and the crash spike on that one Android chipset. If live-ops does not appear anywhere on a partner’s rate card, they have not done much of it. For context on how crowded your launch is, SteamDB counted 19,112 releases on Steam in 2025 as of December 12, and 9,327 of them had fewer than 10 reviews. A slipped date lands harder every year.
Money: how much goes out before something works?
My ceiling is 15 to 20 percent up front, and every payment after that is tied to a milestone I can verify by playing it. Keep 10 percent back until the warranty period ends. Partners complain about the holdback exactly once, and the ones who push hardest are telling you something.
Rates are the least useful number in the proposal. Newzoo’s latest update put global games revenue at $201.6 billion for 2025, the first year past $200 billion, so there is real money in the sector and a lot of people trying to attract it. A cheaper hourly rate on a team that needs three certification attempts is not cheaper. I compare total cost to a passed submission, and I count my own team’s hours spent babysitting.
Set a change request price list in the same section. Day rates by role, the process for approving extra scope in writing, and a cap on what the partner may spend without your sign-off. Scope will move. The only open question is how you pay for it, in an agreed rate or in an argument.
The slice that ended a deal
A few years back I was about to sign a nine-month co-development contract for a mobile title. The studio was charming, the portfolio was strong, and the rate was 25 percent under the other bid. I insisted on the paid slice anyway: three weeks, a fixed fee, an Android device from our bottom tier.
On day 19, they sent a build. It ran on their lead’s flagship phone. On our test device, it crashed at the loading screen, and when we asked for the build steps, it took them four days to reproduce their own result. Nobody had built the pipeline. The art was lovely, and the project was held together with one engineer’s good intentions.
I paid the slice invoice, thanked them, and signed with the other team, who were dearer and also a little dull. Their slice was ugly and boring, and it ran on every device we owned. The game shipped on its date.
The first studio emailed me a year later, quite friendly, asking if I had work. I said not yet.