First, let me say that I've met Pete Lewis (he was the "tour guide" when I visited SparkFun a few months ago). I have great respect and appreciation for his work, and that of all the folks at SparkFun!

I have more than 25 years of experience in the field of Test Engineering, ranging from "operator" in a factory (that's what got me to go back to school and get my Engineering degree) to doing both "hardware system architecture" and "system level software" on testers that sold for several million dollars apiece. (As one example, every true Intel Pentium ever made was tested on a machine I helped design.)

Based on all that experience, I have a few comments, mostly for anyone (including the folks at SparkFun) using one of these in an "industrial" setting. Please remember, this is not an "attack" on anyone -- it's just I've learned a few things in all my years of testing, and can enourage others to avoid the mistakes I've made.

My first thought is that if you use something like a Raspberry Pi 3 Model B+, you can use its WiFi capabilities to connect to your LAN (Local Area Network). By setting up a "designated directory" somewhere on a file server, it is possible to have the tester/programmer to at least verify that it's got the correct version of the code to be loaded. (Actually downloading from the server each time it's turned on is probably a bit much, but with not much programming you can do something like compare a "version_number" file locally to one on the server, and if there's a mis-match either automatically down load it or flash the lights to tell the operator that there's a potential problem.)

My next thought is that you should ALWAYS do some "datalogging". You might not need it now, but it can come in handy in the future. It is a LOT easier to log data now than to not have "historical" data in the future. This can be as simple as just writing a line to a CSV file on the aforementioned server for each device tested/programmed. It should, at a minimum, include the tester/programmer's name (and maybe a serial number for the tester/programmer), a time/date stamp, the version level of the software on the tester/programmer, the version level of software being loaded into the target, an operator ID, and a result code. It is also a very good idea to keep track of "retries", i.e., when something went wrong on the first attempt to test/program a given target and the operator decided to try it again.

I've been thinking about a way to obtain an operator ID for a "headless" tester/programmer. What I'd be inclined to go with would be a USB drive (aka a "thumb drive") with a file in it's "root" directory that contains the operator's employee number or name or some other identifying info. I did think about using the Blue Tooth capabilities of the 3 B+ to either talk to an ID chip in the badge or the operator's cell phone, but those seemed like they might be a bit flaky if there were too many people in the vicinity.

I'm also a big fan of things having a "machine readable serial number". One way that you might do this would be to designate four bytes at the end of the boot loader to be a uint_32 serial number (we can only dream of building more than 4 billion Red Boards!). The tester/programmer would have to keep track of what the last serial number used is, so that it can insert it. By the way, this could be an easy way to take care of most of the "retry" detections: the tester/programmer could try to read the serial number to see if it "makes sense" (i.e., is less than or equal to the last serial number used, and it's non-zero) -- then it's likely a "retry" unless the last attempt failed in writing the serial number.

This brings me to my one suggestion for enhancing the hardware: add a second capacitive touch pad labeled something along the lines of "retry", so the operator has a way to indicate to the tester/programmer that it's an actual retry. Although this does NOT likely make any difference on the procedure that the tester/programmer will use to test/program the target, it DOES make an important difference in the datalogging.

You could, of course, use Ethernet to connect any of the tester/programmers to the LAN, but this makes for yet another cable to hook up and clutter the work area.

There is a lot of important information to be had from analysing the aforementioned data: First, it can quickly alert you that there might be problems when you have too high a failure rate on testing/programming. Second, a good idea can be had of how much labor you can expect to expend to test/program a planned production run. Another thing that can be done, if the devices are serialized, is that if a failing device is returned from a customer, the exact lot can be identified, and if there are several in the same lot, you may be able to say "XYZ sent us a bad batch of XXX parts".

Obviously, if you're just tinkering with this on your own "bench", or using it, say, in a school lab, you can ignore all my comments!