Two and a half years inside a robot manufacturer — building everything except the robot
My last role was at Standard Robots, an industrial AMR (autonomous mobile robot) manufacturer in Shenzhen, where I was the sole developer for every internal system the company ran: the software that takes a robot from a bill of materials to a shipped, supported machine. I did not write their fleet software and I am not going to claim I did. What I got instead is rarer, and if you build machines yourself it is more useful: two and a half years watching a robot company work from the inside.
What I actually built there
Everything the company ran on that was not the robot. As the only developer on internal systems, that meant the supply-chain platform with its bill-of-materials structures, the CRM that replaced a bought-in product, an expense system, the file-storage engine, and the deployment pipeline. Concretely:
- A middleware layer that made a platform migration cost nothing. The company's systems were wired deeply into DingTalk and needed to move to Feishu. Instead of rewriting every integration, I built a layer that speaks DingTalk's shape upward and Feishu's API downward — file handling, event callbacks, response formats and all. The migration became a one-line switch.
- Deployment from hours to one minute. Ten-plus systems were released by hand, taking an hour to half a day each. I replaced that with scripted, environment-aware deploys behind an internal page.
- A recovery nobody wanted to need. Someone deleted a top-level category in a company system and it went unnoticed for two days. A rollback would have destroyed two days of new data. I read the code to find every affected table, located the moment from the logs, reconstructed state from MySQL binlogs, and wrote an idempotent, reversible repair. All of the lost data came back, with operations still running.
- A faster file store. Replaced the S3-compatible object store with one that handled small files better — over 50% improvement on small-file performance.
Why this matters if you build machines
Those systems are the nervous system of a machine company, so I spent two and a half years reading its whole body. How a configuration becomes a bill of materials. How a model variant multiplies into part numbers. What sales promises and what production can actually ship. Where after-sales calls come from and what information the person answering them wishes they had. Which of those problems get solved with software and which ones people just live with.
That is the part I bring to your project, and it is the part most contract developers do not have. Someone who has only ever written applications will ask you for a specification. Someone who has watched a machine company from the inside already knows why the specification does not exist yet.
The adjacent engineering, stated precisely
Two things people reasonably ask about, answered without stretching. Fleet scheduling: I did not build theirs. I did build a task-dependency scheduler elsewhere that decomposes multi-level dependencies into a directed acyclic graph, detects cycles before execution rather than deadlocking on them, and runs a topological order — structurally the same problem as breaking a composite job into ordered sub-tasks, in a different domain. Device protocols: my hands-on protocol work (Modbus, OPC UA, MQTT, PLC) comes from my own contract work and the demos on this site, not from that job. If you need robot-vendor SDK experience specifically, ask me and I will tell you exactly where the edge of my experience is.
Proof
Named company, named referee, and the letter itself. This is the one thing on the site I cannot have written: the CTO of Standard Robots put his assessment of me in writing and signed it. It names the platform migration middleware, the 80%+ unit-test coverage, and the binlog recovery, and it ends with an offer to verify directly. How to get it →
How to get the letter. Tell me who you are and what you're evaluating; the signed PDF reaches you within 24 hours. If you'd rather hear it from him directly, a call can be arranged — I ask him first, and it usually takes under a week. It's on request rather than published because it carries his name and signature: he wrote it for people evaluating me, not for search engines.
Where else this applies
If you make equipment and you need someone who will not need the shop floor explained to them: interfaces that ship with the machine, device integration, and the internal systems that decide whether a build goes out on time. I have been the person inside that company. I know which questions to ask before writing anything.
If a machine you build needs an interface, a device connection, or data that has to land somewhere else, tell me what it's costing you now. You'll get an honest read on whether it's solvable, and usually something running to look at. Start here →