Testing times: Between some IoT code and a hard place) is very real:
In smaller companies and startups the pain can be intense. I remember a job before going to university where I sweated for a week over hardware that stopped working just before a critical demo in the US. It was for a robot toy for a couple of the world's largest purveyors, and no one would have died... except for my employer. We slept under the desks (my landlady thought I must be out doing drugs and summoned scary relatives to hound me) and we tore out our hair, some of which may even have turned grey.
It all turned out to be down to one tiny misplaced wire on our development electronics board, discovered at the 11th hour when rechecking "everything".
We did the demo, the project continued, and my employer lived.
Radbot has suffered similar hardware and software bugs. One case involved a stack overflow. (If only someone could create a Web site for solving problems something similar ... oh wait ...) It lost us a lot of data but had a trivial software fix. Then a very long drawn out code rewrite that took months to nail. That is why I am strongly in favour of extensive (unit and other) tests and CI (Continuous Integration), just as I am for 'bigger' software. Never mind the techie grumbling; the pain can otherwise prove fatal. The increased confidence those tests can provide when refactoring allow much bolder code and functionality improvement. Also fab.
Actively assess risks coming down the pipe. Decide which are to be avoided and which just have to be rolled with. Avoid the pointless ones. It's all part of the fun. Setbacks happen despite the best-laid plans of mice and men. How you then deal with them is key.