Solutions

Built for the people who build here.

Here is what we are offering, in one paragraph: a backend you can start in an afternoon, that fits the way apps in Africa are actually used and paid for, that you can test and verify rather than take on trust, and that you can leave with your data whenever you like. Below is who that is for, and what works for each of them today, with the gaps named.

Start building What people build

By team

Who it is for, in the order we are serving them.

A two-person team ships in order, so we chose an order where each group makes the next one easier.

Mobile-first startups

You are building for people whose phone number is their identity and whose data is expensive. You need sign-in, a database, files and live updates to exist before you have a hundred users, not after you have built them yourself. Your community is small enough that a good tool spreads by word of mouth, and you will tell us when it isn’t good.

Works today

Phone-number sign-in with a code, plus email, magic links, Google, GitHub, Apple, Facebook and anonymous sessions
A Postgres per project with an automatic REST API and row-level security
Uploads that resume after a dropped connection; live updates that catch up
Server code (Workers) and a cron, so a payment callback has somewhere to land

Still to come

Real SMS delivery for sign-in codes (test numbers work today)
M-Pesa, Airtel Money and MTN MoMo as one API (you can call your processor from a Worker now)
A Flutter SDK, which is how most African mobile apps get built

Agencies building for SMEs

One agency is ten projects. You want speed, a cost you can quote a client, and a client who never opens an invoice they didn’t expect. You also want each client’s data kept apart from the others’, in a way you can show them.

Works today

Organisations with owners, admins and members, and invitations
A separate database per project; isolation is attacked by tests that run against production
Per-project usage: every request, every byte, database size
A CLI, migrations and type generation, so a client’s backend lives in their repo
Several apps inside one project, sharing one set of users

Still to come

The prepaid wallet and spend caps that make a client’s cost predictable
Custom domains for a project’s API

Fintechs & regulated teams

You arrive once the foundation is trustworthy: isolation, audit, backups you have seen restored, and paperwork. We would rather tell you now what is not there than let you find out in a compliance review.

Works today

Nightly encrypted backups, and a weekly drill that restores one and reads it back as the project’s own users
Row-level security, sign-in audit logs, and a request log you can filter
Plain Postgres. Payments run on your own processor credentials; we are never a party to the funds

Not yet, and you should know

An African region. Data lives in London today; Johannesburg when a customer needs it
Point-in-time recovery (backups are nightly, so up to about a day of changes is at risk), two-factor sign-in, and an uptime commitment
A dedicated Postgres of your own. That is a conversation, and we would rather have it early

Teams already on Supabase

Your hands already know the query builder, the auth calls and row-level security. Moving is a change of import and key for the code, and a copy for the data. We do the copy with you, run both side by side, and you switch when it is boring.

Works today

An importer that reads a dump of your database and loads an empty project in one transaction, with every row count checked
Your edge functions run on Workers without a rewrite; cron jobs and webhooks come across switched off
A comparison that tells you whether the project and a fresh dump of the original still agree

Still to come

A self-service import button (it is run alongside you today)
Importers for Appwrite and Firebase

By what you’re building

What people build on it.

These are the shapes we have tested against real apps, and the honest edge of each.

Shops & marketplaces

Orders, receipts and a shop screen that updates the moment something is paid. We ship an example app, Duka, that uses every pillar at once and is run by hand against production before we say a pillar works.

Edge: first-class M-Pesa is next; today the payment callback is a Worker on your own credentials.

Learning platforms

Courses, tutor tools and large video files, with uploads that survive a bad connection and access decided by the policies you already write for tables.

Edge: live classes run on your own video provider; we do not host video calls.

Events & ticketing

One identity across a public site and an organiser console, as several apps inside one project, with sign-in links that return to the right one.

Edge: ticket payments are the same M-Pesa caveat as shops.

Field & community apps

Phone sign-in, small payloads, reads that retry on a flaky link, and live updates that reconnect and catch up.

Edge: there is no offline write queue in the SDK yet; reads and live updates are resilient, writes are not replayed for you.

Internal tools

A real Postgres with a SQL editor that explains a statement before it runs, row-level security for who sees what, and Workers on a schedule for the nightly jobs.

Edge: single sign-on for your organisation is not built.

Large enterprise systems

Not yet. We looked hard at an insurance back-office with well over a hundred tables and three backend services, and wrote down why it does not fit: it needs things like allocated compute and an uptime commitment that we have not built.

If that is you, tell us; it shapes the order we build in.

Not sure it fits?

Describe what you’re building. We’ll answer straight.

If it doesn’t fit yet, we’ll say so and tell you what would change that.

Tell us what you’re building How pricing will work