In Nigeria, online generosity has a familiar choreography. A creator announces a giveaway. The replies fill with phone numbers and bank details. Someone opens a spreadsheet. Someone else starts making transfers one by one. What is meant to feel generous can quickly become an administrative job.

Mayowa Sunusi thinks that job should disappear.

He is the technical founder behind Ridim, a Nigerian rewards platform built around a simple idea: distributing value to many people should not require collecting everyone’s details first, reconciling them manually and spending hours sending individual transfers.

That idea did not come from a pitch deck. It came from church.

The small problem that opened a bigger market

Mayowa had been asked to share mobile data with members of his church group. His first instinct was practical: create a Google Form, collect everyone’s information and distribute the data from there. The form exposed the problem almost immediately. People did not reliably submit their details, the process felt unnecessarily cumbersome, and Mayowa found himself asking a more useful question: why should the person giving the reward have to gather all of this information in the first place?

What if the giver could create a pool, share a link or code, and let each recipient claim what was meant for them?

That question became Ridim.

Mayowa’s background made him unusually prepared to turn the irritation into software. Before becoming a founder, he worked as a frontend engineer and creative developer across products for startups and companies in Nigeria and abroad. He says those years taught him how products move from inception to launch, how roadmaps and milestones work, and how technical constraints have to meet the reality of user behaviour.

The first version of Ridim was deliberately small – essentially a one-page product designed for the immediate use case. Even then, users began teaching him what the product needed to become. Early campaigns required creators to allocate reward slots by mobile network. MTN slots disappeared quickly while allocations for less-used networks could remain untouched. A mentor suggested letting recipients choose their own networks instead. Mayowa changed it.

It was a small product decision, but it established the operating philosophy behind Ridim: do not design around how a process looks on paper; design around how people actually behave when the link reaches them.

Rewarding people should not be admin work

Ridim’s homepage currently opens with the line, “End the Awoof Wahala.” In Nigerian slang, awoof is the freebie, bonus or unexpected reward; the wahala is everything that makes getting it more stressful than it should be. The copy is playful, but the problem underneath it is operational.

A community manager may want to send airtime to 500 people. A creator may want to reward ten followers from hundreds of comments. A brand may be running a campaign that requires hundreds of small payouts. In the familiar version of these workflows, somebody has to gather phone numbers or account numbers, choose recipients, make transfers and then answer the inevitable messages from people who say they were skipped.

Ridim changes the sequence. A campaign creator funds a reward, sets the rules and shares a link, code or protected access. Recipients can then claim cash, airtime or data without needing to create an account. Live slot counts show whether rewards are still available, while campaign states tell users when a drop has ended. The platform also gives the creator a record of redemptions instead of leaving the campaign buried across screenshots, forms and transfer receipts.

For Mayowa, that is the real product: not the giveaway itself, but the removal of the messy middle between deciding to reward people and knowing the reward reached them.

He wants the claim experience to be almost forgettably fast. In the interview, he described a target of less than ten seconds for a recipient to open a campaign, provide the information needed for that reward and complete the claim, assuming network conditions cooperate.

Speed matters, but Ridim’s case is broader than speed. Mayowa repeatedly returns to transparency, accountability and reducing opportunities for abuse. If a reward has already been claimed by a recipient, the system should not simply allow the same allocation to be taken again. If someone says a payout never arrived, the campaign owner should have more than memory and screenshots to rely on.

A local product, by design

Ridim is also interesting because it does not try to hide where it comes from.

Its language is deliberately Nigerian. Phrases such as “End the Awoof Wahala” and “See How E Dey Work” sit beside wallet funding, access controls, live campaign status and payment infrastructure. Mayowa says that balance was intentional from the beginning. If the people using a product already have a language for the problem, he sees little value in replacing it with corporate vocabulary simply to sound sophisticated.

That instinct matters beyond branding. Ridim’s early product choices – network selection, campaign codes for people who may not be scanning QR codes, PIN-protected campaigns, live slots and minimal claim requirements – are all responses to specific behaviours around how Nigerians participate in giveaways, communities and digital payments.

The most important of those choices may be what Ridim does not ask for. A recipient claiming airtime does not need to create an account just to receive it. Mayowa’s principle is to request only what is necessary for the transaction: a phone number for airtime or the relevant account detail for cash. In a market where unfamiliar money links can immediately trigger suspicion, reducing the amount of information requested is not only a user-experience decision; it is part of the trust model.

Mayowa is equally clear that trust cannot be solved by interface copy alone. He describes compliance and partnerships as among the hardest parts of building Ridim. Once a product starts moving money, the challenge is no longer simply whether the code works. It is whether the company can satisfy providers, operate within the rules that govern money movement and build relationships with the infrastructure partners it depends on.

One account, three products – but one underlying job

Ridim has expanded considerably from its first airtime-and-data use case. Its current public product is organised around three areas: Ridim for campaigns, games and rewards; Ridim Events for ticketing and event management; and Ridim Business for payroll, vouchers and bulk payouts.

At first glance, rewards, ticketing and payroll can look like three different companies sharing a wallet. Mayowa’s argument is that they are variations of the same underlying job: moving value to a group of people without the manual coordination that usually surrounds it.

The event product emerged from a conversation with someone who wanted Ridim to facilitate ticket sales and then use the reward experience around the event itself. That opened the door to ticketing, audience engagement and features intended to help organisers get useful access to their sales proceeds while the event is still being prepared. Ridim has also built live trivia and game mechanics so engagement and rewarding do not have to happen on separate systems.

The business product followed a similar logic. When the team began speaking with small and medium-sized businesses, Mayowa saw another manual workflow: salaries and contractor payments managed with bank transfers, spreadsheets and fragmented records. Ridim Business is the company’s attempt to make those payouts more structured, while adding payroll histories, payslips, deductions, overtime and vouchers for staff or customers.

The expansion is ambitious, but Mayowa insists the roadmap is not simply a list of interesting things an engineer wants to build. He uses a stricter test: does a feature remove friction in value distribution?

That principle even shaped an experiment around social rewards. Mayowa initially built a Twitter bot that could inspect comments and facilitate rewards. The flaw became obvious: a platform-specific bot solves a platform-specific problem. What happens when the campaign lives on Instagram, Facebook or TikTok? Rather than build a different bot for every network, Ridim moved toward a more unified approach to handling social engagement and rewards.

It is a revealing example of how Mayowa thinks as a technical founder. The first solution does not have to be sacred. If the architecture becomes the constraint, change the architecture.

The founder behind the product

There is a tendency to romanticise the technical founder as the person who can simply build faster than everyone else. Mayowa’s experience with Ridim has made that idea harder to believe.

“Writing code is only half the battle,” he says.

The rest is operations, partnerships, keeping systems online, supporting users, finding distribution and convincing good people to work on something before it has the resources or certainty of a mature company. As Ridim’s solo core developer, Mayowa has also had to confront a basic founder limitation: the same person cannot sustainably be the engineer, designer, marketer, operator and social media team at once.

That realisation is shaping both the company and the founder. His engineering background still gives Ridim its bias toward building and iteration, but his most useful founder lesson may be that product quality alone does not create a business. Infrastructure requires trust. Growth requires distribution. Expansion requires focus. And a founder eventually has to build an organisation, not only software.

The discipline he is trying to impose on Ridim can be summed up in one of his clearest ideas from the conversation: true skill comes from removing friction, not adding features.

That is a useful filter for a product with many possible directions. It also gives Ridim a more coherent story than a list of features might suggest.

The bigger bet

Mayowa’s long-term ambition is for Ridim to become a foundational rewards-payout layer for Africa’s digital economy – the infrastructure people think of when value needs to move from a creator, brand, event organiser or business to many recipients.

That is still an ambition, not a finished outcome. But the direction is visible. The company that began with one church-group problem now spans consumer reward campaigns, audience games, event ticketing and business payouts. What connects those products is Mayowa’s conviction that the manual work surrounding distribution is not inevitable.

If Ridim succeeds, the behaviour it replaces will be instantly recognisable: “drop your account number,” “send your phone number,” “fill this form,” “wait while we confirm the transfer.” Mayowa wants those phrases to sound less like the default workflow and more like the way things used to be done.

There is also a founder story inside that ambition. Mayowa did not begin with the full Ridim roadmap. He began with airtime and data. Cash came later. So did events, vouchers, payroll and new engagement tools. Each addition came after the first product exposed another piece of the problem.

That is why, when asked what he wants other builders to take from his journey, his answer is not about waiting for certainty. It is about starting early enough for the problem to teach you what comes next.

“You won’t even see the full picture until you start,” he says.

Ridim is, in many ways, the product of that belief: start with the friction in front of you, solve it well, and pay close enough attention to notice the larger system hiding behind it.

For Mayowa Sunusi, a request to share data in a church group was never supposed to become a startup thesis. But it revealed one anyway: generosity may be human, but the work of distributing it does not have to be manual.