Building Products on the US-Mexico Border

The US-Mexico border is the busiest international land crossing in the world. Over 100,000 people cross the San Ysidro port of entry every day: commuters, students, shoppers, families, and workers moving between two cities that function as one metropolitan area divided by a fence.

Living in this corridor shaped how I build products in ways I didn't appreciate until I moved away. The border teaches you about arbitrage, bilingual design, regulatory complexity, and the economics of serving communities that exist between systems.

The Two-Economy Life

Living between Tijuana and San Diego means operating in two economic systems simultaneously.

San Diego runs on US dollars, US banking, US tax law, and Silicon Valley's startup culture (filtered through Southern California's more relaxed version). Cost of living is high. Salaries are high. The tech ecosystem is mature.

Tijuana runs on Mexican pesos, Mexican banking, Mexican tax law, and a scrappy entrepreneurial culture born from necessity. Cost of living is low. Opportunity is abundant for anyone who can bridge the two sides.

The arbitrage between these systems is obvious and real. A developer earning San Diego contract rates while living in Tijuana has a dramatically different financial position than the same developer living in San Diego. The rent savings alone can be enough to bootstrap a product.

But the arbitrage isn't just financial. It's informational. Living on both sides of the border gives you visibility into two markets simultaneously. You see needs in Mexico that aren't served by US products (language, pricing, cultural mismatch) and needs on the US side that Mexican labor and expertise could serve (nearshore development, manufacturing, cross-border logistics).

This dual visibility is an unfair advantage for product building. You don't need market research to understand cross-border needs. You live them.

Bilingual by Necessity

On the border, bilingualism isn't a skill. It's a survival mechanism. You speak English at work, Spanish at the tienda, Spanglish with friends, and whatever's needed at the border crossing.

This constant language-switching taught me things about product design that monolingual founders miss:

Language affects behavior. Users in Spanish-speaking markets interact with products differently than users in English-speaking markets. Not just the obvious things (text direction, date formats) but the subtle things: tone expectations, formality levels, the role of visual vs. textual communication.

Translation isn't localization. Running your app through a translation API produces text that's technically Spanish but culturally wrong. Localization means understanding that a Mexican user expects different formality than a Spanish user. That "Sign Up" translates differently depending on the context and culture.

Some products shouldn't be bilingual. Comensalaqui needed to be bilingual because its users crossed languages. But an aviation study tool used by Italian pilots studying in English shouldn't be in Italian. It should be in English, because the exams are in English and the technical terminology is English.

Code-switching is natural. Bilingual users don't think about which language they're using. They switch fluidly based on context. Products that force users to choose a language and stay in it feel unnatural to bilingual users. The best bilingual products allow mixing, just like the real conversation.

Regulatory Complexity as Training

Operating on the border means dealing with two regulatory systems for everything. Business registration, taxes, banking, employment law, intellectual property, privacy regulations: everything has two versions.

This was frustrating at the time. In retrospect, it was the best possible training for building products in regulated industries.

When I started building for aviation (an industry regulated by EASA, the FAA, and national authorities) the multi-jurisdictional complexity felt familiar. Different rules in different places. Different compliance requirements. Different user expectations based on which regulatory framework they operate in.

The same skill will translate to any regulated industry I build for in the future. Understanding that rules differ across jurisdictions, that compliance requirements vary, and that "the same service" means different things under different regulatory frameworks isn't something I had to learn. It was something I'd lived on the border.

Regulatory complexity isn't a barrier to entry. It's a moat. Products that navigate complex regulations correctly are hard to replicate. The effort to understand and comply with multi-jurisdictional rules is substantial, but it protects the product from competitors who don't want to make that effort.

The Hustle Culture

The border creates a specific kind of entrepreneurial culture. It's not the "move fast and break things" culture of Silicon Valley. It's more pragmatic, more survival-oriented, and in many ways more honest.

Border entrepreneurs hustle because they have to, not because a startup accelerator told them to. The businesses on the border (import/export operations, manufacturing liaisons, cross-border logistics companies, bilingual service providers) exist because someone saw a gap between two systems and filled it.

This hustle isn't glamorous. Nobody writes TechCrunch articles about the person who built a customs brokerage connecting Tijuana factories to San Diego distributors. But the business acumen (understanding two markets, navigating two regulatory systems, managing two currencies, serving two cultures) is more sophisticated than most VC-backed startups require.

The border taught me to build products that solve real problems for real people willing to pay real money. Not hypothetical problems that might scale to a billion users. Real problems that affect the person standing in front of you.

This pragmatism is now central to how I evaluate product ideas. I don't ask "could this be a unicorn?" I ask "does someone need this badly enough to pay for it?" The border taught me that the second question is the only one that matters for a bootstrapped founder.

What I Carried Forward

I don't know if I'll live on the border forever. My life has already taken me across Italy, and I may end up in other cities. But the border's lessons will travel with me:

Serve communities that exist between systems. Pilots between regulatory authorities. Families traveling between countries. People seeking legal help between income levels and service availability. The gaps between systems are where the most underserved users live.

Build for the arbitrage. Not financial arbitrage, but informational and capability arbitrage. Where one group has a need and another group has the solution, build the bridge between them.

Embrace complexity. Multi-language, multi-currency, multi-jurisdiction products are harder to build but harder to compete with. The complexity is the moat.

Ship pragmatically. Not every product needs to scale globally. A product that perfectly serves a specific community, even a small one, is more valuable than a product that poorly serves everyone.

Stay connected to real users. On the border, your users are your neighbors. You eat at the restaurants you build platforms for. You fly the routes your aviation products serve. This proximity to users is an advantage that scales poorly but matters enormously.

The US-Mexico border is a 1,954-mile line that divides two countries. But for the people who live along it, it's not a division. It's a seam. And seams, if you know how to work with them, are where the strongest connections are made.