Hire Unity Developers: Rates, Vetting and Staffing Shape

What a Unity developer actually does on a real project

A Unity developer builds the thing the player touches: the scene graph, the prefabs, the C# that runs every single frame, the render pipeline choice, and the build that has to open on a four year old Android phone without cooking it. On a mobile project they are also, whether the job description says so or not, the person responsible for your frame budget, your download size, and whether you can change a difficulty curve without shipping a new binary through store review.

It breaks in week seven, and it breaks the same way most times. The build runs at a locked 60 in the Editor on the lead's MacBook. You sideload the APK onto a Redmi Note for a playtest and it opens at 24fps, sags to 14 after four minutes because the chip starts thermal throttling, and the download is 340MB because everything got dumped into a Resources folder and shipped uncompressed. You open the Profiler and there are 11ms of garbage collection inside a 16ms frame, most of it from string concatenation in Update. The developer says they will optimize at the end. There is no end. You are three weeks from soft launch and the fix is architectural, not a checkbox.

The Editor lies. It runs Mono, not IL2CPP. It has different memory behavior. It runs on desktop silicon with a fan. A Unity developer who has only ever seen their game in Play Mode is not a Unity developer who has shipped, and that single distinction accounts for most of the gap between the good hires and the expensive ones.

Engagement models: in-house, freelancer, agency, staff augmentation

In-house hire. Right when Unity is your product for years and you have real live ops: weekly content drops, an economy, seasonal events. Wrong when you have one game and no plan for a second. After launch your Unity engineer has thirty percent weeks of bug fixes and seventy percent of nothing, and you pay for all of it. This is also the hardest role to recruit: the good ones are inside studios, and you compete on shipping credits and comp, not on your funding story.

Freelancer. Fastest and cheapest, and correct for a slice with a finish line: an iOS port, wiring in ad mediation, clawing back a frame budget, a prototype to put in front of an investor. Wrong for anything you intend to maintain. The failure mode is predictable: bus factor of one, Asset Store licenses bought under their seat and not yours, and a project structure only they can navigate. When they go quiet in month five you own a Unity project nobody else can open without a week of archaeology.

Agency. Buys you the tech artist, the backend engineer for the economy, QA on an actual device lab, and someone who has been through App Store review and Google Play policy rejections before. You pay more per hour and you carry coordination overhead. Wrong when your scope is a single clear ticket.

Staff augmentation. One or two engineers embedded in your standup, your repo, your architecture calls, on someone else's payroll. This fits most mobile game and interactive 3D work, because it lets you rent seniority for the six months where seniority decides whether the project ships.

What Unity developers cost

These ranges are what Digital Heroes sees quoted and what we quote, from our own delivery and market experience. They are not a survey, and rates move with region, seniority, and how specialised the work is.

• India, South Asia, Southeast Asia: mid-level Unity $20 to $45 per hour, senior $40 to $65.
• Eastern Europe and Latin America: mid-level $35 to $60, senior $60 to $90.
• US, UK, Canada, Western Europe, Australia: contractors $90 to $150, with senior specialists in DOTS, netcode, XR, or tech art at $150 to $200 and up.

The in-house number is not the salary. Payroll taxes, benefits, insurance, and equipment push base up by a meaningful margin, commonly a quarter to a third again in the countries we hire in. Recruiting costs either an agency fee, and the game recruiters we have used quote a percentage of first year base, or several months of your own hiring time. Then ramp: four to eight weeks before a strong Unity engineer is net positive on an existing codebase, longer if the project has custom editor tooling they have to learn. Add per seat Unity licensing, a CI setup that needs its own license to run headless builds, and a device lab of six to ten Android phones across performance tiers plus a couple of older iPhones. Everybody forgets the device lab, and the device lab is the thing that catches the 14fps.

How to vet a Unity developer

Skip the general C# quiz. Ask questions only someone who has shipped can answer without stalling.

• "Walk me through Update, FixedUpdate, and LateUpdate. Where does input reading go, where do physics forces go, where does camera follow go, and why?" Basic, and it sorts the room in ninety seconds.
• "Tell me about a bug that only appeared in an IL2CPP build and never in the Editor." Good answers: managed code stripping removed a type reached through reflection and they fixed it with link.xml or a Preserve attribute, an AOT problem with generic virtual methods, a serialisation library that was fine on Mono and died on device.
• "How do you profile on device, not in the Editor?" You want Development Build with Autoconnect Profiler, or the Profiler attached over USB, reading the GC.Alloc column and the CPU timeline rather than the Editor's numbers. Deep Profile as a last resort because it distorts timings. If they have never attached to a device, everything else they say about performance is theory.
• "Addressables or Resources, and what breaks when your remote catalog was built against a different Unity version than the player build?" Good candidates wince before they answer. They have been burned. They talk about catalog versioning, content update workflows, and why they keep Resources nearly empty.
• "Your draw calls jumped after you started tinting objects per instance. What happened?" They should reach for SRP Batcher compatibility, MaterialPropertyBlock, or GPU instancing, and they should be able to open the Frame Debugger and show you where the batch broke. What matters is that they know batching is fragile and an innocent change can break it.
• "Two engineers need to touch the same scene this week. What do you do?" Good: nobody does, the scene is nearly empty, everything lives in prefabs and ScriptableObjects, Git LFS and the Unity YAML merge tool are configured, or they use file locking in Unity Version Control. Bad: "we take turns."
• "What texture compression do you ship on Android, and what is your fallback?" ASTC with an ETC2 fallback. If the answer is "the default," end the call politely.
• "Show me a frame you took from 30 to 60 and tell me what you cut." The right answer is specific and slightly boring: pooled the projectiles, cached the GetComponent, pushed pathfinding onto a Job with Burst, cut a fullscreen blur, stripped shader variants to kill the first-run hitch, set Application.targetFrameRate deliberately rather than leaving it at the platform default.

The take-home. Do not ask them to build a game. Hand them a deliberately broken Unity project and pay for three to four hours: several hundred GameObjects calling GameObject.Find and GetComponent in Update, a Resources folder of uncompressed 2048 textures, an uncompressed audio bank, and a Canvas that rebuilds every frame. The brief is: get this under 16ms on a mid-tier Android device, do not change the gameplay, and write half a page on what you changed, what you deliberately left alone, and why. The note is worth more than the diff. Juniors fix everything they can see. Seniors tell you what they chose not to touch.

Portfolio review. Do not watch the trailer. Ask for the live store link and the crash-free rate. Ask which systems they architected versus which project they joined at month fourteen. Ask what the build size was at first submission and what it is now. Then ask them to share their screen, open the project, and walk you through the prefab hierarchy and where game state actually lives. Five minutes of that is worth an hour of conversation.

Red flags

• The portfolio is Asset Store glue. Every credit is "I integrated Playmaker, Easy Save, and a third party controller." Those tools are fine, but if no code they authored outlived them, ask instead: show me something you wrote that another engineer maintained after you left, and tell me what they complained about.
• They only ever tested on their own phone. Ask: name the lowest tier Android device you validated on, what your frame budget was in milliseconds, and how long you played before checking the frame rate again. If thermal throttling is a new idea to them, they have not shipped mobile.
• Everything is a singleton MonoBehaviour and game state lives in the scene. Ask: how do you run a combat or economy calculation in a test without entering Play Mode? If they cannot, every balance tweak costs a full playthrough to verify, and you will stop tweaking.
• They reach for DOTS or ECS on a 2D match-3. That is resume driven architecture and it will cost you a quarter. Ask instead: what is the simplest thing that hits the frame budget, and when would you not use ECS?
• Nothing in their answers touches live ops. Balance values are consts in C#. Ask: how do you ship a difficulty change without a store review? If the answer is "we submit an update," you have built a game you cannot tune, and tuning is the entire job after launch.

When to hire a Unity developer, and when to hire someone else

If you are building a game, this is the role. Beyond that, be honest about the shape of the problem. If you are building an app with one 3D moment, a product configurator or an AR try-on, embedding Unity as a Library into a native or React Native shell works, but it adds real weight to your binary, fights your app lifecycle, and hands you two build systems to maintain forever. Often the cleaner answer is a native developer with SceneKit, RealityKit, or a WebGL view. Hire Unity when the interactive 3D is the product, not a feature.

If the target is Quest or Vision Pro, a Unity generalist is not an XR developer: hand tracking, comfort, foveated rendering, and a 72 or 90Hz budget are their own discipline. If you want console-grade AAA visuals, that conversation is about Unreal. If you need an authoritative server for a multiplayer economy, your Unity client developer is not your backend engineer: Netcode for GameObjects or Photon Fusion solves transport, not fraud, receipts, or the ledger. And if your real problem is retention or monetisation rather than framerate, your next hire is not a second Unity engineer, it is someone who can read the funnel.

Digital Heroes staffs Unity work as a shape, not a headcount: one senior Unity generalist who owns architecture and the frame budget, a mid-level engineer on features, a tech artist part-time on shaders, LODs, lightmaps and texture budgets because that is where mobile performance is won and it is not a programmer's job, and a backend engineer only once there is an economy or real-time play. Your repo, your Unity organisation, your store accounts, from day one. We start with a two week paid pilot on the slice of your project you are most worried about, and if the profiler numbers have not moved by the end, you keep the code.