+## Safety Considerations
+
+You probably don't want to "brick" your keyboard, making it impossible
+to rewrite firmware onto it. Here are some of the parameters to show
+what things are (and likely aren't) too risky.
+
+- If your keyboard map does not include RESET, then, to get into DFU
+ mode, you will need to press the reset button on the PCB, which
+ requires unscrewing the bottom.
+- Messing with tmk_core / common files might make the keyboard
+ inoperable
+- Too large a .hex file is trouble; `make dfu` will erase the block,
+ test the size (oops, wrong order!), which errors out, failing to
+ flash the keyboard, leaving it in DFU mode.
+ - To this end, note that the maximum .hex file size on Planck is
+ 7000h (28672 decimal)
+
+```
+Linking: .build/planck_rev4_cbbrowne.elf [OK]
+Creating load file for Flash: .build/planck_rev4_cbbrowne.hex [OK]
+
+Size after:
+ text data bss dec hex filename
+ 0 22396 0 22396 577c planck_rev4_cbbrowne.hex
+```
+
+ - The above file is of size 22396/577ch, which is less than
+ 28672/7000h
+ - As long as you have a suitable alternative .hex file around, you
+ can retry, loading that one
+ - Some of the options you might specify in your keyboard's Makefile
+ consume extra memory; watch out for BOOTMAGIC_ENABLE,
+ MOUSEKEY_ENABLE, EXTRAKEY_ENABLE, CONSOLE_ENABLE, API_SYSEX_ENABLE
+- DFU tools do /not/ allow you to write into the bootloader (unless
+ you throw in extra fruit salad of options), so there is little risk
+ there.
+- EEPROM has around a 100000 write cycle. You shouldn't rewrite the
+ firmware repeatedly and continually; that'll burn the EEPROM
+ eventually.