50% of the time, it's the wrong engineer. That's James Watling, talking about a staffing agency (not us!) that his new company had been using when he joined. Here's the backstory. When James was at Early Day, a seed-stage startup, he had no recruiter budget and a roadmap bigger than the US salaries he could afford. He hired 4 engineers through @remotelyworkshq. 18+ months later, when Early Day was acquired, all 4 Remotely engineers were still there, so he brought them with him. Post-acquisition, in his new role, he inherited a relationship with an outside staffing agency. "We would ask for a senior engineer, and the next day we have one, but 50% of the time that's not a great fit." Over the following months, the agency's roster went from 15-20 engineers down to the 6 or 7 worth keeping. When James moved to his next company, he brought Remotely with him again. Today, he's a Senior Engineering Manager at @spring_health, the mental health platform on TIME's 2026 most influential companies list. Across all 3 companies, that's roughly 20 of our engineers over 4 years. Here's the part I didn't expect. Matt McKenna runs the electronic health record system at Spring Health. Different team, different manager, and he had the objection I hear constantly: "My biggest concern when hiring someone that is technically a contractor is that there's going to be less of an ownership mentality." He's right to ask. Most of my industry has earned that suspicion. So Spring Health didn't take our word for it. Every candidate we shared went through the same hiring loop Spring Health uses for full-time, US-based employees. Engineering manager screen, coding assessment, system design, pair programming, a conversation with the product team. Same sequence for engineers in Argentina, Mexico and Brazil as for anyone in New York or the Bay Area. Nobody has left since the first hire in July 2025. 3 engineering managers at Spring Health now hire this way, on separate teams, and they got there on their own. I'm proud of what this says about proof. Anything we say about our own vetting reads as marketing. It should. What I can't manufacture is a company running its own process and reaching its own answer, or a manager attaching his name to us 3x when nothing made him do it. That's the only kind of proof I'd trust, from the other side of the table.

Two lines on a resume get all the attention. Logo & years. The number I look at on a fintech resume? The ratio. I want to know how much of the system they owned, divided by how many people were holding it with them. You're buying whether someone has owned a system where being wrong meant a regulator, not a postmortem. Take for example Nubank that runs 21,000 production databases across 3 countries with a fraud and credit-risk stack that logs every model decision for auditor reconstruction. 5 engineers for 21,000 databases. Zero critical incidents in 12 months. A central bank watching. That's the ratio. Yes, the ratio is the automation. Somebody had to design it, ship it into a regulated environment, and trust it enough to sleep. That's who you want. Most US fintechs buy their way out of this with headcount. Rational move. But nobody on that team ever finds out what they could have carried. We run a version of this at @remotelyworkshq. 30 people supporting 500+ developers. Roughly 16 to 1. I know what that ratio costs and what it selects for. So when I read a fintech engineer's background now, the logo is the last thing I look at. Ask what they were responsible for, divided by how many of them there were. That number is the one that travels.

We published what the engineers in our network earn. Medians and ranges, by seniority and by role. @RemotelyWorksHQ does this every year. Most of what you'll find for LATAM engineering is a single average with nothing behind it, and an average is close to useless when you're setting a band. Senior and lead are 93% of our network, so those two rows are solid. Take it into your next hire or comp conversation. If your own numbers say something different, I'd like to hear it. We'd rather publish this than have you guess. Get our salary guide ordnl.link/Iqf6Z8w

Capital One just paid $5.15 billion for Brex. Brex was founded by two Brazilians, Henrique Dubugras and Pedro Franceschi. Before they turned 21, they sold their first payments company, Pagar dot me. A year later, they started Brex. When I tell this story to US fintech CTOs, the room usually goes quiet. But the founders aren't the point. The real story is the ecosystem they came from. Brazil's payments infrastructure was years ahead of the US. PIX processes more daily transactions than any comparable US payment system. Open banking went live in 2022. Card issuing was rebuilt for mobile years before most US fintechs started paying attention. That generation is now in senior roles. That's the talent pool we hire from at @remotelyworkshq We don't send generic LATAM developers. We maintain a fintech bench mapped by sub-vertical (payments, lending, ledgers, and fraud), tech stack, and seniority. Every engineer works full-time US hours. So when a fintech needs someone who's already built payments infrastructure, we're not starting a search. We already know who has done it. The question I still hear is, "How do I know these engineers are at the same level as senior US hires?" The answer is what they've already built. The same ecosystem produced a generation of engineers who built payment systems at scale. Many are still in São Paulo, Belo Horizonte, and Recife. Most US fintech startups just haven't looked there yet. P.S. Hiring senior fintech engineers? DM me and I'll share a few sample profiles from our bench.

Our agent surfaced three engineers we'd never have found on our own. Picking the right one was still on us. A health benefits company needed a senior AI engineer. We pointed our agent at the role and asked it to surface candidates from our network. A few minutes later, three names came back, the kind most hiring teams would scroll right past. One had built multi-agent systems for a healthcare insurer. One had launched AI products generating six figures in revenue. The third was running multi-agent systems in production, with their own evaluation framework and monitoring stack. On paper, they had almost nothing in common. One read more like a researcher than an engineer. Another had a title no recruiter would think to search for. Their experience was scattered across different projects, industries, and career paths, which is exactly why a keyword search buries people like this. Surfacing those names is the easy part. It's what the agent is good at, pulling the non-obvious people out of a pile a human would never finish reading. Then the real work starts, and that part is still human. Has this person actually operated AI systems in production? Worked with customer data, handled the failures, managed the costs, improved things over time? And do they genuinely want to build at THIS company, or are they just available? Five years ago, ML experience on a profile was enough to get your attention. But now, experience on paper isn't the same as proof they've operated it. A profile tells you what someone has touched. Whether they can run it in production? That's the judgment we built @RemotelyWorksHQ to make.

Everyone expected AI to shrink engineering teams. I keep seeing the opposite. The teams hiring through us want fewer junior engineers now and more senior ones. Across our last 40 placements, almost every new role is a judgment call, not a coding task. Judgment is the bottleneck now. Knowing what to build. Catching the AI when it's confidently wrong. Engineers already work alongside agents merging more than a thousand pull requests a week. Judgment isn't getting automated. Volume works because senior engineers are validating, catching errors, and making calls agents can't. A Bay Area zip code never created that judgment. Take Aiwyn. They do AI accounting automation, backed by KKR and Bessemer. A company building AI built their team with 25 engineers from LATAM. They doubled engineering in 12 months, more than half of those hires through us. Their CTO put it simply: "Location doesn't matter. We just don't think about it." I run @RemotelyWorksHQ, a network of AI-enabled engineers already proven at fintechs and unicorns across São Paulo, Buenos Aires, Mexico City, Medellín, and Bogotá, many of them are Claude Certified Architects. The move back to the office is real. Some of our customers are going hybrid right now, pulling people back to the desk. But they make the exception for top remote talent in LATAM. The senior engineers they can't replace stay exactly where they are. Even the companies bringing everyone else back keep these people remote. The premium pays for a SF zip code. The judgment was always somewhere else.

We put ourselves on a map with our competitors. Most companies wouldn't do that. But if you're evaluating hiring partners, that's exactly what you need. Marketplaces. Vetted networks. IT services companies. EOR platforms. AI sourcing tools. In-house hiring. Nearshore LATAM providers. I referenced Human Cloud's market map and rankings. What stood out once everything was laid out: Almost every category is crowded. And almost every model runs on the same hidden mechanism: a margin you can't see. The developer's compensation is one number. The client pays another. The gap sits somewhere in the middle. There is a small category built differently. Transparent pricing. The developer keeps their full salary. Long-term embedded teams instead of constant turnover. There are four companies in that category. We're one of them. That doesn't mean it's the right answer for every situation. If you need a freelancer for a two-week sprint, the map points you toward a marketplace, not toward us. That's the honest takeaway. Who did I miss?

A pleasure to be part of the Eveywhere Ventures community and have you on our cap table!

We used to joke that if Olapic ever worked out, we’d start an investment vehicle called Siesta Ventures. Tagline: “You work while we sleep.” Back then, building a startup was hard (spoiler: it still is). So we imagined a future where we’d trade the chaos of operating for the ease of angel investing. Fast forward - Siesta is real. We’ve been investing in early-stage startups for the past 8 years now (50+ to-date), and we have a new investment vehicle, Clara.Ventures, that focuses on the immigrant entrepreneur. But… the sleep part hasn’t quite materialized. We are operators, and we love building.

Ben Horowitz says the thing that defeats people is expecting life to be fair. Hard to argue with that. I am trying to transmit to my kids that when given lemons, they should make lemonade and all that jazz. We are still working on the concept; it will probably take years to sink in. A lot of stuff happens in building a company that has nothing to do with merit: An investor pulls the term sheet at the 11th hour You lose a deal because someone had a connection you didn’t. A competitor with a weaker product gets funded because the timing lined up for them. You can spend days trying to make sense of it, but it doesn’t change what’s on your desk the next morning. The only real move is deciding what you’re doing next. Fix the thing that broke. Replace the person who left. Adjust the plan that stopped working. Keep going. You don’t have to like the problems, but you need to enjoy solving them. You just can’t let them turn into a story that slows you down. "What should I do now?” is usually a helpful question.

I’ve never liked the term “remote engineer.” It makes it sound like there’s a separate species of developer who codes from a distant planet, instead of someone who happens to live a planet ride away, but sometimes in almost the same timezone. What we’ve seen while building @RemotelyWorksHQ is that geography was never the variable that made the difference. Context was. Engineers in Latin America have worked at unicorns. They’ve shipped at scale. They understand startup chaos, legacy code, and the 2 am bug that nobody else can reproduce. The only difference is they do it from Medellín or Buenos Aires instead of Austin or Denver and with better coffee. We’ve been conditioned to see “remote” as a compromise. In practice, it’s been the opposite. Time-zone overlap, shared culture, English fluency, and startup experience have made our teams more aligned, not less. The engineers we work with don’t need “managing.” They need context, trust, and good problems to solve - same as anyone else. Maybe it’s time we drop the label altogether. They’re not remote engineers. They’re engineers.

We've left millions on the table over the past 5 years. And I'd do it again. Take a simple example: one full-time developer at 40 hours a week. Standard staff augmentation model: Developer makes $4,550/month Agency bills customer $13,000/month Agency keeps $8,450 65% take rate Our model: Developer wants $6,625/month Developer gets $6,625/month We charge a flat fee on top It's the same role with same hours. But the customer pays less, developer earns more, and we earn less. When I tell people this, they look at me like I set money on fire. They're right. If we ran the opaque model, we'd be doing 2-3x the revenue right now. But that doesn't sit well with us. There are a lot of problems with the traditional model, here's the one about retention: the moment a developer becomes valuable for your company, the model starts working against you. The developer might be really good but it's hard to reward them. If you try to give them a raise, it turns into a negotiation with a third party. If you try to promote them, more problems arise. Basically, everyone’s incentives are pointed in different directions. We removed all of it. Developer and company negotiate directly. Raises go 100% to the developer. Bonuses go 100% to the developer. Our fee stays the same whether they make $5k or $15k a month (and we have many making more than that) Hiring managers finally know where their money goes. We left money on the table. But because we built it tech-enabled from the start, in the age of AI, we can provide an excellent service with a margin that incumbents cannot replicate. When you're not trying to squeeze maximum value out of year one, things are more fun. Customers send us their friends. Developers stick around. We're cash flow positive and growing fast. No regrets leaving money on the table.

Success leaves its own kind of scar tissue. When people ask why we’re so disciplined about profitability, I tell them it’s muscle memory. Our first company, Olapic, was a success by most definitions. We raised $20M+, built a big team, and eventually got acquired. But behind those headlines were the months of board decks, fundraising cycles, and the constant pressure to keep the curve going up and to the right. You learn how much energy it takes to feed that machine. How every new dollar raised comes with expectations that change how you think, hire, and move. You get used to optimizing for speed even when you can feel the wheels shaking. We burned a lot of cash every month; we were never profitable pre-acquisition. That experience leaves a mark. It’s why, at Remotely, we built the business to be profitable early. Why we care more about transparency and alignment than about chasing a valuation. It’s not fear. It’s a kind of muscle memory, and it's amazing how fast one can grow being profitable. We are killing the rule of 40, but that is for another time. When you’ve already been through the game once, you start playing for long-run instead of headlines.

When we started Remotely, one of the first things we agreed on was that we weren’t going to play the same game as everyone else in our industry. Most staff augmentation firms charge opaque markups and hide what portion of the customer’s payment actually reaches the developer. We went the other way. We decided every dollar a customer pays should be split transparently: the developer sees exactly what they make, and our fee sits separately on top. It sounds simple, but it changes everything. It means you can’t hide behind margins. You have to build real operational discipline. You have to earn efficiency through process and technology. Running a low-take-rate business forces you to think like an engineer: every small inefficiency compounds. Every extra layer of coordination, every redundant tool, every unnecessary handoff eats into what would be someone else’s salary. It also changes the kind of trust you build. Customers know exactly what they’re paying for. Developers know exactly what they’re earning. There’s no guessing, no suspicion, no “what’s the real rate?” Slack message after the call. Five years in, we’ve proven you can build a transparent, low-margin business in a high-margin industry -- and still grow profitably.