One of the hard learned lessons as a beginner is this:
You’ve spent a lot of time on your project, like weeks or months - but then it won’t build, or it crashes on the device, or it will render only 30 frames … per minute.
The “but it works in the editor” fallacy
It is all too easy to assume that whatever works in the editor will work just the same way in the build. That is not the case!
Setting up your work environment means you need to test end-to-end, particularly if we’re talking mobile devices, standalone VR headsets, consoles, or the Web as target platforms. Before you create anything, you ought to make a simple test scene, build it, deploy it, and run it on the device to work out any issues in that process.
This gives you confidence that you should be able to, at any time, repeat that process. If you cannot go through this process, perhaps you don’t have the device or the license or the money to purchase the device, there is absolutely no point in going forth with that project. You cannot develop in the dark!
Keep making builds
Repeat making builds often enough to ensure you catch any new issues as early as possible, when they are still fairly easy to narrow down and fix. If you wait too long, multiple issues can accrue which makes it all the harder to interpret each individual issue.
The issues can be plentifold. You may be relying on a feature or script that’s just not compatible with the target platform. Or tanks the framerate. Or won’t even load because it consumes far too much memory for a restricted platform.
Speaking of which: the most restricted platform you can ever run into with Unity is without doubt a WebGL app that ought to run on mobile, specifically iOS with its ~500 MiB browser tab memory cap.
Build how often?
How often is “often enough”? As general guidance I would recommend at least once after every major change. This could be a new game feature, or integrating a new asset, or designing a level or GUI.
You will need to test daily on a device when you work on device-specific functionality. Don’t get fooled by simulators - those do not accurately represent the actual device’s behaviour such as gyrometers, VR hand tracking, NFC, GPS, and similar. These are things that need to be fine-tuned to the hardware, the actual hardware, and varying hardware (eg models, vendors) too!
All of this needs to run perfectly on the targeted end user device so this is where you ought to spend a lot of testing time on. Possibly half the development time and more if you work on an innovative design, technically challenging features, or when you are adding lots of assets.
Lesson learned
Back in the day, around the 2000s, I was working on my second Gameboy Color games. A BMX riding game. We put a lot of effort into this. Tony Hawk was all the rage at the time. That game was primed for success even on a handheld.
Alas, we spent most of our development time working with PC emulator that allowed us to test our work instantly. It also made us design the controls towards a PC keyboard’s level of responsiveness and pinpoint accuracy. When we were finally able to get ahold of the EEPROM burner and spent like an hour or so exporting and flashing the cartridge (every time!) we had to realize that the controls were mushy.
The game was shunned for its inaccurate controls as we didn’t have enough time to fix the controls that late in the project. Nor had we any idea how to fix it - this should have been an early prototype telling us to move the design to a different direction, away from twitch-control skill-based to a more forgiving input scheme.