Building for LatAm: What the Data Forces You to Rethink

Nearly half of Mexico’s population is unbanked.

When you first encounter that statistic, it rearranges everything you thought you knew about building software products. Because the entire SaaS playbook — the one that dominates tech Twitter, Y Combinator demo days, and Silicon Valley conference talks — assumes a credit card at signup.

In a country where half the people don’t have a bank account, a subscription model with a Stripe checkout is not a business plan. It’s a fantasy.

The Subscription Illusion

The default monetization model in tech is elegant in its simplicity: user signs up, enters credit card, gets charged monthly. Churn is managed. MRR is tracked. Investors understand the metrics.

This works beautifully in markets with near-universal banking access. The US, Canada, most of Western Europe — places where a debit card is as unremarkable as a phone number.

In Mexico, it’s a filter that eliminates half your addressable market before they’ve even seen your product.

This forces you to think differently from day one. Not “how do we add a payment method later?” but “how do we build something valuable for people who may never connect a credit card?”

The answers get creative fast: cash payment integrations (OXXO, convenience stores), prepaid models, WhatsApp-based onboarding (because everyone has WhatsApp, even without a bank account), freemium tiers that deliver real value before any transaction occurs.

These aren’t compromises. They’re architectural decisions driven by the material reality of your users.

LatAm Is Not a Monolith

One of the mistakes I made early on was thinking “LatAm” was a single market. It’s not.

Chile has near-universal banking. Argentina has a population that understands financial instruments (out of necessity — when your currency devalues constantly, you learn about inflation hedges). Brazil has Pix, a government-built instant payment system that leapfrogged traditional banking infrastructure. Colombia has a thriving digital payments ecosystem.

And Mexico has a deeply rooted culture of microbusinesses — the tienda de la esquina, the family laundromat, the street vendor who does more daily transactions than some SaaS companies. These businesses run on cash, trust, and WhatsApp. They’re not “underserved by technology.” They’re operating in a system that most technology wasn’t designed to serve.

Understanding these differences changes what you build. A product that works in Santiago may be irrelevant in Oaxaca. The infrastructure, the habits, the trust models — they’re all different.

The iPhone Bubble

Here’s a bias I notice consistently among colleagues building from San Francisco: they design for iPhones.

This seems reasonable when your beta users are other founders, VCs, and tech workers — people who overwhelmingly use the latest Apple hardware with fast WiFi. But it creates a profoundly skewed sample.

The majority of people in the majority of the world do not use iPhones. They use mid-range Android devices with 2-3 GB of RAM, on cellular connections that fluctuate between 3G and unstable 4G. They share devices within families. They’re conscious of data usage because their plans are prepaid and metered.

When you design for that reality, your engineering priorities shift dramatically:

Performance isn’t a nice-to-have — it’s accessibility. A 5MB JavaScript bundle that loads in 1.5 seconds on a MacBook Pro takes 15 seconds on a $100 Android phone over 3G. Those 15 seconds are the difference between a user and a bounce.

PWAs become a first-class architecture, not a fallback. Progressive Web Apps that work offline, install without an app store, and run efficiently on low-spec hardware aren’t a compromise — they’re often the optimal solution. No Play Store approval process. No mandatory updates that eat storage. Just a URL that works.

Server-side rendering matters again. When the client is weak, you push work to the server. This isn’t a regression to the pre-SPA era — it’s an engineering decision driven by the constraint that your users’ hardware is the bottleneck, not your backend.

Material Reality Over Idealism

I want to be clear: this isn’t about dismissing Silicon Valley builders. I’ve learned enormously from their approach — there’s a freedom in how they think about product that’s genuinely inspiring. The willingness to imagine something that doesn’t exist yet and then build it from scratch is a muscle that the Valley develops better than anywhere else.

But there’s a complementary muscle that emerging markets develop: building within constraints. Not “move fast and break things” but “move carefully and make it work for everyone.”

Both perspectives are valuable. And in the age of the internet, where your users can be anywhere, both are necessary.

The engineer in San Francisco who builds a beautiful iOS app for American users is solving a real problem. The engineer in Mexico City who builds a PWA that works on a $80 phone over a spotty connection is also solving a real problem. The best products — the ones that truly scale globally — are built by teams that understand both.

What I Carry From This

Every technical decision I make now passes through a filter that my LatAm experience installed:

  • Who can’t use this? Not “who’s our target user?” but “who are we accidentally excluding?”
  • What’s the worst connection this needs to work on? Design for 3G. Celebrate when it’s fast on 5G.
  • Does this require a bank account? If yes, you’ve cut your market in half in some of the fastest-growing economies on earth.
  • Can this run on a shared device? Multi-user households are the norm, not the exception.

These aren’t LatAm questions. They’re global questions that LatAm forces you to confront earlier and more honestly than most markets do.

And that’s the gift of building here: the constraints don’t limit your thinking. They sharpen it.


Diego Jiménez Vergara — AI Infrastructure & DevOps Engineer. Building from Mexico City for users everywhere.