For automation integrators, machine builders and robotics companies
You win the work. I do the software. Your client never has to know I exist.
Most small integrators have the same shape of problem: you can wire a panel, program the PLC and commission a line, and then a job needs an operator interface, a device driver, or data pushed somewhere upstream — and there's no software person. Hiring one for that is absurd. Turning the job down is worse. I'm the third option.
White-label, and I mean it
I don't want your customer. I'll work under your name, in your repo, with your branding on the screens. I'll join a call as your engineer if that's easier, and I'll stay off it entirely if that's easier. I won't contact your client, before, during or after. If you'd rather that be a contract term than a promise on a web page, send me yours and I'll sign it — that's the correct instinct and I won't be offended by it.
What I take off your plate
- Operator interfaces. Touch panels and desktop HMIs a floor operator can actually run. One interface configured per machine model, rather than one per machine.
- Getting the device to talk. Modbus, OPC UA, MQTT, serial, vendor SDKs — including the equipment whose documentation is a printed booklet and a phone number.
- Upstream connectivity, as your selling point. When your client asks whether the line's data can reach their ERP or MES, you can say yes. I've built the systems on that side too — bills of materials, work orders, batches — so the answer isn't a maybe you have to go source.
- Software that already exists and doesn't work. Including the increasingly common case where a prototype was generated by AI, demos beautifully, and cannot be deployed or extended by anyone.
The thing that makes remote work: I build against a fake machine
The usual objection to a remote software person is real — I can't put my hands on your equipment. So I don't pretend otherwise. I build a simulator of the device first: same command and telemetry contract, with fault modes I can inject on purpose. The interface and the logic get finished, exercised and tested against that, long before the real machine is on the floor. When it arrives, the work left is wiring and calibration, not discovery.
This is also why my timelines don't depend on your shipping schedule. Software finishing before hardware is the normal case here, not the lucky one. There's a public example of the pattern you can run in about a second.
Where my layer ends
Software I deliver does not implement safety interlocks. E-stop, guard doors and light curtains belong in a safety relay or a rated safety controller — hardware that keeps working when my code is wrong. I build the layer above that, gate it hard, and write the boundary into the contract. You already know this; I'm saying it so you know that I know it.
How a first job usually goes
- You send me the messy version. The client's email, the device manual, a photo of the panel. I don't need a specification; if you had one you probably wouldn't need me.
- Within a day you get a straight read. Doable or not, what I'd worry about, and roughly what it takes. If it's still genuinely uncertain, that's what the three-day sprint is for. If you already know the scope, I'll quote it fixed-price for free.
- Fixed scope, milestones, something running early. You see working software in the first milestone, not the last. Every delivery comes with documentation and a handover, because you are the one who has to support it afterwards.
- The code is yours. Full source, no lock-in, no dependency on me. I keep the rights to my own pre-existing framework pieces and you get a perpetual licence to them — I'll put that in writing rather than leave it vague.
The awkward questions, answered first
| You're thinking | Straight answer |
|---|---|
| "Where are you?" | Shenzhen, China. In practice that means I'm working while you sleep and I'm at my desk when your morning questions arrive. Payment runs through Payoneer with a proper invoice and a W-8BEN, and if your procurement needs a corporate entity to contract with, I can arrange that before we sign. |
| "What do you charge?" | Fixed scope, tiered. My current client's first project was $3,000; the second, in progress, is $10,000. If your budget is tight, say so in the first message and I'll tell you immediately whether it fits. |
| "We handle software in-house." | Good — then you don't need me for the steady state. Call me for the overflow week and the thing nobody wants to own. |
| "Can you send some references?" | A signed CTO letter, on request, within 24 hours. And he'll take a call. |
| "Where are you?" | Shenzhen, China. In practice that means I'm working while you sleep and I'm at my desk when your morning questions arrive. |
| "Will you go around me?" | No, and I'll sign a non-solicit saying so. Your client relationships are the only asset you have that I couldn't replace even if I wanted to — and repeat work from you is worth far more to me than one job from them. |
| "What if you disappear?" | Fair question, and "I won't" is what everyone says. So: work lands in your repository from week one, milestones are small enough that you're never more than a couple of weeks from a working state, and the handover document is written as we go, not at the end. |
| "Can you talk to my customer's engineer?" | Yes, in writing, and I'm better at that than at small talk. I've sat on the internal-systems side of a robot manufacturer for two and a half years, so I know what a production manager means when they describe a problem badly. |
Why you can check any of this
A signed letter from the CTO of the AMR manufacturer where I held every internal system is available on request — with his name, his title, and his own offer to verify directly. Nineteen public repositories run on your laptop without credentials. And there's a note explaining how to check work you can't see — take that checklist to anything I deliver.
Need to show this to a partner or a colleague? There's a one-page PDF built for forwarding.
Got a job you'd take if the software side were covered? Send me the client's email and the device manual — I'll tell you within a day whether I can carry it. Start here →