I started our my games development career as a low level programmer and moved to a lead programmer in the technology department and then founded a games studio where we wrote our own engine and released several games.
My role meant I had to make the correct business decisions using my technological knowledge and as much as writing engines and technology ran through my blood, the right answer was to switch to Unity. The man cost of constantly writing all the technology we need and then maintain it was too great compared to the ever diminishing wins we got from it.
One scary part of this decision was then hiring Unity programmers and initially having these new hires knowing more about Unity than I did. I needed to make calls about what is possible, time frames, performance, meeting client requirements etc without being an expert of the most important part of our development process. Luckily we made the right hires and it didn't take so long until I had been converted to the Unity mindset. Initially I would always be saying "oh well I would normally tackle this in this way" and wanted to coerce Unity to work in a familiar way. But overtime this disappeared and I became increasingly interested in working out the best way to achieve things in the "Unity way" which ultimately returns much greater dividends.
The first game we released, called Bloody Zombies came out last year on Steam, Oculus, Xbox One, PS4 and Nintendo Switch. It can be played in VR (on supporting platforms) and non VR. It is multiplayer, both in the sense of multiple people on one machine (you can do things like 1 VR player and 3 TV players or 4 TV players) but also online multiplayer (where you can do one player per machine or any combinations say one tv player on one machine playing with 1 VR players and 2 tv players on another machine).
VR meant we had to maintain a constant frame rate (60 or 90 depending on platforms). We used stereoscopic rendering, offloaded graphics work to a special job system. We used custom shaders (the game is like a graphical novel so outline shaded characters) we have spherical fog, lightmaps, FXAA, colour post processing etc.
Online multiplayer meant a packet system, ability to establish connections, matchmake, a system for making parts of the game world communicate, handling so many error cases, etc.
For variety of platforms meant lots of variety on the rendering, controller input etc.
For Switch it meant the ability to play on Switches close to each other on a different protocol to online multiplayer.
I shudder to think how much time and effort this would have been without Unity. I suspect we would have needed several new hires working on platform specific tech, full time network engineers, at least one full time graphics dev, at least one full time audio dev, one full time physics dev, the list goes on. Instead we had 3 programmers (which includes me where my time was heavily comprised being a founder/MD/Tech Director/coffee maker) and whilst the other programmers were very good they had both only graduated a few years prior.
Did Unity solve everything? Absolutely not. We hit loads of huge problems with Unity. Without help of their engineers some problems we would never have been able to solve. We helped Unity fix lots of issues at their end. We found issues that could have been solved trivially without Unity. We felt the strain of waiting days for an answer to a mission critical Unity issue. But in the grand scheme, the pain was less than 10% of what we would have experienced doing it with our own engine.
My big worry was not doing "tech" anymore, but that simply isn't true. But instead of having to write loads of architecture and code to even be able to write the "real" tech, instead you can write the more interesting stuff. For shaders you just write the shaders, not the system for passing in shader constants and setting up vertex streams. Post effects is similar. Coming from a strong engine/Tech background has been massively helpful, whilst unity trained hires are amazing it has been really useful for our studio for me to be able to get into the lower level to add feature, fix stuff, debug stuff, etc.