Creating the image isn't hard, the trouble is the stupid installer never seems to work properly according to their directions on most system that I've tried (primarily Chromebooks, so YMMV). The only surefire method that has worked for me every single time is using dd from the Ctrl+Alt+F2 shell (or one in a logged in account, but then that account gets copied over to the target system) or dd or the 'python-awesome-dd' script from a Linux LiveUSB. If you use dd you probably need to run the fix-grub.sh script from the chromefy repo and the lab folder. There is a short URL for it, curl -L goo.gl/HdjwAZ | bash -s /dev/sda to grab the file and run it assuming you are in a root shell.
You MUST be in Developer Mode if you are attempting to Chromefy an existing ChromeOS device. Then after the Dev Mode changeover wipes the device you should access the system shell (aka VTY) using Ctrl+Alt+F2 (usually the Forward key depending on the age of the device but may also be Refresh or something else, and you might need to hold the Fn key if you have one to get it to emit the F2 keycode). After reading through the installation documentation a few times I noticed that there is a MUCH easier method of Chromefy-ing an existing Chromebook, though I'm not sure whether it will actually update the system kernel, so you may still want to build a custom image if you are trying to enable Android or Linux apps on a much older system that has an unsupported kernel (if uname -a shows 3.x it is too old and you'll want to make an image).
If you are wanting to do something interesting like booting other ChromeOS variants or custom builds or Linux you can do the next steps.
In this shell you'll need to set crossystem dev_boot_usb=1 and optionally crossystem dev_boot_legacy=1 in case you want to boot from a Linux USB (GalliumOS/etc).
Once you have set these flags you can reboot and at the "OS Verification is Off" screen you need to press Ctrl+U to boot from the Chromefy USB.
WARNING: Once you have installed Chromefy, avoid following the directions of Press Space to enable verification because doing this will screw up your Chromefy installation and put your Chromebook in a bad way requiring a stock factory image USB recovery and then switching into Developer Mode and starting from scratch with putting Chromefy on the system again.
NOTE: If you are "converting" an out of support ChromeOS device in this way I would suggest investigating the MrChromebox alternative firmware and possibly disabling Write Protect so you can "permanently" enable the dev_boot_usb and dev_boot_legacy via GBB flags and avoid losing access to booting the Chromefy alternative ChromeOS images which is likely how you'll need to update your system going forward. You can also disable the Press Space to enable because doing this will screw up your Chromefy requiring a stock factory recovery and then switching into developer mode and starting from scratch with putting Chromefy on the system again.
There are several types of storage devices that Chromebooks have available. For early models it was an actual laptop hard drive, then some manufacturers moved to an mSATA drive using eMMC, then some started putting the eMMC onboard (basically making it like a permanently affixed SD card, but when it wears out the system is basically a brick, this has affected some really expensive systems like the Chromebook Pixel 2013 and Chromebook Pixel 2015). Some manufacturers took a smarter route and used the M.2 SATA drive interface, which had the added benefit of making the storage replaceable and upgradeable (good because it is probably the most prone to failure from wear besides the battery). Nowadays lot of newer systems are still using eMMC, but some of the higher end ones have switched over to NVMe, but most are still using flash chips soldered to the board so when it dies your system is useless. A few manufacturers have started making serviceable systems with replaceable M.2 drives again that utilize the SATA or NVMe protocol, these are my personal favorite because they are easy to repair and upgrade.
Running lsblk will show you which type(s) your system has, and if you have an SD or microSD inserted and mounted it will show you some information about that as well.
Writing the image to the system via dd is pretty straightforward, just follow the commands below and fix the of=/dev/sdX to the top level of whatever your desired target device is, maybe /dev/mmcblk0 or /dev/nvme0n1 (if it has a p in it, that is an individual partition, you want the whole device).
The Chromefy scripts and/or ArnoldTheBat have and expect a 4GB ROOT-A partition (partition 3) (they don't use ROOT-B) so if you are using the script against a stock Chromebook where the ROOT-A partition is only 2GB, you need to delete the STATE partition (partition 1), extend the ROOT-A partition, then recreate the STATE partition and format it as ext4. There are several tools that already exist on the system to do this, fdisk/partx/cgpt and resize2fs and resizepart.
You can get a nice (ordered) list of the partitions as they are laid out on disk using cgpt show -q /dev/sda | sort. We need the -q so it doesn't print headers and labels which mess with sort. If we look at this output the awesome thing is both ROOT-A and ROOT-B are after everything else but before STATE which takes the entire rest of the disk, and STATE is simply logged in user data which gets wiped when going into/out of Developer Mode and is easily recreated by logging in to your Google account.
lsblk # This shows the block devices in the system, if you booted from the USB then /dev/sda or /dev/sdb should have a /mnt/stateful_partition entry.
dd if=/dev/sdb of=/dev/sda bs=4M status=progress # This takes a few minutes
# Next you'll want to delete and recreate the /dev/sda1 (STATE) partition to expand it to fill the whole disk
fdisk -l
fdisk /dev/sda
# Next few commands are inside fdisk's "shell"
p # prints partition list in fdisk
d # delete
1 # specifically partition 1
n # create partition
1 # use 1 which is free since we deleted it
# when it prompts if you want to change the signature, say no, because we'll keep the same label and designation, and just format it once we are out of fdisk
w # writes the changes to disk
q # quits the fdisk shell
mkfs.ext4 /dev/sda1 # format so that Chrome can recognize it
# You may need to run the grub_fix.sh from the Chromefy repo since we didn't use the chromeos-install method which doesn't cause the issue it fixes
# Once completed you can type reboot to boot from the internal disk
reboot
ProTip: Mark the USB well and do NOT log into it, just use the VTY noted above, if you do login, drop the custom recovery image onto your USB again from whichever computer you originally created it on (and kept a backup of the custom image on... right?) or you can delete/reformat the STATE partition after the dd copy.