Building Scalable Web Apps for African Startups: What the Stack Looks Like
Infrastructure choices that work in Lagos or Kampala are different from what works in San Francisco. Here's how we think about the stack.
When we take on a web application project at Zyntel, the first conversation is always about context: who uses this, where do they use it, and what does failure look like? The answers shape the architecture before a single line of code is written.
Frontend: performance is not optional
A 3 MB JavaScript bundle that takes 8 seconds to parse on a mid-range Android device is not a minor inconvenience — it's an unusable product. The median smartphone in Uganda is 2–3 generations behind what developers in Europe or North America test on. We optimise aggressively: code splitting, lazy loading, minimal dependency footprints, and server-side rendering for meaningful content on first paint.
Our default frontend stack is Astro for content-heavy sites (as you're seeing here) and React or SvelteKit for interactive applications. Both produce minimal JavaScript by default and let us add interactivity where it matters rather than shipping a full SPA for every project.
Backend: close to the data
Latency matters. Running your application server in us-east-1 when your users are in Nairobi adds 200–300ms to every request — before your code has done anything. We deploy to African regions where available (AWS af-south-1 in Cape Town, or closer via Cloudflare's edge network) and use Railway for simple deployments that don't require a DevOps team to maintain.
For most startups at early scale, a PostgreSQL database with sensible indexes, a well-structured API, and a CDN for static assets will outperform a complex microservices architecture that's harder to debug at 2am. We start simple and add complexity only when the data proves it's needed.
Payments and auth: use what's already trusted
Users in East Africa have strong preferences: M-Pesa in Kenya, MTN Mobile Money in Uganda, Flutterwave cards across the region. Trying to introduce unfamiliar payment methods is a conversion killer. We integrate with payment providers that already have user trust in the specific market — not just whatever has the nicest API.
Authentication should feel familiar too. Phone number + OTP performs better than email/password for many East African users, particularly in markets with high mobile penetration and lower email usage.
The honest answer about AI
AI features are genuinely useful when they solve a specific problem for the user. They're a distraction when they're added because "every app needs AI now." We use AI where it earns its place: automated data extraction, intelligent form completion, anomaly detection in datasets. We skip it where a simpler rule-based approach does the same job with less complexity and cost.