The Fishball Deal
If you've eaten fishballs in Singapore, you've probably eaten Ha Li Fa's. They make BoBo, the brand sitting in every supermarket freezer. In June they became my customer, and for the next five weeks I was both the deal owner and the engineer who built what I'd sold.
At Voltade we've started running enterprise deals this way: one person is the DRI and the deployed engineer at once. Leonard and I sit in the sales conversations together (I wrote about what those rooms taught me), but once the deal is scoped, the person who signed up for the outcome is the person writing the code. No handoff, no solutions engineer translating for a delivery team.
The discovery was the part that would have died in a handoff. Ha Li Fa runs on-prem SAP ECC6 across three entities, two in Singapore and one in Malaysia. Their B2B customers order over WhatsApp and email, in Chinese and English, with shorthand like repeat orders and "same as last week but double the fishballs". Any scope written by someone who wasn't going to build it would have flattened all of that into "WhatsApp ordering integration" and the project would have found the truth the expensive way, three months in.
Because I was writing the scope for myself, it stayed honest. The work order covered two agents: a B2B agent that takes orders and chases receivables through statements of account, and a B2C rewards agent where customers upload receipts and OCR does the match-back. Five-figure engagement, IMDA grant scheme, four-month timeline.
Then I built it. 28 commits, solo, from the fourth of June to the seventh of July. A channel adapter for Moobidesk, their existing messaging layer. Order parsing that handles typos, ambiguous quantities, and Chinese shorthand. And the part I found most interesting: rejection paths that behave exactly like SAP would.
The temptation with an AI layer in front of a legacy system is to be smarter than the system. If SAP would reject an order for a credit hold, the agent could see it coming and quietly route around it. I chose the opposite. The agent's confirmations and rejections mirror what SAP does, because the ops team's mental model is SAP's behaviour, and an agent that surprises the ops team gets switched off. Deployment safety is mostly this kind of decision, not jailbreak defence.
The last commit in the repo is the live verification record: the production run-through, with the operational gotchas written down next to it. I've learnt to treat that as part of the deliverable. A deployment you haven't watched work in production is a demo with better hosting.
Six decision docs and a handover file came out of the build. Not because anyone asked for documentation, but because the next person to touch this system will not have been in the discovery calls, and the decisions only make sense with the reasoning attached.
The honest trade-off: this model doesn't scale past the number of people who can do both jobs. It has a bus factor of one per deal, and my calendar is the bottleneck. But for deals this size, the compression is worth it. Every requirement went from the customer's mouth to the code with zero telephone game, and when something broke in UAT there was no meeting to decide whose ticket it was.
We've since closed COURTS on a similar shape, and a string of smaller work orders behind it. Still early to call it a repeatable motion. But so far, the deals where I build what I sell are the ones that go live.