You win the work. I do the software. Your client doesn’t need to know I’m involved.
Most small integrators run into the same 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 sent to an upstream system, and there’s no software person on the team. Hiring someone for one job doesn’t make sense, and turning the job down costs you the customer. I’m the third option.
White-label, properly#
I don’t want your customer. I’ll work under your name, in your repo, with your branding on the screens. I can join calls as one of your engineers, or stay off them entirely, whichever is easier. I won’t contact your client before, during or after the project. If you’d rather have that as a contract term than a promise on a web page, send me your clause and I’ll sign it. That’s a sensible thing to ask for.
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 equipment whose only documentation is a printed booklet and a phone number.
- Upstream connectivity you can sell. When your client asks whether the line’s data can reach their ERP or MES, you don’t have to turn it down. I’ve built systems on that side too (bills of materials, work orders, batches). I look at which system it is and tell you plainly what it takes, so you won’t need to find another vendor for it.
- Software that exists but doesn’t work. This includes the increasingly common case of an AI-generated HMI or device prototype that demos well but that nobody can deploy or extend.
How remote work holds up: I build against a simulated machine#
The usual objection to a remote software person is fair: I can’t touch your equipment. So I build a simulator of the device first, with the same command and telemetry contract and fault modes I can trigger on purpose. The interface and logic are finished and tested against it well before the real machine reaches the floor. When the machine arrives, what’s left is wiring and calibration, not working out how it behaves.
That’s also why my timeline doesn’t depend on your shipping schedule. With this approach, the software is usually ready before the hardware. There’s a public example of the pattern you can run in about a second.
Where my layer ends#
The software I deliver doesn’t implement safety interlocks. E-stop, guard doors and light curtains belong in a safety relay or a rated safety controller, which keeps working even if my code is wrong. I build the layer above that, gate it carefully, and write the boundary into the contract. You already know this. I’m stating it so you know I know it too.
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 answer: whether it’s doable, what concerns me, 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 give you a fixed-price quote for free.
- Fixed scope, milestones, something running early. You see working software at the first milestone. Every delivery comes with documentation and a handover, because you’re the one who supports it afterwards.
- The code is yours. Full source, no lock-in, no dependency on me. I keep the rights to framework pieces I wrote before your project, and you get a perpetual licence to use them. I’ll put that in writing.
Awkward questions, answered up front#
- “What do you charge?”
- Fixed scope, tiered quotes. My current client came back after the first project for a second one, now in progress, at five figures. If your budget is tight, say so in your first message and I’ll tell you right away whether it fits.
- “We handle software in-house.”
- Good, then you don’t need me for the day-to-day work. Call me for the overflow week, or for the job nobody on the team wants to own.
- “Can you send some references?”
- A signed CTO letter, available on request within 24 hours. He’s also willing to take a call.
- “Where are you?”
- Shenzhen, China. In practice I’m working while you sleep and still at my desk when your morning questions come in. Your project runs on my servers in the US and your data stays there; I keep no standing access to your network, and any remote session is one you start and can watch.
- “Will you go around me?”
- No, and I’ll sign a non-solicit to that effect. Your client relationships are yours, and repeat work from you is worth far more to me than a single job from them.
- “What if you disappear?”
- Fair question, and everyone says they won’t. So the work goes into your repository from the first week, 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.
- “Can you talk to my customer’s engineer?”
- Yes, in writing. I spent nearly two years on the internal-systems side of a robot manufacturer, so I can usually work out what a production manager means even when the problem is described badly.
How you can check all this#
A signed letter from the CTO of the AMR manufacturer where I ran every internal system is available on request. It carries his name and title, and he offers to verify it directly. The demo library has 5 runnable projects, and they run on your laptop without any credentials. And a note on how to check work you can’t see gives you a checklist you can use on anything I deliver.
Have a job you’d take if the software side were covered? Send me the client’s email and the device manual, and I’ll tell you within a day whether I can take it on. Start here