The ask sounded simple. The system behind it wasn't.
The assignment was to configure GL-iNet routers for digital-signage fixtures being deployed into large retail environments. The routers needed to connect reliably, support analytics and reporting, and be provisioned in a way that could scale beyond a developer's desk.
I did not come into the project as a networking or router specialist. The work began with discovery: understanding the hardware, firmware, configuration model, status lights, deployment environment, failure modes, and what the production team would actually need.
Learn the domain while building the model.
I used documentation, hands-on experiments, and AI tools including ChatGPT, Gemini, and Claude to accelerate domain learning. The goal wasn't to have an AI “solve the router.” It was to shorten the distance between an unfamiliar technical domain and a useful mental model I could test against real hardware.
- Researched GL-iNet/OpenWrt behavior, firmware versions, configuration options, networking, and recovery paths.
- Repeated reset/flash/configuration cycles roughly 100 times during local testing.
- Bricked a few routers along the way — useful failures that exposed recovery paths and edge cases before deployment.
- Worked with teammates who understood the retail fixture environment to connect the networking problem to the actual installation context.
Provisioning as a system, not a one-off configuration.
I built an Ubuntu-based flashing and configuration server connected through a network switch. The workflow could provision multiple routers sequentially with minimal operator supervision and inject the settings needed for the deployment.
I also designed the approach with future hardware and firmware changes in mind, so the process was not tied to one moment in the life of one router SKU.
Production assumptions had to survive a real store.
After local testing, I went into local Best Buy stores with a coworker and validated the workflow in the environment where the fixtures would actually operate. Questions from IT and the project team exposed additional requirements, which went back into the system before retesting.
That field loop mattered. A router that behaves perfectly on a developer's network is not evidence that a retail deployment will behave perfectly.
The best support ticket was the one that never happened.
The final deliverable included documentation detailed enough for the manufacturing/supplier team in China to recreate the flashing environment and operate the process independently.
I later learned that the process had been used for thousands of deployed routers. The more important result to me was that the solution transferred knowledge: the system could keep working even when I wasn't in the loop.
The technology was new. The work pattern wasn't.
This project is a compact example of the pattern that has followed me through my career:
- Start with ambiguity. Figure out what problem is actually hiding inside the request.
- Learn fast. Build enough domain understanding to make good technical decisions.
- Prototype against reality. Test assumptions with hardware, users, stores, and constraints.
- Design beyond the demo. Think about versions, operators, recovery, scale, and handoff.
- Enable the next person. A system isn't finished if it still depends on the person who invented it.