Most Unity tutorials optimize for the first hour. Get a character moving, get a scene lit, ship a prototype. That’s the right priority when you’re proving a concept, and it’s exactly the wrong priority once the project has 400 prefabs and a second person on the team. A record 19,468 games shipped on Steam in the most recent full year tracked. The ones that shipped on schedule weren’t using better rendering features than the ones that didn’t. They’d made a handful of unglamorous engine decisions early — the kind that cost two days in month one and save two months in month nine.
1. Addressables, earlier than feels reasonable
Direct references work fine until the build hits platform memory limits, at which point retrofitting asset loading means touching every scene that hardcoded one. That refactor lands at the worst possible moment, usually somewhere near certification.
The counterargument is real. Addressables adds friction on day one: groups to configure, a build step to maintain, and a class of bug that fails at runtime instead of compile time. For a two-month jam project, skip it.
For anything expected to run past six months, set it up before the asset count passes a few hundred. Not because memory is a problem yet, but because the conventions are cheap to establish with twelve prefabs and expensive at four hundred. One practical middle ground: use Addressables for anything content-shaped from the start — characters, levels, audio banks — and direct references for systems and UI. That split holds up well and avoids converting the whole project at once.
2. The build pipeline is a feature
Ask a small team how they make a build and the answer is usually a person and a laptop. That works right up until the person is on holiday during a publisher milestone.
A scripted build — command line, versioned, running on something that isn’t a developer’s machine — is maybe two days of work. It removes an hour of manual packaging from every release, catches platform-specific breakage on the day it’s introduced rather than a week later, and makes the release process transferable to anyone on the team.
This is the part indie teams outsource last and probably should outsource first. Shops selling custom unity game development services get asked for gameplay features and shaders. The higher-value ask is often a week of build, CI, and asset pipeline work, because that work compounds across every subsequent sprint and it’s exactly what a small team never prioritizes for itself. If the build only exists on one machine, the project has a single point of failure that isn’t in anybody’s risk register.
3. Profile on the worst device you support
Editor profiling tells you almost nothing about shipped performance. The editor allocates differently, runs managed code differently, and hides the thermal behavior that decides whether a mobile title still holds 60 frames after ten minutes.
Get a device build profiling loop working early and run it on the lowest-spec target in your support matrix. Once a month is enough at first. The point is catching the trend, not the frame.
The failure mode this prevents is specific and extremely common. Performance work gets deferred to a dedicated optimization phase near the end, and by then the architectural decisions causing the problem — update loops on every object, an unbatched UI, a physics setup carrying more colliders than the design needs — are load-bearing. Performance is far easier to maintain than to recover, and teams that check monthly rarely need an optimization phase at all.
4. Version strategy is a scaling decision
Staying three versions behind feels safe and quietly accumulates debt. Every deferred upgrade adds package incompatibilities, and the eventual jump becomes a multi-week project nobody scoped.
The current picture makes this easier to plan than usual. Unity announced Unity 7 in July 2026 for release in early 2027 and has stated it’s a direct continuation of the Unity 6 line — no project rebuild, no new scripting language — with foundational features shipping through Unity 6.x releases first. By Unity’s own framing, staying current on Unity 6 is the migration strategy.
The version question also shapes who you can bring in later. Any video game development company you contract in year two will quote differently for a project on the current LTS than for one sitting three versions back, because the second quote includes an upgrade nobody planned. The same applies to hiring — developers ramp faster on a version whose documentation matches what they last used. Pick an LTS, stay on its patch line, and schedule the major upgrade instead of deferring it indefinitely.
What Scale Actually Punishes
None of this is about the engine’s capabilities. Unity will render, simulate, and ship a game at almost any scale a small team is likely to attempt.
What scale punishes is the absence of structure — asset loading that was never designed, a build that lives on one laptop, performance measured in the editor, and a version nobody wants to touch. Each is a two-day fix early and a two-month fix late.
The tutorials aren’t wrong. They’re optimizing for hour one. The project that matters is the one still being worked on in month eighteen.
Frequently Asked Questions
When should an indie team move from direct references to Addressables?
Before the project passes a few hundred assets, or as soon as a second developer joins. The trigger isn’t memory pressure — it’s convention cost. Establishing loading patterns is cheap with a dozen prefabs and expensive once scenes across the project hardcode references that all have to change at once.
Is a CI setup worth it for a team of two or three?
Usually yes, at a small scale. A single scripted build running on a spare machine covers most of the value: repeatable releases, early detection of platform breakage, and a process that doesn’t depend on one person being available. Full test automation can wait. A build anyone can trigger cannot.
How often should a small Unity project upgrade engine versions?
Stay current within an LTS patch line continuously, and plan the major version move as scheduled work roughly once per project cycle. Upgrade cost rises non-linearly with how far behind you are, so the deferral that feels cheapest in month four is usually the most expensive decision in month sixteen.