Nearly two 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. 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 and supported machine. I did not write their fleet software and I won’t claim I did. What I got instead is less common, and more useful if you build machines yourself: nearly two years watching a robot company work from the inside.
What I actually built there
Everything the company ran on apart from the robot. As the only developer on internal systems, that meant the supply-chain platform with its bill-of-materials structures, a CRM that replaced a bought-in product, an expense system, the file-storage engine, and the deployment pipeline. Specifically:
- A middleware layer that made a platform migration nearly free. The company’s systems were tied deeply into DingTalk and had to move to Feishu. Instead of rewriting every integration, I built a layer that looks like DingTalk to the systems above it and calls Feishu’s API below, covering file handling, event callbacks and response formats. The migration came down to changing one line.
- 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 data recovery. Someone deleted a top-level category in a company system, and nobody noticed for two days. Rolling back would have wiped two days of new data. I read the code to find every affected table, located the moment of deletion in the logs, rebuilt the state from MySQL binlogs, and wrote an idempotent, reversible repair. All of the lost data came back while operations kept running.
- A faster file store. I replaced the S3-compatible object store with one that handles small files better, improving small-file performance by more than 50%.
Why this matters if you build machines
These systems are how a machine company actually runs, so in nearly two years I saw most of it. How a configuration becomes a bill of materials. How one model variant turns into a pile of part numbers. What sales promises compared with what production can ship. Where after-sales calls come from, and what the person answering them wishes they knew. Which of those problems got solved with software, and which ones people just put up with.
That’s what I bring to your project, and most contract developers don’t have it. A developer who has only written applications will ask you for a specification. Someone who has worked inside a machine company understands why the specification doesn’t exist yet.
Related experience, stated precisely
Two things people reasonably ask about, answered without stretching. Fleet scheduling: I didn't build theirs. Elsewhere I built a task-dependency scheduler that turns multi-level dependencies into a directed acyclic graph, detects cycles before execution instead of deadlocking on them, and runs tasks in topological order. Structurally that's 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 specifically need experience with a robot vendor's SDK, ask me and I'll tell you exactly where my experience ends.
Proof
Where else this applies
If you make equipment and need someone who doesn't need the shop floor explained: interfaces that ship with the machine, device integration, and the internal systems that decide whether a build goes out on time. I've been that person inside a machine company, and I know which questions to ask before writing any code.