Working From Panama, Building for the World

It's 7am in Chiriquí. The volcano province in the west of Panama, where I'm from — green mountains, coffee farms, the kind of quiet that city people pay for. My laptop is open, a US team is just starting to stir three hours and a couple thousand kilometers away, and I'm pushing a deploy to a system that will be used by people who will never know it was built from here.

I've been doing some version of this morning for ten years. Remote work from Panama for companies in the US and beyond — from a tech support headset early in my career to architecting an AI product today. And in that decade I've learned that "remote-first" is a phrase that means something very different depending on where you're sitting when you say it. From a San Francisco suburb it means you skip a commute. From the periphery — from a country most of your teammates couldn't place on a map — it means something else entirely. I want to tell you what it actually feels like. The pride, and the honest tradeoffs.

The Timezone Is a Feature, Not a Bug

Let's start with the thing nobody mentions because it sounds too simple: Panama is on Eastern Time. No daylight-saving shuffle, ever. We just sit on EST year-round while the US clocks bounce around us.

This is a quiet superpower, and I don't think people appreciate how much of one. A brilliant engineer in much of Asia or Eastern Europe is working through the night to catch a sliver of US overlap, or living permanently offset from the team that pays them. I overlap a full US business day. When my CTO has a question at 2pm his time, I'm at my desk. When something breaks during US business hours, I'm awake and caffeinated, not blearily logging in at 3am.

A normal weekday from Panama (EST)
──────────────────────────────────
 7:00  Deep work — team still asleep, zero pings
10:00  US east coast online — overlap begins
12:00  Standup / real-time collaboration
 3:00  US west coast fully online
 6:00  Wind down as the team keeps going west

For remote talent in Latin America, the timezone alone is a structural advantage over most of the planet. You're close enough to be present and far enough to get hours of uninterrupted deep work before the pings start. I do my hardest thinking in those quiet early hours, before a single Slack notification has fired.

Async Writing Is Survival, Not Etiquette

On a co-located team, sloppy communication gets patched in the hallway. Somebody's confused, they swivel their chair, the gap closes in thirty seconds and nobody notices the breakdown ever happened.

I don't have a hallway. When my teammates are heads-down or asleep, what I wrote down is the only version of me in the room. A vague PR description doesn't get rescued by a desk-side chat — it just sits there, blocking, costing hours, until our windows overlap again. Distance turns every small communication failure into a measurable delay.

So I learned, out of pure necessity, to treat writing as a core engineering skill rather than overhead. PR descriptions that explain the why and not just the what. Decision docs that let someone act without me. Status updates precise enough that nobody has to wait twelve hours to ask a clarifying question. The async-writing discipline that companies now preach as "remote best practice," I learned the hard way, because on the periphery it's not best practice. It's the difference between contributing and being a bottleneck.

The funny thing is it made me a better engineer everywhere, not just remotely. Forcing yourself to explain a decision clearly in writing is a debugging tool for your own thinking. Half the time I write the doc and realize my plan was wrong before anyone else even reads it.

The Loneliness of Being the Only One

Here's the part that's harder to put on a LinkedIn post.

For a lot of people in my orbit, I'm the only senior AI engineer they've ever met. There's no local crowd of people doing exactly what I do that I can grab coffee with and say "hey, is this how you'd architect this?" The peer group that an engineer in a tech hub takes completely for granted — the hallway expertise, the meetup down the street, the friend who already solved your exact problem — mostly isn't there.

You compensate. The internet is the great equalizer; I have access to the same papers, the same open source, the same communities as anyone in any hub. But access isn't the same as proximity. There's a particular flavor of isolation in being the one who has to figure it out, because there's no one nearby who already has.

It cuts the other way too, and that part I love. Being the only one means I get to be the one. I run Waldo's Code Lab, a free coding school for kids and teens here, partly for exactly this reason — so the next kid from a mountain province who's curious about how this stuff works doesn't have to feel like the only one for as long as I did. If I'm going to be a local rarity, I'd rather use it to make myself less rare.

The Infrastructure You Plan Around

Let's be honest about the unglamorous stuff. Bandwidth and power are realities you architect your day around in a way a SF engineer never thinks about.

The cities — Panama City, David — are solid. But "solid" still means I keep a mobile hotspot within arm's reach, because the day an ISP decides to have an outage will inevitably be the day of the big launch. I think about power continuity. I've taken important calls tethered to my phone on the side of a road. None of this is a crisis — it's just planning, a layer of operational paranoia baked so deep into my routine that I forget it's there until a teammate is baffled that I have three internet connections.

Representing More Than Yourself

There's a weight to this that took me years to name. When you're one of the few, you're not only representing yourself in that standup. Fairly or not, you're a data point about an entire region's talent.

I've occasionally had to prove competence across a distance that carried quiet assumptions — about where "real" engineering comes from, about what someone working from Panama can be trusted to own. Not often, and rarely stated out loud. But it's there, in the background, and you feel it.

I've made peace with it by deciding to treat it as fuel rather than insult. Every system I ship, every problem I solve, every clean piece of architecture I hand off is a tiny argument that Latin American engineers belong at the center of how the world's software gets built — not at the edges, not as the cheap option, but as peers. I get to make that argument with my work, every single day. That's not a burden I resent. It's a privilege I'm proud of.

Why It's Worth It

A decade in, here's what I know. I get to live where I'm from — close to family, to the mountains of Chiriquí, to a culture I love — and still build at the frontier of AI for teams anywhere in the world. The internet erased the geography that would once have forced me to choose between the two.

Remote-first, lived from the periphery, is not a lesser version of the SF experience. It's a different one, with its own real advantages — the timezone, the deep-work mornings, the writing discipline distance forces on you — and its own real costs — the isolation, the infrastructure planning, the occasional weight of representing more than yourself. I wouldn't trade it.

It's 7am in Chiriquí. The team is waking up to a deploy that went out clean while they slept. They probably won't think about where it came from. But I will. I always do.

---

Building a distributed team, or working remotely from Latin America and want to compare notes? Get in touch. I've been doing this from Panama for a decade and I'm always glad to talk shop with people on the periphery.