Scope, Not Price: A Unity Developer on Where Game Projects Go Wrong
Most conversations about hiring a game developer start with money and time. According to one Unity developer, the more useful conversation starts with what the project will not include.
Maxkcy, whose work is collected on Maxkcy's portfolio, was recently included in a roundup of freelance Unity game developer portfolios. In a short interview, he answered three questions about the practical side of building games for other people — with an upfront caveat about where his perspective comes from.
He described his background as mostly non-commercial: a handful of projects for family, plus his own games and side projects. He is hoping to take on paying clients going forward, including game projects, and said his answers come from that non-agency vantage point rather than from years of client work.
That honesty shapes the interview. The advice below is less a pitch and more a set of boundaries one developer has drawn for himself.
When the budget and the game don't match
The first question was about the common situation where someone wants a Unity game built, but the budget or deadline they have in mind does not match what the game actually needs.
His answer is to protect the core of the game and remove everything around it. If money or time is short, he cuts features — multiplayer, AI, custom shaders, heavy polish — and keeps the core loop simple.
He also set a firm line: "I'd rather turn a project down than take one I can't finish."
That is a useful framing for anyone commissioning work. A reduced scope that ships is usually worth more than an ambitious scope that stalls. The features he names as first to go — multiplayer, AI, custom shaders, polish — are also among the most expensive to build and the hardest to estimate, which makes them natural candidates for a first version.
He was candid about his own habits too, noting a quality bar despite "a habit of cutting corners, guilty." The point stands either way: deciding what to cut before work begins is cheaper than discovering it mid-project.
What hiring guides leave out
The second question asked what comes up repeatedly when people ask him to build a game — something the guides on hiring a game developer tend to skip.
His answer was about difficulty. Specifically, how badly non-technical clients underestimate it.
He gave a concrete example from his own experience: family members asked him for things that sounded simple and turned out to be weeks of work. In those cases, he rejected the requests.
This is the gap that guides often gloss over. A feature that sounds like a sentence — add a leaderboard, make it multiplayer, let players share levels — can translate into weeks of engineering, testing, and edge-case handling. Clients who have never built software have no reliable way to judge that, and developers who do not say so out loud end up absorbing the difference.
The question almost nobody asks
The third question was which question people rarely ask before hiring a Unity developer, and later wish they had.
He was direct about the limits of his experience here: "Honestly, I don't have a strong answer — my client experience is limited to family, where expectations were already set."
But he did flag one thing worth asking: "people rarely ask 'what will you not do / what's out of scope,' and that's usually where things go wrong."
He added that expectations can also be overestimated based on personal projects that took months — a reminder that a developer's own hobby work is not a reliable schedule for a commissioned project.
Practical takeaways
For anyone preparing to hire a Unity developer, the interview suggests a few concrete steps:
- Ask what is out of scope. Get the exclusions in writing alongside the deliverables. That is where the developer himself says projects tend to break down.
- Expect feature cuts when budgets are tight. Multiplayer, AI, custom shaders, and heavy polish are the usual casualties. Agree on the core loop first.
- Pressure-test your own assumptions about difficulty. If a feature sounds simple to you, ask what it involves. The answer may be measured in weeks.
- Treat personal projects as a signal, not a schedule. A developer's own game is evidence of skill, not a promise about your timeline.
- Value a developer who says no. Turning down work he cannot finish is, by his own account, part of how he protects the projects he does take.
None of this requires a large agency or a long track record to apply. It requires a conversation about scope before the first invoice — which, on this developer's account, is the conversation most clients never have.