WhatsApp Might Be Africa’s Most Underrated MVP Platform

I have built enough products on WhatsApp to stop thinking of it as just a messaging app.

Fitness Space started there.

Ajo.cash started there.

Famrshare started there.

Three different products solving three very different problems. Health. Savings. Access to food and farm produce.

In each case, we had ambitions to build technology around the problem. But before the websites, apps, and more sophisticated systems, there was WhatsApp.

And something about happened there.

The products worked.

Not in their final form. Not with all the automation, interfaces and infrastructure we would eventually want.

But the important behaviour could happen.

That has changed the way I think about MVPs.

An MVP does not necessarily have to look like a smaller version of the technology you eventually want to build.

Sometimes it only needs to create enough structure for the behaviour at the centre of your idea to happen.

For African founders, I think WhatsApp may be one of the most underrated places to do that.

Fitness Space existed before the app

Fitness Space began with a simple problem.

People wanted to lose weight.

We could have started by designing an app.

Meal logging. Workout tracking. Progress dashboards. User profiles. Notifications. Subscription management.

There were dozens of things we could have built.

Instead, we started on WhatsApp.

We organised people into groups and built a structure around healthier eating, exercise, physical activity, and accountability.

People participated.

They asked questions.

They shared meals.

They struggled.

They disappeared sometimes.

They came back.

We could see what people understood and, perhaps more importantly, what they didn't.

None of this required us to first convince someone to download a new app, understand a new interface, and develop a new digital habit before we could begin helping them.

They already knew how to use WhatsApp.

So we went to them.

That distinction became important.

We weren't testing whether people could use an app.

We were learning whether the system itself could help people.

And every day that the system operated, we learned something.

Then there was Ajo.cash

Ajo.cash gave me an even stronger appreciation for what can happen before dedicated software exists.

Ajo is based on a behaviour that is already familiar to many Nigerians: people putting money aside through a structured contribution system.

Again, we could have started with the website.

We could have spent months thinking about dashboards, interfaces, and all the technology a financial product might eventually require.

Instead, we ran it through WhatsApp.

And in over two years, members saved more than ₦1 billion through the system before we started building the dedicated Ajo.cash website.

That number matters to me for a reason beyond its size.

It changed what the website represented.

We weren't sitting in a room trying to imagine whether people might use what we wanted to build.

People were already doing it.

The behaviour came first.

The technology came later.

By the time you begin building software in that situation, the conversation is different.

You are no longer asking only:

What features should this product have?

You can ask:

What are people already doing?

Where are they struggling?

What are we doing manually that technology could do better?

What becomes difficult as more people participate?

Where does WhatsApp start to break?

Those are much more useful questions.

Famrshare started the same way

Then we did it again with Famrshare.

The problem was different.

People come together, make contributions, and when the pool is complete, the money is used to buy goods, usually farm products, which are then divided among the contributors.

Yam. Beef. Fish. Milk. Palm oil. Vegetable oil. Other food items.

Pooling purchasing power can make it possible to buy closer to the source and reduce some of the layers between the people buying food and where that food comes from.

Once again, the idea did not need to begin with sophisticated technology.

People needed somewhere to organise.

Somewhere to communicate.

Somewhere to coordinate contributions.

Somewhere to see what was happening.

WhatsApp provided enough infrastructure for us to begin.

And this is where I think founders sometimes misunderstand the idea of an MVP.

Your MVP does not have to look like your final product

When people hear "MVP", they often still imagine software.

A rough app.

A simple website.

A product with three features instead of ten.

Essentially, a smaller version of the thing they eventually hope to build.

But I have come to think about MVPs differently.

Your MVP needs to test the behaviour at the centre of the product, not imitate the appearance of the final product.

If you want to know whether people will pay for something, you need a way for them to pay.

If you want to know whether people will contribute regularly, you need a way for them to contribute.

If you want to know whether people will follow a structured health programme, you need a way for them to participate in one.

You don't necessarily need the final software.

WhatsApp gives you a surprising amount of infrastructure before you write a line of code.

You have conversations.

Groups.

Images.

Voice notes.

Documents.

Notifications.

Direct access to users.

And, perhaps most importantly, many of the people you're trying to reach already understand the interface.

There is very little to teach them about how to send a message, post a picture, respond to a group notification, or listen to a voice note.

That lets the founder spend more time learning about the problem instead of teaching people how to use the product.

Manual isn't always bad

There is an obsession in technology with automation.

Eventually, that makes sense.

If something requires a person to manually perform the same action for thousands of users, you probably have a scaling problem.

But at the beginning, manual work can be incredibly valuable.

Manual work forces you close to the problem.

You see the strange requests.

You notice the questions people keep asking.

You discover the steps that look obvious to you but confuse everyone else.

You learn which parts require explanation.

You notice where trust matters.

You discover which activities consume too much time.

You begin to see what should eventually become software.

The inefficiency is giving you information.

At Fitness Space, the things we learned while operating around people eventually influenced what we built.

The product became more structured.

We built dedicated technology.

Bibi became an intelligent layer for guidance and personalisation.

Health Score gave us a way to make daily healthy behaviours more visible.

The app could organise experiences that would become increasingly difficult to manage through conversations alone.

But WhatsApp hadn't failed.

Something else had happened.

We had learned enough to know what needed to exist beyond it.

The breaking point is useful

There is a moment when WhatsApp starts becoming uncomfortable.

I don't think founders should necessarily fear that moment.

I think they should study it.

Maybe you're maintaining too many spreadsheets.

Maybe information is getting lost in conversations.

Maybe users need histories that are difficult to reconstruct manually.

Maybe an activity needs to happen instantly and you're still depending on a person to perform it.

Maybe you need better measurement.

Maybe privacy, security, compliance or the nature of the service requires infrastructure that a messaging group simply cannot provide.

Maybe the number of people using the product has made the existing process impossible to operate properly.

Those problems are frustrating.

But they are also telling you something.

They are showing you why your technology needs to exist.

That is a very different position from building twenty features because you imagine users will eventually need them.

Your operational pain begins writing part of the product specification for you.

Build where people already are

I don't think every startup should begin on WhatsApp.

Some products simply cannot.

And WhatsApp has obvious limitations. It isn't a replacement for dedicated technology when the problem requires dedicated technology.

But I do think African founders should become more comfortable asking a question that comes before:

What should we build?

Ask:

What can we make work with what people already have?

Maybe the answer is WhatsApp.

Maybe it's something else.

But there is enormous value in starting inside existing behaviour rather than immediately asking users to adopt a new one.

Fitness Space taught me that.

Ajo.cash reinforced it.

Famrshare showed me the pattern again.

Three different problems.

Three different products.

The same piece of infrastructure underneath their earliest versions.

WhatsApp.

Eventually, we build.

We build because manual processes become difficult.

We build because users need better experiences.

We build because the product needs to do things WhatsApp was never designed to do.

We build because scale creates new problems.

But by then, ideally, we're not building from imagination alone.

We've watched the product happen.

We've watched people use it.

We've seen where they struggle.

We've seen where our own processes break.

And we've learned what technology actually needs to solve.

That is why I think WhatsApp might be one of Africa's most underrated MVP platforms.

Not because it can replace the product you eventually want to build.

Because it can help you discover what that product actually needs to become.