Building across the Caribbean, Africa & the US

The Decade Lag: Why the Future Reaches Kingston and Lagos Late

Kenroy George · 2026-10-12 · 6 min read

TL;DR: New technology reaches small and emerging markets roughly a decade after it reaches San Francisco, not because of any law of nature, but because of how product teams prioritize, localize, and comply. The lag compounds: being ten years behind on tools means being ten years behind on everything those tools unlock. The fix is to build for constrained markets from day one, lean on open standards, and prove things in one small market so the next adoption is a copy, not a pilot.

I grew up watching the future arrive late. A product would launch to enormous fanfare, the world would reorganize itself around it, and then, years later, a diluted version would finally work in Kingston or Lagos or St. John's. By the time it arrived, the people who got it first had already moved on to the next thing.

This is not an accident. It is the predictable output of four mechanisms, and once you see them, you can design around them.

Why the lag exists

Market-size logic. Product teams prioritize by revenue. Every roadmap meeting ranks markets by how much money they represent, and small markets rank last by definition. Nobody is being malicious. The spreadsheet simply never sorts a two-million-person island above a three-hundred-million-person continent. So the features ship to the big markets first, the bug fixes land there first, and the small markets wait for the leftovers.

Localization debt. Products built for rich markets carry assumptions baked so deep that nobody remembers making them. The checkout flow assumes a credit card. The address form assumes a postal code. The onboarding assumes a language the team speaks. When those assumptions fail outside the original market, they get filed as edge cases, and edge cases for small markets never climb the backlog. The debt is not paid down. It just sits there, quietly excluding people.

Infrastructure assumptions. Features presume constant connectivity, recent devices, and bandwidth cheap enough to ignore. An app that streams everything works beautifully on fiber in a city with reliable power. The same app on an older phone, on prepaid data, in a place where the connection drops during rain, is not a slightly worse experience. It is unusable. The product team never sees this, because their test devices are new and their office wifi is fast.

Regulatory attention. Compliance work gets done for the big markets first. Legal teams clear the United States and the European Union because that is where the revenue and the risk both live. A small market with its own regulator, its own data rules, and its own licensing regime is a project nobody wants to staff. So the product launches everywhere except the places that would need a conversation first.

The cost is not inconvenience, it is compounding

Here is the part that keeps me up at night. The lag is not a delay in getting a gadget. It is a delay in getting the productivity the gadget unlocks.

A business that gets modern payment tools a decade late spends that decade doing manual reconciliation. A clinic that gets modern records a decade late spends that decade on paper. A student who gets modern learning tools a decade late competes against students who had them the whole time.

Each year of lag does not just cost that year. It costs the growth that would have compounded on top of it. Two regions can start in similar places and end up in different worlds, purely on the timing of when the tools arrived.

Breaking the pattern

The pattern breaks when you stop treating small markets as a porting target and start treating them as the design constraint.

Build for constrained markets from day one. Offline-first is not a feature you bolt on. It is an architecture you choose at the start. The same goes for efficiency: software that runs well on the phones people actually have, that respects expensive bandwidth, that degrades gracefully when the connection does. When you build this way from the beginning, the rich-market version is the easy case, not the other way around.

Use open standards so small markets are not custom work. The reason localization debt never gets paid is that every small market looks like a bespoke project. Open standards flip that. When identity, payments, and data follow standards instead of proprietary formats, supporting a new market becomes configuration, not engineering. The marginal cost of inclusion drops toward zero, and the spreadsheet logic that excluded small markets stops applying.

Prove in one small market so the next adoption is a copy. Small markets have a hidden advantage: you can deploy something real, end to end, with actual users and an actual government, faster than you can schedule a meeting in a large bureaucracy. A working deployment in one Caribbean nation is not a small win. It is a template. The second country does not run a pilot. It runs a copy. That is how small markets go from last in line to first movers.

Why this wave matters more

Every previous technology wave had this lag, and every previous wave was survivable at a distance. You could adopt the web late and catch up. You could adopt mobile late and catch up.

AI is different, because AI compounds human capability itself. It is not one tool, it is a multiplier on every tool, every worker, every institution. A decade of lag on AI is not a decade behind on one product category. It is a decade behind on medicine, education, agriculture, government services, and every business that runs on knowledge work. The compounding that was dangerous in previous waves becomes decisive in this one.

Which means this is the wave where the old pattern has to break. Not eventually. Now, at the start, while the tools are still being shaped.

Where Cari stands

This is why Cari treats the Caribbean, Africa, and the US as one build, not a sequence of afterthoughts. There is no flagship version for rich markets and a stripped version for everyone else. The constraints of the smallest market we serve are design inputs for everything we ship, and the proof we build in one small nation is engineered to be copied by the next.

The future does not have to reach Kingston and Lagos late. It only does when the people building it decide those places can wait. We decided they cannot.

Common questions

Is the lag really about profit, or is it about capability? Mostly profit logic, honestly. The engineering to support low bandwidth, older devices, and local payment methods is well understood. What is missing is the prioritization, because roadmaps sort by revenue and small markets lose that sort every time. Change the economics of inclusion, through standards and shared proof, and the capability follows quickly.

Can small markets really lead instead of follow? Yes, and their size is the advantage. A small nation can go from decision to nationwide deployment in the time a large country spends on procurement. That speed turns small markets into the proving grounds where the template gets built, which is the opposite of waiting at the back of the line.

What can a small market government do right now? Insist on open standards in everything it procures, so it is never locked into a vendor's timeline. Pick one real service and deploy something working end to end, rather than piloting forever. And partner with builders who treat the local constraints as the spec, not as an exception to it.

If you want to see what building for every market at once looks like in practice, read more about what we are building at cari.global/about.