Dear @Jardar, we just answered a similar question by @danielm over at [1], so we are humbly pointing you there for an introduction to what we are trying to say here. In short, we are conceiving a medium-sized MicroPython codebase [2] called Terkin for MicroPython [3] for the Bee Observer project, which might well resonate with your questions and requirements. Following up on that, we are happy to answer your specific questions here. To what extent do you split your project into multiple submodules (.py files) Quite extensively, you might want to have a look at the terkin folder over at [4]. To what extend do you use classes vs. simple functions? We are trying to use as much OO techniques as possible. FSM (Finite State Machine) is a common way to implement FW. Do you use this? If FSM to what extend do you use this (just as part of specific logic or as the main structure of your program). Are there any best practice for how to implement FSM in Python? We are not using any FSM mechanics within our codebase yet. Is there any best practice in fault handling? Other important considerations What practices do you follow to harden your code with regards to reliability? As Python itself is pretty strong on exception handling, we are using this extensively. We are not doing anything special here but tried to find a good sweet spot between balancing things. It was important for us not to leave any gaps for unhandled exceptions which would make the program crash completely. Having appropriate logging in place was important for us in order to be able to follow up with the execution and to see what is going on. Logging Python tracebacks within the exception handlers helps tremendously when tracing hard to find bugs occurring after some runtime. Saying this, we are recording this logging output through the UART interface connected to a SBC like the RaspberryPi or BeagleBone in order support the process of detecting respective spurious glitches within the execution flow. We've outlined this at [5]. Enabling the watchdog functionality of the ESP32 is absolutely essential, you would do that with any kind of embedded development project anyway. However, we feel this detail is sometimes underestimated by people just starting with MicroPython development on these devices and give up hope too quickly after experiencing random crashes with their software. We hope this helps to give you at least some insights into the direction of your questions. With kind regards, Andreas. [1] https://forum.pycom.io/topic/3860/proper-structure-of-micropython-package [2] https://github.com/hiveeyes/hiveeyes-micropython-firmware [3] https://community.hiveeyes.org/t/developing-terkin-for-micropython/233 [4] https://github.com/hiveeyes/hiveeyes-micropython-firmware/tree/master/terkin [5] https://community.hiveeyes.org/t/monitoring-and-recording-the-serial-interface-output-of-a-microcontroller-attached-to-an-uart-interface/2430