I worked on a kiosk management system that needed to integrate with a JCM iVizion bill acceptor using the JCM ID008 protocol over USB. The project required backend APIs, a frontend management interface, hardware communication, and a controller strategy that could reliably support the payment workflow.
I started by gathering requirements from stakeholders and investors, then designed the system architecture around the expected workflow. I also worked directly with JCM documentation and support to understand the hardware integration requirements.
My original plan was to build the controller in Node. Based on my previous hardware and controller work, that was a reasonable direction to investigate. But as the project moved deeper into the JCM iVizion integration, the USB controller requirements created constraints that made the Node approach impractical at the time. The controller path depended on DLL behavior that was better suited to a different implementation stack.
That was the key technical decision point.
Instead of forcing the original plan because it was the plan, I changed course. I brought in a C# developer to handle the controller constraints while the Node APIs and Angular frontend work continued successfully.
This project had a mixed result, but that is part of why it matters. Not every useful technical story is a perfect launch story. Sometimes the most important engineering judgment is recognizing when the first approach is no longer the right one.
The useful work was in the discovery, the architecture, the API and frontend foundation, the hardware research, and the willingness to adjust when real-world constraints appeared.
This project is a good example of technical course correction: knowing when to keep going, when to change tools, and when to bring in the right expertise before the wrong path burns too much time.
