Building a multi-tenant SaaS for an emerging market, what nobody tells you | by Joshua Ajayi | Jun, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

Building a multi-tenant SaaS for an emerging market, what nobody tells you

Joshua Ajayi

6 min read·<br>Just now

Listen

Share

Press enter or click to view image in full size

In my last post I wrote about why I build software products in my spare time while working a full time engineering job. A few people asked the obvious follow up question. What is it actually like to build one of these things, technically, on your own, for a market most tutorials never talk about?<br>So this is that post. It is about building a multi-tenant e-invoicing and compliance platform for small businesses in Nigeria. The architecture, the decisions, the things I got wrong, and the parts no blog post prepared me for, because almost nobody is writing about building for this market.<br>The first decision that shapes everything<br>If you build SaaS for more than one customer, you hit the multi-tenancy question very early. Do you give each customer their own database, or do you put everyone in one database and separate them with a tenant identifier?<br>The internet has strong opinions about this. A lot of the advice quietly assumes you are a funded startup with a platform team and a cloud budget.<br>My instinct, the one I think most engineers have, was database per tenant. It feels clean. It feels safe. Each customer is walled off completely.<br>I built a prototype that way and then did the maths. For a product where I need to keep the monthly cost per tenant extremely low, database per tenant was financially impossible. Every new customer meant another database to provision, back up, migrate and monitor. Onboarding should take seconds, not a provisioning job. I would have spent more on infrastructure than I could ever charge.<br>So I rebuilt it on a shared database with a tenant identifier on every relevant table. Every query carries the tenant filter. The isolation lives in the application layer, enforced consistently rather than by physical separation. It is less glamorous and it puts more responsibility on your code, but it scales to hundreds of tenants on one modest server. For the market I am serving, that tradeoff is the entire reason the product is viable.<br>The lesson: the safest architecture on paper can be the one that kills your product before it launches. Pick the model that matches your unit economics, not the one that feels tidiest.<br>Tenant routing is a problem you only notice once you have tenants<br>Each business on the platform gets its own subdomain. That sounds trivial until you try to make it work. You cannot manually configure a route every time someone signs up. The system has to resolve any subdomain dynamically, map it to the correct tenant, and load that tenant’s context before a single line of business logic runs.<br>I handle this with wildcard subdomain routing. One DNS record, one certificate and one server configuration cover every current and future tenant. A request comes in, the host header is read, the subdomain is extracted, the tenant is resolved, and from that point the whole request is scoped to that tenant. Get this wrong and you either leak data between customers or you turn onboarding into a manual chore. Get it right and a new customer is live the moment they sign up, with no intervention from me.<br>Payments are where building for an emerging market really diverges<br>This is the part nobody writing about SaaS in the West has to think about, and it consumed more of my time than anything else.<br>In a mature market you reach for one well documented payment provider, drop in their SDK and move on. That is not the reality here. I ended up integrating two different local payment gateways, partly for coverage and partly because relying on one felt risky. The documentation gaps meant a lot of trial and error against live sandboxes. Webhooks arrive late, arrive twice, or occasionally do not arrive at all, so I had to build reconciliation into the design from day one. Every payment event is treated as something to verify, not something to trust. Idempotency is not an optimisation here, it is survival. If your system cannot safely receive the same webhook three times, you will eventually credit someone twice or not at all, and in invoicing software that destroys trust instantly.<br>There was also a harder lesson. Some integrations I wanted are simply gated behind local business registration requirements, and no amount of clean code gets you past a compliance gate. Building for an emerging market means accepting that regulation shapes your roadmap as much as engineering does.<br>Compliance is a data modelling problem before it is a legal one<br>An invoicing platform in a regulated market does not get to treat compliance as a feature you bolt on later. Tax identifiers, document numbering, audit trails, the exact shape the authorities expect data in,...