What kinds of modifications does the client wish to make on their own? Simple ones like changing configuration setting variables, or more complex modifications that greatly change the product’s behavior?
Are you using these Photons in the Particle product console? If so, you’d have to mark the devices as development devices.
DFU is much more reliable than Y-Modem, as Y-Modem has to be used while the Photon is in listening mode and can be interrupted if the application makes use of serial in listening mode. DFU much less likely to be interrupted because the firmware does not run while the Photon is in DFU mode.
As far as simplicity goes, the Y-Modem flasher is included in Particle CLI, and dfu-util is it’s own separate binary.
How will the client be building the firmware? Web IDE, Workbench, Particle CLI, Locally with gcc-arm?
It might be easiest include the dfu-util binary with the firmware and provide a helper script that puts the Photon in DFU mode by setting the serial baud rate to
14400 and then flashes the firmware with dfu-util.
Also, which OS is the client using? The method of automatically putting a Photon into DFU works on macOS, Linux, or Windows.
I have developed firmware for clients who are competent with using the command line. I provide them with a copy of the firmware using GitHub. They can clone the repository to their computer with Git. They can make modifications the the firmware if they please, and use po-util to build the firmware locally and flash it with DFU.
DFU is much more reliable and simple than Y-Modem because it is standalone and can be used without installing Particle CLI first. You can put a Photon into DFU mode without touching the buttons from within a script to create a more pleasant DFU experience.