My style as well. I would add one thing which I call “critical dimension analysis.” Try to identify the main customer driver for the domain you’re in (could be cost/performance/something entirely different), and invest at little more in that technical area (while still keeping things relatively simple). That will give you a simple yet efficient stack for the domain you’re in, which will be a great base for taking your product forward.
Totally agree about keeping things simple. When [it] hits the fan on Sunday afternoon, you can probably root-cause the issue fairly quickly and get things running again. And, you don't have to wait for that *one guy* who went on vacation Friday to come back a week later to show you how things were configured.
I've used a microscope, a JTAG cable and a MIG welder on the same project on the same day.
Here's the thing though - I like simplicity. I like stuff to be simple. I drive a 25-year-old Range Rover because it's simple, and because if it breaks I can fix it quickly with simple tools. I bring this simplicity to the stuff I build - lowest parts count, easiest to get parts, comprehensive manual.
Build your software stack as though you expect to have to fix it in a boggy field on a pissing wet Sunday afternoon with a hammer and a roll of sticky tape, because that's exactly what you're going to have to do.