Building for the slow internet

---

There is a conversation that happens in every technology team that builds for Nigerian users, usually around the third sprint, usually when someone opens the product on their personal device for the first time outside the office. The conversation goes: why is it so slow?

The answer is almost always the same. The team built for the connection they had, not the connection their users have. They tested on fibre. Their users are on 4G that behaves like 3G after 6pm. They optimised for a MacBook Pro on a Lagos Island office network. Their users are on Tecno handsets in Surulere, in Aba, in Kano, in Jos. The product works perfectly in the environment it was built in. It fails in the environment it was built for.

This is not a Nigerian problem. It is a discipline problem.

Performance is not a feature to be added after the product is built. It is a constraint to be designed around from the first line of code. A performance budget — a hard limit on the total weight of a page, the time to first meaningful paint, the JavaScript that must execute before a user can interact — is not a technical nicety. It is a product decision. It says: we have decided that the person on the slow connection is as important as the person on the fast one. We have decided that our product exists for both of them, not just the one who looks like us.

At TEK NAIJA, we call this building for the slow internet. It is one of the four informal principles that govern how we build.

The slow internet is not slow because Nigeria lacks infrastructure. Parts of Nigeria have excellent connectivity. The slow internet is slow because connectivity in Nigeria is uneven — fast in some places, at some times, for some people, and unreliable everywhere else. A product that only works on the fast internet is a product that works for a fraction of its intended users. A product that works on the slow internet works for everyone.

The discipline this requires is specific. Images must be served in modern formats — AVIF, WebP — at the sizes actually needed, not at the resolution the designer exported from Figma. JavaScript must be minimal on first load; every kilobyte of code the browser must parse before rendering is a millisecond of waiting that someone on a congested network cannot afford. Fonts must load without blocking the page; the text must be readable before the typeface arrives. Server responses must be fast; database queries must be indexed; caching must be deliberate.

None of this is exotic. It is standard engineering discipline applied with the Nigerian user in mind rather than the San Francisco user.

LEGTEK NAIJA, our digital dispute resolution infrastructure, was built under these constraints from the beginning. A party filing a claim, a counsel uploading a submission, a neutral joining a hearing — any of these actions might be performed on a mobile device in a city where the network is under load. The platform cannot afford to be slow for them. The proceeding does not pause because the connection is poor. The architecture must compensate for the environment rather than assume it away.

The same principle governed the STK Industries platform. A procurement officer placing a bulk order for yam exports, a logistics coordinator checking a shipment status, a compliance officer reviewing KYC documentation — these users are not always on fast connections, and the platform must work regardless. The performance budget was set at the beginning of the project, not retrofitted at the end.

This is what it means to build for Nigeria rather than in Nigeria. The geography is the same. The discipline is different.

Performance budgets are a Lagos question before they are a Vercel question because the constraint that matters is not the one imposed by the infrastructure provider. It is the one imposed by the user's reality. Vercel is fast. Lagos is uneven. Build for Lagos.

---

Joseph Ugbede Ejeh is a Director at TEK NAIJA LTD.

15 March 2026

---