When My Contractors Started Asking for Dollars I Could Not Quite Send

I started a remote developer talent platform out of an apartment in Palermo, Buenos Aires, the kind of place where the kitchen doubles as the office and the only meeting room is whichever café on Honduras has working air conditioning that day. The premise is unglamorous and durable: there are excellent engineers across Latin America, there are US companies who want them and pay in dollars, and the gap between those two facts is full of friction that someone has to absorb. We match them, we handle the contracts, and we run payouts. That last part, the payouts, is the one I underestimated most when I drew the business on a napkin three years ago. I thought it was plumbing. It turned out to be the building.

For the first year I paid everyone the obvious way, by bank transfer. A US client funded us in dollars, we paid our engineers in their local rails, and I told myself this was solved. Then the requests started, quietly at first and then with a frequency I could not ignore. A senior backend developer in Medellín asked if we could pay him in USDC instead. Then two more in Buenos Aires. Then someone in Lagos who freelanced for one of our clients. My first reaction was the reaction of a person who has watched a long parade of crypto promises arrive and leave: scepticism, bordering on irritation. I did not start a company to take a position on tokens. I assumed they wanted a speculative wrapper and I did not want to be anyone's exchange.

The complication was that the operational case underneath the ask was real, and it kept being real no matter how much I wanted to wave it away. Cross-border wires were taking three to five days to clear, and a meaningful share were failing or arriving short after intermediary banks took their cut, which meant support tickets, frustrated engineers, and me personally apologising for money that existed but had not moved. The engineers asking for stablecoins were not making a bet. They were tired of waiting and tired of watching value evaporate in transit. And here is the part that hit closest to home: the hardest market I had to pay was my own. Paying contractors in Argentina under our FX restrictions is genuinely difficult, and it had already shaped how I thought about everything else. If I could solve dollars-to-engineer cleanly, the local pain was exactly what it would relieve.

So I made myself do the unglamorous thing and treat it as an operations problem rather than an ideology. The piece that reset my thinking was a walkthrough that frames USDC payouts as a payout rail decision and not a crypto bet, and is blunt that you can add it without changing treasury policy by keeping balances in dollars and converting at disbursement. That last sentence did more for me than any whitepaper, because it told me I was not signing up to hold token risk on the balance sheet. The useful question it posed was simple and answerable: can my platform send a contractor a dollar-denominated payout in USDC, then track status, references, exceptions, and accounting entries with the same discipline I already expect from fiat? It also listed the things I had to nail down before launch rather than after, the unknowns I would have happily skipped, who runs AML and sanctions checks, how a failed payout actually gets reversed, what reference data finance receives for reconciliation. I am not a compliance lawyer and I did not pretend to be one; I used the reading to know which questions to put to people who are.

The Argentina layer is where I spent the most care, because it is where the abstract becomes my neighbours. I went back to a guide on paying contractors in Argentina under FX restrictions that treats BCRA and FX handling as items to verify with counsel and providers rather than assumptions to inherit from a sales conversation, and its insistence on a complete contractor file before anyone gets paid is now baked into our onboarding. It made the point that a market can be commercially attractive and operationally premature at the same time, which described my home country with uncomfortable precision. Worker classification, tax-data collection, payout eligibility, evidence retention, all of it had to be in place and owned, with a named person who could approve, pause, or reject a payout when a review fired. It also warned, in the way I most needed to hear, that the common and expensive failure is product assuming a settlement path works, ops building around it, and finance later discovering the exceptions that break everything. I had lived a smaller version of that already. I did not want the larger one.

What I settled on is layered and deliberately boring. We keep our treasury in dollars and convert at the moment of disbursement. USDC is one rail among several, offered where it is allowed and where the recipient actually clears our checks, not promised as universal coverage. Every payout carries one stable lineage from our internal request ID through the provider reference to settlement status, and finance can trace any of them end to end. We allow exactly one controlled retry per payout, and anything still unresolved after that goes to a human instead of looping silently. The compliance gates, KYC, KYB, AML, the tax-document paths, are assigned to owners before a corridor goes live, not improvised once it is.

The strange thing is that the engineers were right and I was right at the same time. They were right that the old way was failing them. I was right to refuse the token framing, because the framing was never the point. What the point turned out to be was the same thing it always is in this business: can you pay people quickly, correctly, and with a record you can defend later. The café on Honduras still does not have reliable air conditioning. The payouts, finally, are something I no longer apologise for.