Which Unity decisions are hard to reverse?
Every Unity project starts with a template picker and a short list of settings nobody argues about. Some are trivial to change in month six; others are not, and the New Project dialog does not tell you which is which.
A workable test is what reversing the decision would cost in Unity terms: re-authoring materials and rebaking lighting, re-serializing every prefab and scene, or editing every place the code samples input. Anything that fails that test belongs on the day-one agenda. Anything that touches a single system can wait until you get there.
Render pipeline and color space
Unity ships more than one render pipeline, and materials, shaders and post-processing are pipeline-specific. A custom shader written for the Universal Render Pipeline does not drop into the High Definition Render Pipeline. Switching pipelines mid-project means re-authoring materials and relighting scenes, which is art time, not engineering time.
Comparing pipelines on their merits is a separate question from this one, and not what this piece is for. What setup requires is that the answer gets recorded along with its reasons: the target hardware it assumes, the lighting and material fidelity the design depends on, and any dependency that removes the choice. A package or native plugin you cannot replace that only supports the Built-in pipeline settles the matter regardless of preference.
Color space carries the same weight. Linear and gamma produce different results from identical materials and lights, so flipping it late changes the look of everything and invalidates lighting work already done.
Do you need the new Input System?
Unity has two input paths: the legacy Input Manager and the Input System package. The legacy manager is still present and needs no package setup, so a throwaway keyboard-and-mouse prototype can start there without ceremony. The question is whether that code will survive into the product.
Choose the package deliberately if the project involves XR controllers or hand tracking, control rebinding for accessibility, or several input devices at once for local multiplayer. Retrofitting means editing every place the code samples input, plus the UI event system, so the size of that change grows with the amount of gameplay code already written.
The path to avoid is picking neither. If half the project samples the legacy manager and half uses the package, with both enabled, input behavior can differ by device and the resulting bugs are awkward to reproduce.
Scale, units, and the physics you inherit
Unity’s convention is one unit to one meter, and the default physics values assume it. That reaches further than it looks: import scale for models from a modeling tool or from CAD in millimeters, character controller speeds, camera planes and physics tuning are all calibrated against it. Author at a different scale and everything downstream compensates for it, and rescaling a finished scene later changes physics behavior and can break animation root motion.
For AR, VR and training simulation the rule is stricter, because the headset renders in real-world meters and the user’s own body is the reference. A room at the wrong scale can read as wrong to the person standing in it. Fix the convention in the asset specification before the first delivery arrives.
Repository setup: the reversible parts and the rest
Two editor settings get cited as make-or-break for a Unity repository: Asset Serialization set to Force Text, which keeps scenes and prefabs diffable and mergeable, and Version Control Mode set to Visible Meta Files. Both are current Unity defaults, and both can be changed at any time in Project Settings, where switching serialization simply re-serializes the assets. They are worth verifying rather than agonizing over, and the case that calls for a check is inheriting an older project whose settings differ.
It is worth being precise about what the second setting does, because it is easy to describe backwards. Version Control Mode controls whether .meta files are hidden or visible in the file system. It does not control whether Unity creates them: a .meta file carrying an asset GUID is generated for every asset either way. What reaches the repository is decided by what your .gitignore excludes, which is a different decision entirely.
The items in this area that are genuinely awkward to reverse are these four:
- A .gitignore that excludes Library, Temp, Logs, obj and build output, so generated files never enter history. Pulling them back out afterwards means rewriting it.
- Git LFS configured for textures, audio, video and model files before the first commit, since moving existing history into LFS rewrites the repository for everyone who has cloned it.
- Unity’s merge tool registered, so scene and prefab conflicts can be resolved rather than hand-edited or discarded.
- A scene structure using additive scenes or prefab variants that keeps two people out of one file, which is harder to introduce once the scenes are large.
Target platform, scripting backend, and how content gets into the build
Leaving the target platform open is what quietly shapes the other answers. A mobile GPU or a standalone headset brings tile-based rendering, specific texture compression formats, memory ceilings and stereo rendering settings. Moving content authored for a desktop build onto a standalone headset late is closer to rebuilding it at the art level than porting it.
The scripting backend follows the platform. IL2CPP is required on some targets, including iOS, and ahead-of-time compilation with managed code stripping can break code that leans on runtime reflection or dynamic code generation. Check platform support before adopting a package or native plugin.
Then decide how content reaches the player. Direct references are the simple path and a reasonable answer for an app that ships whole. Anything in a Resources folder ships in the build whether or not it is used. Addressables give you remote content, patching and finer control over memory, and add a build and hosting pipeline someone has to operate. If content must change without shipping a new build, settle that early, because converting the loading strategy late touches every asset reference.
What you can safely defer
Treating every decision as urgent is its own failure mode. Analytics, interface polish and the final art direction can wait. The entity-based, data-oriented path is a large commitment; if the project is not bound by updating very large numbers of objects each frame, the standard GameObject approach is the simpler option. Localization is deferrable as long as user-facing strings stay out of code from day one.
Multiplayer is different. Network authority, ownership and state synchronization run through gameplay code, so retrofitting them rewrites the parts that matter. If shared sessions are even a possibility, decide up front whether the design assumes an authoritative server.
None of this needs a heavyweight process, only a short document written before the first sprint recording the pipeline, the color space, the input path, the scale convention, the repository settings, the target platform and the content strategy. Where nobody can say why these were chosen, they are easier to change by accident than on purpose.
Related service: Related service: Our Unity development page covers the Unity work we take on, if a build is coming up and you want to talk it through.
Related service: Unity development services.