Building SaaS for Africa: Lessons from UniMarket and Tixa

We don't only build for clients; we run our own products. UniMarket is a marketplace for Maseno University students to buy, sell and find hostels. Tixa sells event tickets over M-Pesa and WhatsApp. Running them taught us things no framework tutorial covers. Here are the lessons we would give anyone building software for the Kenyan market.

1. Don't assume people will install your app

We built a good Flutter app for UniMarket. Most of our users still use the website. When we measured where new listings came from, the majority were posted on the website, not the app. Students are careful with phone storage and data, and a link opened in the browser is always easier than an install.

Lesson: make the website a full product, not a brochure that says "download the app". And anything that must happen for every user — alerts, checks, moderation — should be triggered by the data itself, not by one app's code path, or you will quietly miss most of your users.

2. Push notifications reach fewer people than you think

App notifications only reach people who installed the app and allowed them. For a product where most users are on the web, that is a small group. We learned to treat push as a bonus, and to send anything important — payments, tickets, replies — somewhere people actually look.

3. WhatsApp is the real interface

Kenyans already live in WhatsApp. People will message you there before they fill any form or open any support chat. With Tixa we went further and made WhatsApp itself the checkout: pick an event, choose tickets, get an M-Pesa prompt, receive the ticket in the chat.

Lesson: plan for WhatsApp from day one — as your support channel at minimum, and possibly as the product's main way in.

4. M-Pesa is the checkout, so get it right

Card payments are a minority option for most Kenyan consumers. If you charge money, you need M-Pesa, and you need to handle it carefully:

• Confirm every payment with Safaricom before delivering anything, rather than trusting the callback alone.
• Run a job that settles payments whose callbacks never arrived.
• Tell customers the business name their M-Pesa prompt will show. When the prompt shows a company name they don't recognise, some will cancel, thinking it is a scam. We saw exactly that on Tixa and fixed it by naming it up front.

Our Daraja guide goes into the details.

5. Your data will tell you what your code doesn't

When we rebuilt UniMarket we queried the live database before migrating each feature, and it changed our plans more than once. Items that had been sold were still being treated as expiring, so sellers were being asked to renew things they had already sold. Seller names typed by hand didn't match the accounts behind them. And the question that mattered most for buyers wasn't star ratings but a simpler one: will this seller actually reply?

Lesson: before you build a feature on top of a field, look at what is really stored in it. Measure the thing your users care about (for a marketplace, replies), not the thing that is easy to count. And when you report a "typical" time, use the median; one conversation that waited a week will wreck an average.

6. Trust has to be designed in

In a student marketplace, the fear is being scammed, especially with hostels, where money changes hands before you move in. We are moving hostel listings to verified agents who are checked before they can post, and who students can chat with inside the app. The same goes for any product that handles money or meetings between strangers: verification, visible identity and a record of who said what are features, not extras.

7. Price in shillings, and think in small amounts

Prices in US dollars feel foreign and move with the exchange rate. Price in KES, in amounts that fit how people pay: small, frequent M-Pesa payments are easier to say yes to than one big one. For Tixa we chose a percentage per ticket sold instead of a monthly fee, so organisers pay only when they earn.

8. Keep it light

Every megabyte costs your users money, and many are on budget phones. Small pages, compressed images, and screens that still work on a weak signal aren't polish; they decide whether people come back.