I'm curious on what the value of a frontend would actually be on this kind of project and where it is in the engineering lifecycle. I've worked in the same spac

I'm curious on what the value of a frontend would actually be on this kind of project and where it is in the engineering lifecycle. I've worked in the same space on instrument control software (microfluidics, synthetic biology) and I feel like what you would gain for, as an example, putting a slider on a flow rate is of minimal use to the development of the instrument, especially in an ad-hoc iterative environment. The engineer who is writing this software and building the system in tandem will be able to express most of their experimental/engineering needs via a CLI tool and something that visualizes instrument state and sensor readings. For example, I've gotten quite a bit of mileage out of throwing Grafana as a graphing interface and then using ipython to essentially have a REPL to control logical subsystems, such as a pump or a motor. This allows you to interrogate the empirical limits of your system without having to spend time centering divs or caring about button placement. This is only true if the engineer is the intended end user of the system. As you scale out and include other disciplines in the project you do have to consider the user interface as the window into the instrument. I've played with the automatic GUI element generation from parsing the underlying control code before. I think its a fun bit of meta problem solving, but I've always ended up in a corner that requires some sort of bespoke tool or widget to solve a tricky problem arising from the scientific domain. I think you might be fine if all you are doing is controlling a syringe pump or similar, but as the experimental needs become complicated you'll end up re-writing the control interface as a deliberate experience and toolbox.