On June 1, 2026, an African electric mobility company raised $215 million.

Not a fintech. Not an AI startup. Not a SaaS platform.

An electric motorcycle company.

Spiro, founded by Gagan Gupta and headquartered in Dubai, secured the round from Impact Fund Denmark and Equitane, and the raise pushes the company toward $1 billion in valuation, putting it on the edge of becoming Africa’s next unicorn.

The funding will be used to expand battery-swapping and manufacturing infrastructure across its seven existing markets — Nigeria, Benin, Togo, Kenya, Uganda, Rwanda, and Cameroon — and to enter three new ones: Malawi, Mali, and Ethiopia.

This is the largest capital raise in Africa’s electric mobility sector. It is also the third major raise in less than twelve months — Spiro raised $100 million in October 2025, then $50 million in debt from Afreximbank in February 2026, and now $215 million in June.

In a year when African startup funding is tracking ahead of 2025 at $1.3 billion by June 3, Spiro’s raise alone accounts for a significant portion of that momentum.

But I do not want to write another funding announcement. You can read those anywhere.

I want to talk about why a motorcycle company is doing this — and what the model underneath it tells every African SaaS builder something important about how the best businesses actually work.

Spiro is not selling motorcycles

Here is the thing that most coverage of Spiro gets wrong by omission.

Spiro does not primarily make money by selling motorcycles.

It makes money by selling battery swaps.

The model works like this. A rider gets a Spiro electric motorcycle — either purchased or financed through a ride-to-own scheme. The motorcycle uses a removable battery. When the battery runs low, the rider does not wait hours to recharge it. They ride to a Spiro battery-swapping station, hand over the depleted battery, and ride away with a fully charged one in minutes.

The swap is the service. The swap is the recurring revenue. The motorcycle is the hardware that creates the dependency on the service.

Spiro has deployed approximately 100,000 electric motorcycles across its markets. It operates over 2,500 battery-swapping stations. Every single one of those motorcycles is a recurring customer for every single swap it needs — multiple times a day, every day, as long as the rider is working.

If you are a SaaS builder, you have already recognised this model.

It is subscription revenue. It is infrastructure lock-in. It is the same logic that made Flutterwave valuable — not the dashboard, but the pipes underneath that every transaction flows through.

Spiro built the pipes. The pipes happen to be battery-swapping stations instead of payment APIs. But the business logic is identical.

Why motorcycles are infrastructure, not just transport

To understand why this raises $215 million instead of, say, $5 million, you need to understand what motorcycles actually are in Africa.

Across Sub-Saharan Africa, an estimated 80 to 90% of motorcycles are used for commercial purposes, such as motorcycle taxis, last-mile delivery, logistics riders, and intra-city transport services. The electric two-wheeler market across Africa is valued at $4.01 billion in 2025 and is projected to reach $6.76 billion by 2034.

More importantly, motorcycle-based transport is estimated to support over 10 million jobs across Sub-Saharan Africa.

Ten million jobs. Not passengers. Jobs.

These are not people who occasionally use a motorcycle. These are people whose entire livelihood depends on a motorcycle being operational, affordable to run, and available every day. When the motorcycle stops working, income stops. When fuel becomes unaffordable, income stops. The motorcycle is not a convenience; it is the business.

This is why battery swapping is not a nice feature. It is a critical service.

A petrol motorcycle rider in Lagos faces rising fuel costs that erode margins with every price increase. A Spiro electric rider has a predictable swap cost that does not fluctuate with oil prices. That predictability is worth money. Real money, paid every day.

And every swap is a data point. Spiro knows which routes are busiest, which stations are underutilised, which riders have the highest swap frequency, and which markets need more stations. That data makes the infrastructure smarter over time, a compounding advantage that grows with every motorcycle added to the network.

This is what infrastructure-level thinking produces. Not a product. A platform that gets more valuable the more people use it.

The Nigeria connection

Spiro operates in Nigeria. That is not a minor detail.

Nigeria is Africa’s most populous country, its largest economy, and one of the most complex logistics environments on the continent. Running a battery-swapping infrastructure across Nigerian cities — dealing with traffic patterns, power availability for charging stations, rider behaviour, and regulatory complexity is not an easy problem.

The fact that Spiro has made it work in Nigeria, alongside six other African markets simultaneously, is part of what gives investors confidence in the $215 million raise. It is proof that the model survives contact with Africa’s hardest conditions.

For Nigerian builders reading this, there is a specific lesson here.

Spiro did not start in Nigeria and then figure out how to work elsewhere. It built the model in multiple markets simultaneously, refined it in each context, and used that multi-market experience to build an infrastructure that is genuinely Africa-shaped, not a Western model localised for Africa, but a model that could only have been built by someone who understood African mobility from the ground up.

That contextual knowledge is a moat. It is the same moat I have written about in the context of the Google Accelerator cohort, the London Stock Exchange eight, and every other company that has broken through this year. The companies that win in Africa are the ones whose products could only have been built by people who understood African problems from the inside.

What the battery-swap model teaches SaaS builders

Let me make this explicit, because I think the connection is worth naming directly.

Spiro’s business model has three components that every SaaS builder should recognise.

First: the hardware is the distribution strategy.

Spiro does not acquire customers by running ads or building virality. It acquires customers by placing motorcycles in the hands of riders who need them. The motorcycle is not the product; it is the mechanism by which the customer enters a relationship with Spiro’s service infrastructure.

For a SaaS builder, the equivalent question is: What is your mechanism for getting a customer into your service relationship? Not your marketing strategy. Your distribution mechanism. The thing that, once a customer has it, creates the conditions for a recurring service relationship.

Swoop’s food delivery app is a distribution mechanism for payments. Flutterwave’s payments API is a distribution mechanism for the banking stack. Every great African tech company I have written about this year has a clear answer to this question. Most early-stage builders do not.

Second: the recurring revenue is in the consumable, not the asset.

Spiro does not primarily make money when someone buys or finances a motorcycle. It makes money every time that motorcycle needs a battery swap. The asset, the motorcycle, is almost incidental to the business model. The consumable battery charge is where the revenue lives.

For SaaS builders, this maps directly to the difference between a one-time sale and a subscription. The product is the mechanism. The value delivered continuously — the thing the customer comes back for again and again — is the business.

If your SaaS product only charges users once or relies on infrequent upgrades for revenue, ask yourself what the equivalent of the battery swap is. What is the thing your customer needs repeatedly, on a short cycle, that you could be capturing as recurring revenue?

Third: density makes the model defensible.

One battery-swapping station in a city is not very useful. A hundred battery-swapping stations, placed at the right intervals across the city’s busiest routes, create a network that is genuinely difficult to replace. The value of the network increases non-linearly as the coverage increases.

This is the same dynamic that makes payment networks, telecom infrastructure, and logistics platforms so valuable over time. The first unit of capacity is almost worthless. The ten-thousandth unit of capacity is extraordinarily valuable.

For SaaS builders, density maps data. The first hundred users of your product give you some signal. The hundred-thousandth user gives you compounding intelligence about patterns, behaviours, and needs that no competitor starting from scratch can replicate. The moat builds with scale — but only if you design the product to capture and use that intelligence.

What $215 million in one raise actually means for the ecosystem

Let me zoom out for a moment.

African startups had raised $1.3 billion in total by June 3, 2026, a pace tracking slightly ahead of 2025. Spiro’s $215 million raise, announced June 1, represents a significant portion of that total.

In a year when AI-driven layoffs are accelerating across the continent, Jumia cut 200 jobs, Zap Africa reduced its workforce by 44%, Spiro is expanding. It is adding markets, building manufacturing capacity, and developing energy infrastructure.

The contrast is instructive.

The companies cutting jobs are cutting because AI has made certain roles redundant, and the underlying business model was dependent on human labour at scale. The companies attracting $215 million raises are attracting it because they have built infrastructure that becomes more valuable as it scales — regardless of what happens to the cost of individual labour.

This is the infrastructure-versus-features distinction that I keep returning to across my writing.

Features can be copied. Features can be automated. Features can be made redundant by a better product or a smarter AI.

Infrastructure cannot be easily copied. Infrastructure compounds over time. Infrastructure creates dependencies that make switching costly even when alternatives exist.

Spiro built infrastructure. Not the most glamorous infrastructure, electric motorcycle battery-swapping stations are a long way from the sleek SaaS dashboards that dominate developer Twitter. But real infrastructure, serving real people, solving a real and expensive problem that the market will pay to have solved indefinitely.

One more thing worth noting

Spiro’s raise is being described as positioning the company near unicorn status — a $1 billion valuation.

Africa’s current unicorns are almost entirely fintech companies. Flutterwave. Interswitch. OPay. Wave. The list is dominated by payments, lending, and banking.

A $1 billion electric motorcycle company would be something different. It would be proof that the infrastructure investment thesis works outside of financial services — that there are African infrastructure problems large enough and valuable enough to sustain billion-dollar companies in sectors nobody was watching closely five years ago.

If Spiro crosses that threshold, it changes how investors think about what is possible to build in Africa.

And that changes what gets built.

I write about building products in Africa — what the best companies are doing that most builders miss, and what I am learning as a founder building in this market. Subscribe to this Substack and every new piece comes directly to your inbox.

Ibrahim Kolade is 16 years old.

He has not entered the university system yet. He learned his first technical skill , desktop publishing , at a private training centre in Lagos after his secondary school teacher noticed how much time he spent in the computer lab. He taught himself coding on freeCodeCamp before enrolling at ProCode Coding School in Abeokuta. He built the first version of his product before he had finished his backend development training.

He has an old laptop with a battery so bad that it constantly shuts down mid-project. He has inconsistent electricity in Abeokuta. He has no investors, no accelerator backing, no co-founder with a Stanford MBA.

And he has a live product called Tasknory , an Africa-focused work platform for AI specialists, designed to fix the visibility bias that got him banned from Fiverr while he was talking to a potential client, despite breaking no rules.

He is 16 years old. He is already building.

I want to sit with that for a moment before I extract the lesson. Because I think most people will read this story and feel inspired for approximately four minutes before returning to whatever they were doing before. And I want to be honest about why that happens and what it would actually take to respond differently.

The problem Ibrahim was solving

Let me tell you the specific thing that triggered Tasknory, because the specificity matters.

Ibrahim registered on Fiverr, Upwork, and Freelancer.com as a graphic designer. His parents supported the decision. He had a real skill and a legitimate reason to be on those platforms.

He got no jobs.

The more he used those platforms, the more he understood why. The systems rewarded people who already had ratings and completed projects. But without existing projects, you could not get ratings. Without ratings, you were invisible. It was a closed loop that made entry almost impossible for new freelancers , and disproportionately affected African freelancers who were starting from zero with no existing reputation on global platforms.

Then he was banned from one of the platforms while speaking with a potential client. He had broken no rules. The system flagged him anyway.

That experience did something important. It moved him from frustration to clarity. He stopped asking “how do I succeed on this platform?” and started asking “is there a better way to build a platform altogether?”

That shift , from user to architect, from complaining about the system to building a different one , is the exact identity shift I wrote about in my service-before-SaaS article. And Ibrahim made it at 16.

What he built and how he built it

Tasknory launched its MVP in 2025 as a general-purpose freelance platform. After gathering feedback, Ibrahim made a critical decision: stop trying to compete with Fiverr and Upwork directly. Instead, pivot to a specific, defensible niche , AI specialists across Africa.

This is the same decision I have seen in every company that has broken through this year. The Google Accelerator cohort, the London Stock Exchange eight, Swoop pivoting from Eswatini to Lagos and from general delivery to a payments super app play. The builders who get traction are the ones who resist the temptation to build everything and instead go deep on one specific problem in one specific market.

Ibrahim’s specific insight about the platform was architectural: the bias problem in existing freelance platforms is structural, not cosmetic. Adding more African freelancers to Fiverr does not solve it. The rating system itself is the problem , it creates a permanent advantage for early adopters and makes discovery nearly impossible for newcomers regardless of their actual skill.

So on Tasknory, matching is not supposed to depend on ratings. It depends on verified skill. Clients cannot freely message freelancers until they have funded the project. This design decision addresses two problems simultaneously: the discovery bias for new freelancers, and the scam problem that makes existing platforms noisy and unsafe.

He built the backend initially using Supabase and AI-assisted tools to get the MVP out before he had completed his backend training. Then, after improving his Django skills, he rebuilt parts of the platform properly. He did not wait until he knew everything before he started. He built with what he knew, learned what he needed, and rebuilt what needed improving.

The platform currently has a small number of users. Ibrahim personally sourced the first few projects from schools he attended to build initial case studies. He is honest about where the product is: still early, still limited traction, still building the foundation.

That honesty is itself a signal of someone thinking like a founder rather than a promoter.

The infrastructure reality nobody romanticises

Here is the part of Ibrahim’s story that I think deserves more attention than it usually gets in these profiles.

He built Tasknory while dealing with an old laptop that constantly hung and shut down mid-project. He built it in Abeokuta where power supply was inconsistent enough that work scheduled for one week regularly stretched into months.

He said it plainly: “A lot of learning technology in Nigeria means learning how to continue despite unstable electricity, weak devices, or difficult conditions.”

This is not a side detail. It is the context in which every Nigerian developer who builds something from scratch is working. The infrastructure constraints are not a footnote to the story of Nigerian tech , they are the environment inside which every act of building happens.

And when I think about the developers I know who have been waiting for the right moment , better equipment, more stable electricity, faster internet, enough savings to feel comfortable taking the risk , I think about Ibrahim at 16 with a laptop that keeps shutting down, finishing a product anyway.

The constraints did not stop him from building. The constraints became the conditions inside which he built.

Three things Ibrahim did that most experienced developers do not

I want to be specific here because the lesson is only useful if it is actionable.

One: He built before he was ready.

He started the Tasknory MVP before finishing his backend development training. He used Supabase and AI tools to handle what he could not yet build himself, and then went back and rebuilt those parts properly once he had the skills. Most developers I know would have waited until they had mastered everything before starting. Ibrahim started and filled the gaps while moving.

Two: He pivoted based on real feedback, not assumptions.

The general-purpose version of Tasknory was his first instinct. The AI specialists focus came from listening to what people told him about why competing with Fiverr directly would be difficult. He changed direction because of real information from real conversations, not because a pivot sounded more interesting or looked better on a pitch deck.

Three: He stayed close to the real problem.

Tasknory exists because Ibrahim experienced the problem personally. He was not solving a problem he read about in a report or heard about at a conference. He was on those platforms. He was banned. He watched how the system worked from the inside. That proximity to the problem is what made the architectural insight possible , he could see what was wrong with the system because he had been trying to use the system and failing.

This is the advantage that every Nigerian developer has and most underutilise. You live in the market you are building for. You experience the problems your users experience. You understand the context your product will operate in. That is not a small advantage. It is the most important advantage there is in early stage building.

What this story means if you are reading this as an experienced developer

I am not going to do the obvious thing and say “if a 16-year-old can do it, what is your excuse?” That framing is cheap and I think it misses the real point.

The real point is about the relationship between learning and building.

Ibrahim’s approach to building Tasknory is described in one sentence from the Techpoint Africa interview: “Most of my learning has happened while building.”

That sentence contains an entire philosophy.

Most developers think of learning and building as sequential. First you learn the skill. Then you apply it. First you understand the market. Then you enter it. First you validate the idea. Then you build the product.

Ibrahim does not do it that way. He builds, and the building is how he learns. The MVP taught him what the general platform could not be. The pivot taught him what niche focus actually looks like. The scam problem in the early version of the messaging system taught him why funding before communication was the right architectural decision. Every build taught him what the next build needed to be.

This is not carelessness. It is a different theory of how learning works , one that treats experience as the primary teacher and preparation as something you do continuously rather than as a prerequisite for action.

If you are an experienced developer with skills, with a laptop that works, with electricity that is mostly reliable, with a market around you full of problems you understand , the thing separating you from Ibrahim Kolade is not ability or resources or access.

It is the willingness to start before everything is ready.

Ibrahim started. At 16. With a dying laptop. In Abeokuta. Without a degree.

Tasknory is live at tasknory.com.

What are you waiting for?

I write about building products in Africa , what the best builders on this continent are doing differently, and what I am learning as a founder building in this market. Subscribe to this Substack and every new piece comes directly to your inbox.

Let me tell you something I have not said directly on this Substack yet.

Before GinuxAI. Before BuySmart. Before any of the products I write about here, I spent months building things nobody asked for.

Not because I was not skilled enough to build them. I was.

Not because the ideas were bad. Some of them were genuinely good.

I built them before I had a single user. Before I had validated that anyone would pay. Before I had talked to enough people to understand whether the problem I was solving was painful enough to make someone open their wallet.

I was doing what almost every Nigerian developer does when they decide they want to build something of their own.

I went straight to the product.

And I paid for it in months, in opportunity cost, in the quiet frustration of finishing something and realising you now have to start from zero on the harder problem: getting anyone to care.

This article is about what I learned. And what I wish someone had told me before I learned it the expensive way.

The SaaS dream and why it is a trap for most developers

There is a version of the SaaS story that gets told constantly in developer communities.

Build a product. Launch it. Get users. Generate monthly recurring revenue. Scale.

It sounds clean. It sounds like a system. It sounds like the logical extension of the engineering mindset we already have: define the problem, build the solution, deploy it.

But there is a step that version of the story leaves out entirely.

Distribution.

The developers you see online who have built successful SaaS products the ones doing a million naira a month, the ones with the Twitter threads about their MRR growth, almost all of them had something before the product.

An audience. A following. A network of people who already trusted them. A distribution channel they had been compounding for years before they had anything to sell.

When they launched, they were not launching into silence. They were pulling a lever that was already built.

Most Nigerian developers do not have that lever. I did not have it.

And without distribution, even the best product shouts into a void.

Your product can be objectively better than the alternative. It can solve the problem more elegantly. It can be faster, cheaper, and more thoughtfully designed. And it will still sit undiscovered because nobody knows you exist and you have no mechanism to change that.

The product was never the bottleneck.

Distribution was.

I understood this intellectually before I fully understood it in practice. And there is a significant gap between those two kinds of understanding.

What I should have done first

Here is what I have come to believe, not from a transcript someone filmed on a boat in Lake Como, but from building things in Lagos with real constraints.

The fastest path to a product that people actually want is through service.

Not consulting forever. Not replacing one job with another. But starting with service deliberately, as a strategy, before you write the first line of your product’s code.

Here is why.

Every conversation you have with a paying service client is market research that no survey, no Reddit thread, and no validation framework can replicate.

You are inside their workflow. You are watching them use the broken tools they currently tolerate. You are hearing the exact words they use to describe their problem, which are almost never the words a developer would use to describe the same problem. You are seeing which part of the process makes them frustrated enough to pay someone to fix it.

That intelligence is worth more than months of building in isolation.

And here is the part that changes everything: they are paying you to gather it.

The client who is paying you for a service is, without knowing it, funding your research into the product you will eventually build. They are telling you the price point before you have to guess it. They are telling you the features that matter and the ones that do not. They are pre-validating your roadmap with every conversation.

When you eventually build the product, you are not guessing. You are building what you already know people will pay for because they have been paying for the manual version of it.

The Nigerian context that makes this even more true

I want to add something that the Western developer playbook rarely accounts for.

In Nigeria, the gap between a business owner’s problem and a software solution for that problem is enormous, and it is a gap that very few people are bridging.

Most Nigerian businesses are still running on WhatsApp messages, Excel sheets, and manual processes that a relatively simple tool could automate in days. The logistics company is two streets away. The school your sister attends. The clinic your parents use. The market trader loses sales because payment collection is slow.

These are not problems that require a sophisticated SaaS platform to solve. They often require someone who understands technology to sit with the business owner, understand the workflow, and build the simplest possible solution that removes the friction.

That is a service. And if you do it well, and you document what you learned, and you notice when the same problem appears across multiple clients, that is your product roadmap.

This is how the most successful Nigerian tech companies actually started. Not with a product they built in isolation and then tried to sell. With a deep understanding of a specific problem in a specific market, earned by being close to real businesses.

You have access to those businesses. You live near them. You know people who run them. You can walk into their offices. That in-person access is something no remote agency and no Silicon Valley founder can replicate.

Use it.

The identity shift nobody talks about

There is a deeper reason most developers never make the transition from employee to founder. And it is not the one they think it is.

It is not a lack of skill. Nigerian developers are technically exceptional. That is not the gap.

It is not a lack of ideas. If anything, most developers have more ideas than they know what to do with.

The gap is identity.

For most of us, the mental model of what we are goes like this: I am a developer. I build things. I ship features. I solve technical problems. Someone else sells them.

That mental model is completely fine inside a job. It is lethal when you are trying to build something for yourself.

Because when you are building for yourself, you are not just the person who builds the thing. You are the person who identifies which thing to build, who decides what it costs, who explains why it is worth it, and who takes responsibility for whether it works.

That is a completely different identity. And most developers never make the shift because they never get into the position where they have to.

Services force that shift.

The moment you sit across from a business owner, tell them their current process is costing them money, and propose a specific solution at a specific price, you are no longer an employee. You cannot be. Employees do not negotiate outcomes. Employees do not own the result.

That conversation changes you in a way that shipping another feature inside a product nobody uses never will.

I have had versions of that conversation. Building GinuxAI and BuySmart publicly, writing about it, launching on Product Hunt, all of it has pushed me toward that identity shift faster than anything I could have done by continuing to build quietly.

But if I am honest, I should have had those conversations with real business owners much earlier. Before I was building products. I should have been building an understanding of the market that would have made the products I eventually built much sharper from day one.

The sequencing that actually works

Let me be specific about what this looks like in practice, because the abstract argument is only useful if you know what to do with it.

Start with people you already know. Not strangers. Not cold emails. The people in your phone, your family, your former colleagues, your church or mosque, your university classmates. Think about which of them runs a business or works inside one.

Call them. Not to pitch. To ask one question: what is the most frustrating, time-consuming thing in your work right now?

Listen properly. Not to identify a technical solution immediately. To understand the shape of the pain.

When you hear something you know you can fix, offer to fix it. Charge for the outcome, not the hours. Deliver something that works. Document everything you learned.

Then find another client with a similar problem.

And then another.

After three to five clients in the same space, you will start to see the pattern. The same friction. The same workflow. The same words to describe the same frustration. That pattern is your product.

Build for that pattern, and you will know before you write the first line of code that someone will pay for what you are building. Because they already have.

Where I am now

GinuxAI is live. BuySmart is open source and growing.

Both of them are better products than they would have been if I had built them in isolation from the beginning. Because in the process of building publicly, writing about the market, speaking to beginners at SoftLearn, and having conversations with users since the Product Hunt launch, I have been doing exactly what services do, getting close to real people with real problems and letting that shape what I build.

But I would be lying if I said I got the sequencing perfectly right from the start.

The honest version is: I learned the sequencing by getting parts of it wrong. By building before validating. By moving fast before I was sure of the direction. By discovering, after the fact, that some of the assumptions I built into early versions of the product were assumptions nobody had actually confirmed.

That is not a disaster. It is how almost everyone learns.

But you do not have to learn it the same way I did.

The sequencing is not complicated.

Solve a real problem for a real person. Get paid for it. Learn everything you can from that client. Repeat until you see the pattern. Then build the product that solves the pattern.

Services first. Distribution second. Product third.

In that order. Not because it is the comfortable path. Because it is the one that actually works.

I write about building products in Africa, what I am learning as a founder, what the best builders on this continent are doing differently, and what I wish I had known earlier. Subscribe to this Substack and every new piece comes directly to your inbox.

Six weeks ago, I published my first article on this Substack.

It was about Flutterwave becoming a bank.

Since then, I have published 17 articles. About Nigerian AI regulation. About the CAC cyberattack. About Paul Onwuanibe losing $80 million in seven days. About the 0.04% of the world is being built with AI. About tech layoffs and narrative control and Google Accelerators and London Stock Exchange pitches and broadband penetration and Berkeley dropouts moving to Lagos.

Seventeen different stories. Seventeen different angles. Seventeen different news hooks.

But if I am honest with myself, and I think the best thing I can do for you as a reader is be honest, every single one of those articles was about the same thing.

It took me until today to say it plainly.

The thesis

Here it is, as simply as I can put it:

The builders who win in Africa are the ones who own their foundation.

That is it. That is the thread running through every article I have written since April.

Let me show you what I mean.

The Flutterwave articles

I wrote about Flutterwave twice.

The first time, I wrote about how a payments API became a bank. The lesson was not really about banking it was about what happens when a company methodically acquires the infrastructure underneath its own product. Flutterwave started as a pipe. Then they bought Mono to own the data layer. Then they got a banking licence to own the deposit layer. Every move was a move toward owning more of their own foundation.

The second time, I wrote about the $75 million government drama when a presidential aide announced an investment Flutterwave immediately denied. The lesson there was about narrative. Your story is part of your foundation. When someone else tells it prematurely, inaccurately, without your consent you have to spend credibility you built over years to correct it. Owning your narrative is part of owning your foundation.

Paul Onwuanibe

This is the starkest version of the thesis.

A man spent 15 years and $150 million building the most visited destination in West Africa. Then the Lagos State Government issued a seven-day demolition notice. The property fell within the right-of-way of a planned road whose plans were drawn up after he had already built everything.

$80 million. Gone.

The lesson I drew for SaaS builders was direct: he did not lose Landmark Beach Resort because he built it poorly. He lost it because he built it on land he did not ultimately control.

And I asked every builder reading that article to look at their own product and answer honestly: what land is your business sitting on?

Your Instagram following is rented land. Your WhatsApp Business API integration is rented land. Your users inside someone else’s platform are rented land. The moment that platform changes its rules, your business changes with it.

The builders who survive are the ones who own their email list, their customer relationships, their data, their distribution channel. Everything else is infrastructure someone else can demolish.

The CAC cyberattack

Nigeria’s Corporate Affairs Commission was hacked. The portal went down for three days. 10,000 registration requests per day were suspended.

The lesson was the same lesson, from a different angle.

Most Nigerian SaaS products are sitting on security infrastructure that has not kept pace with the scale of data they are holding. They are building impressive things on foundations they have never audited. When the breach comes and NITDA’s Director General said plainly that 95% of breaches are caused by human error, not sophisticated attacks the product that did not own its security infrastructure will collapse faster than the product that did.

Own your security foundation. Audit it before someone else reveals it to you.

The Nigerian AI regulation article

Nigeria is about to give NITDA the power to regulate all AI systems deployed in the country classifying them by risk, requiring licences, imposing fines of up to ₦10 million or 2% of annual revenue.

The lesson: the regulatory environment is part of your foundation. Builders who understand the regulation before it lands will be embedded, trusted, and compliant when enforcement begins. Builders who ignore it will scramble.

Owning your foundation means knowing what rules govern the ground you are building on before those rules are enforced against you.

The Google Accelerator and London Stock Exchange articles

I wrote about four Nigerian startups getting into Google’s Accelerator from 2,600 applications. Then I wrote about eight Nigerian startups being selected for the London Stock Exchange investment showcase eight out of thirteen African companies chosen.

In both cases I asked the same question: what do these companies have in common?

The answer, every time, was the same.

They are building infrastructure, not interfaces. They are solving problems that cost businesses real money. They are deeply embedded in the specific context of their market not products that were built elsewhere and localised for Africa, but products that could only have been built by someone who understood the problem from the inside.

The infrastructure lesson is the ownership lesson. Companies that build the pipes that other companies depend on own something much harder to replace than companies that build the dashboard those companies log into.

The Swoop article

A 19-year-old from New York dropped out of Berkeley, moved to Lagos, and rebuilt his entire startup codebase from scratch using AI tools. He raised $7.3 million.

The lesson I drew was about movement about building before everything is perfect, about using the tools available to compress the timeline between idea and shipped product.

But underneath that lesson was the ownership lesson again.

Swoop is not building a food delivery app. Food delivery is the wedge. The real play is that payments are becoming the daily interface through which Nigerian users access financial services. The food delivery app is the distribution strategy for owning a deeper relationship with the user.

The founders who win are not the ones who build the most features. They are the ones who figure out which relationship with the user, with the business, with the data is worth owning long term, and then build the wedge that earns that relationship.

The 0.04% article

Only 0.04% of the world’s population is building with AI right now.

Nigerian developers are in that 0.04%.

The lesson was about recognising what you already own and using it before someone else does. African developers have market knowledge that no Silicon Valley company can buy. They have in-person access to businesses that no remote agency can replicate. They have contextual understanding of problems that the world’s AI tools were not built to solve.

That knowledge is a foundation. The question is whether you will build on it or let someone who flew across the world to access your market build on it first.

The broadband penetration article

Nigeria crossed 50% broadband penetration. 16 million new subscribers in a single year.

The lesson was about building for the infrastructure that actually exists, not the infrastructure that was supposed to exist by now. Data prices are rising. Speeds are inconsistent. Rural areas remain underserved. The headline number is real and the constraints underneath it are equally real.

Builders who own their understanding of the market, who design for the actual median connection speed, the actual income levels, and the actual device capabilities of their users will outlast the builders who designed for the best-case scenario.

Owning your understanding of the market is part of owning your foundation.

The HBR layoff article

Only 2% of current layoffs are because AI has actually replaced someone. The other 39% are because companies believe AI will replace people within the next six to twelve months.

The lesson was about the gap between technical skill and business communication and about the danger of building your career on a foundation that someone else controls.

The only engineers who are completely immune to a company’s headcount decisions are the ones generating their own revenue. The only way to generate your own revenue is to connect your technical skill to a business outcome that a non-technical person can see, feel, and pay for.

Own your revenue. Own your value creation. Don’t build your career on ground someone else can demolish.

The SoftLearn talk

I spoke to 30 beginners about AI in Apapa on May 1st.

The lesson I drew from that experience was that teaching reveals that explaining something clearly to someone who knows nothing about it is the fastest way to discover what you actually understand.

The builders I respect most are the ones who can explain their product in one sentence to someone who has never thought about the problem before. That clarity is not just a communication skill. It is evidence that they own their understanding of what they are building and why.

The one thing

Seventeen articles. One thesis.

Own your foundation.

Own your distribution, not just the platforms, the direct relationships. Own your infrastructure, not just the features, the stack underneath them. Own your security, not just the product, the data it holds. Own your narrative, not just the product, the story about the product. Own your market knowledge, the contextual understanding that nobody else has. Own your revenue, not just the skills, the business outcomes those skills produce. Own your understanding not just the information, the clarity to explain it simply.

Every company that has broken through in the stories I have covered this year, Flutterwave, the Google Accelerator cohort, the London Stock Exchange eight, Swoop, has been building toward owning something. Not just building features. Building ownership.

And every cautionary tale, Paul Onwuanibe’s demolition, the CAC breach, the layoffs, the narrative failures, has been a story about what happens when something important was built on a foundation that belonged to someone else.

Why am I saying this now

I did not set out to write 17 articles about the same thing.

I was following the news. Responding to what was happening. Trying to extract the builder lesson from each story as I found it.

But looking back at everything I have written since April, the pattern is unmistakable.

And I think it is the most important thing I can tell you, not as a news commentator, but as a builder who is learning this lesson alongside you.

The opportunity in Africa is real. The market is growing. The infrastructure is improving. The talent is here. The companies are being built.

But the builders who will still be here in ten years, the ones who will have built something that compounds, that scales, that survives regulatory changes and platform shifts and government notices and market downturns, are the ones who spent less time on features and more time on foundations.

Own what you build.

That is the lesson. From every story. In every article. Over six weeks.

Thank you for reading. If you have been following this Substack since the beginning or even just for a few articles, I genuinely appreciate it. The best thing you can do if this resonated is share it with one builder you know who needs to hear it.

On 29 May 2026, eight Nigerian startups will walk into the London Stock Exchange.

Not as tourists. Not as observers. As the most represented national contingent at one of the most prestigious investment showcases on the African tech calendar.

The Africa Tech Summit London Investment Showcase, now in its 10th edition, brings together over 350 African and international ventures, investors, corporates, and regulators. This year, 13 companies were selected from across the African continent to pitch. Eight of them are Nigerian.

The announcement was made on 12 May 2026.

Nigeria holds more than 60% of the selected cohort in a continent-wide competition.

I want to talk about what that actually means. Not just for Nigerian tech’s reputation but for every builder reading this who wants to understand what it takes to get to rooms like that one.

First, who are the eight companies?

Let me be specific, because the details matter.

Aktivate is building a creator operating system, a single platform where African creators can collaborate with brands, manage campaigns, sell digital products, and receive cross-border payments.

Bunce helps businesses turn customer data into personalised engagement that drives retention and revenue growth.

Orbit Electric assembles IoT-enabled electric motorcycles in Lagos and provides pay-as-you-go financing for last-mile delivery riders.

ProDevs helps companies find, assess, and hire top engineers more efficiently without the delays and friction of traditional recruitment.

Reisty is a guest management software platform designed specifically to help African restaurants improve customer experience and boost profitability.

Redbiller Technologies is building a complete financial suite that neobanks, fintechs, and crypto exchanges can use to scale globally.

Scandium Systems offers AI-powered test automation tools that remove quality assurance bottlenecks, enabling engineering teams to test as fast as they build.

UltraPay provides a multi-currency payment solution targeting cross-border commerce.

Eight companies. Eight sectors. Eight different problems are being solved.

But when I look at them together, a very clear pattern emerges.

The pattern that explains why Nigeria dominated this cohort

Look at that list again.

Every single company is solving a business problem, not a consumer lifestyle problem.

Aktivate is not building a social media app. It is building the operating infrastructure that creators need to run a professional business. Bunce is not building a content platform. It is building retention infrastructure for other businesses. Reisty is not a restaurant discovery app. It is the software that helps restaurant operators run better businesses.

Every one of these eight companies is selling to businesses, making those businesses more efficient, more profitable, and more capable of doing what they already do.

This is the B2B infrastructure pattern I have been writing about on this Substack all year.

The companies that get selected for rooms like the London Stock Exchange are not the ones with the most clever consumer features. They are the ones solving problems that businesses pay for because the problems are real, measurable, and expensive.

The Google Accelerator cohort I wrote about earlier, Bani, MasteryHive AI, Regxta, and Termii had the same pattern. B2B. Infrastructure. Real business problems with real costs.

This is not a coincidence. It is a selection principle that the best programmes and investors apply consistently.

What this showcase actually is and what it is not

I want to be honest about what the Africa Tech Summit London Investment Showcase represents, because the framing matters.

This is not a pitch competition with a cash prize. It is a curated investment event designed to connect high-potential African ventures with institutional capital, strategic partners, and regulatory stakeholders operating at the global level.

The difference is significant.

At a pitch competition, you win a cheque and go home. At an investment showcase at the London Stock Exchange, you spend time in a room with people who can write cheques that change the trajectory of your company and more importantly, with people who can connect you to other people who can do the same.

The value is not the stage. The value is the room.

For Nigerian founders whose primary challenge is not building the product but accessing the capital and networks that allow it to scale, getting into a room like that at this moment in time is significant.

Here is why the timing matters particularly.

In 2025, Nigerian startups raised $343 million in venture capital, a 17% decline from the previous year. Meanwhile, the broader African tech ecosystem rebounded to $3.1 billion. Nigeria’s share of African tech funding is shrinking at exactly the moment when its share of African tech talent is growing.

Events like Africa Tech Summit London help maintain Nigeria’s visibility with international investors at precisely the moment when that visibility most needs reinforcing. Eight out of thirteen selected companies being Nigerian is not just a statistic it is a counter-narrative to the funding decline story.

The talent is here. The companies are being built. The question is whether global capital will find its way to them.

The lessons for builders who are not yet in those rooms

Let me be honest about something.

Most Nigerian builders will not pitch at the London Stock Exchange next month. Most will not be selected for the Google Accelerator this year. Most will not raise a seed round from a Tier 1 VC in the next twelve months.

That is not discouragement. That is arithmetic.

The question worth asking is not “how do I get into one of these events?” The question is “what do the companies that get into these events have in common and am I building in that direction?”

Here is what I can observe from looking at this cohort alongside the Google Accelerator cohort, alongside everything else I have been tracking this year.

One: They solve problems that have a measurable cost.

Every company on that list is attacking a problem that costs businesses money, time, or operational friction that can be quantified. Scandium Systems removes QA bottlenecks, so teams can measure how much testing delays their releases. Orbit Electric’s pay-as-you-go financing solves a capital access problem for delivery riders. You can measure exactly how many riders they can now serve who previously could not access a motorcycle. ProDevs reduces the time-to-hire for engineers a cost that any engineering manager can tell you in naira and weeks.

When you can put a number on the problem you solve, investors can model your value. When the problem is vague or primarily emotional, they cannot.

Two: They are solving African problems with African-market knowledge.

Reisty is not a generic restaurant management software that was built in San Francisco and localised for Lagos. It is guest management software designed specifically for how African restaurants actually operate. Orbit Electric is assembling motorcycles in Lagos, not importing finished units. UltraPay is built for the cross-border commerce friction that specifically characterises intra-African and Africa-global trade.

The advantage these companies have is contextual. They understand the problem not because they read a report about it, but because they live in the market. That contextual knowledge is a moat that a company headquartered in London or New York cannot easily replicate.

Three: They are ready for the room, not just the product.

Being selected for an investment showcase at the London Stock Exchange requires more than a working product. It requires a company that can communicate its value clearly to investors who do not know your market, explain its revenue model to people who do not understand your local context, and present a credible path to scale to an audience that is comparing you against opportunities globally.

Most early-stage Nigerian founders have built excellent products and weak investment narratives. The companies that get into rooms like this have spent time often as much time as they spent on the product learning how to tell the story of their company in the language that institutional capital speaks.

This is learnable. It is not a talent you are born with. It is a practice and it starts before you ever walk into a room.

What I take from watching this pattern all year

I have now written about the Google Accelerator, the Flutterwave banking licence, the Landmark Lagos demolition, the Swoop $7.3 million raise, the Moniepoint-Orda acquisition, and in every one of those stories, the same underlying principle appears.

The companies and founders who break through are not the ones with the most features or the most technical sophistication.

They are the ones who understood their market deeply, built something that solved a real and expensive problem for real businesses, communicated that value clearly, and kept moving before everything was perfect.

Eight Nigerian companies will walk into the London Stock Exchange on 29 May 2026.

They did not get there by waiting for the right moment. They got there by building the right things and by being ready to explain why those things mattered when the moment arrived.

That is the work. And it is available to every builder reading this right now.

I write about building products in Africa, what the best companies are doing differently, what the data actually says, and what I am learning as a founder building in this market. Subscribe to this Substack and every new piece comes directly to your inbox.

On the 1st of May 2026, I stood in front of 30 people in Apapa, Lagos.

Not developers. Not founders. Not people who already know what a large language model is.

Beginners. People are starting their tech journey from zero.

SoftLearn had invited me to facilitate the Introduction to AI session at their Tech Starter Training 2026, a free training programme designed to help people take their first steps into technology. I was the second speaker of the day. Two hours. Thirty participants. And one question sitting in the back of my mind before I started:

How do you explain artificial intelligence to someone who has never thought about it before in a way that actually sticks?

I’ve been writing about AI on this Substack for months. I’ve written about Flutterwave’s banking licence, Paperclip’s autonomous companies, the Nigerian AI regulation bill, and the 0.04% of builders using AI. All of it aimed at people who are already building, already thinking, already in the conversation.

This was different.

And teaching something to someone who knows nothing about it is one of the fastest ways to discover what you actually understand and what you have only been repeating.

The moment that set the tone

I opened with a show of hands.

“Before we start, who used their phone today?”

Every hand in the room went up.

“Congratulations. You already used artificial intelligence.”

I watched their faces change.

Google autocomplete is AI. WhatsApp’s spam filter is AI. Instagram’s feed order is AI. Face ID is AI. Google Maps routing is AI. The camera app that adjusts your lighting automatically is AI.

In 60 seconds, before I had explained what AI is, I had already proven that it was in their lives. And that changed the entire energy of the room from anxious to curious.

This is the first lesson I took away from the session:

The biggest barrier to AI adoption is not a lack of access. It’s the belief that AI is something external, a future thing, a foreign thing, a complicated thing. The moment you show someone it is already in the tool they use every day, that barrier dissolves.

Most AI education in Nigeria starts with definitions. What AI is. The history of machine learning. Neural networks. It starts in the abstract and hopes to reach the practical.

I tried to go the other direction. Start with what they already know. Work backwards to the concept.

It worked better than I expected.

The question they were all actually asking

I had structured the two hours around ten sections. History of tech revolutions. What AI is. Types of AI. Free tools. AI in Nigeria. Jobs. Getting started. Ethics. Closing.

But underneath every section, there was really only one question in the room.

Will AI take my job?

Nobody said it out loud in the first hour. But I could feel it in every question that came in sideways. “Is AI going to replace customer service workers?” “What happens to graphic designers?” “Are software developers safe?”

These are not unreasonable fears. They are the same fears that have accompanied every major technology revolution in history, and the historical record is worth taking seriously.

I walked them through it.

The Luddites of the 1800s smashed weaving machines because they believed the machines would eliminate their livelihoods. They were right that the machines changed their jobs. They were wrong that the jobs disappeared; engineering, railways, and manufacturing created millions of entirely new roles that did not exist before.

Typists did not disappear when Microsoft Word arrived. They became executive assistants, editors, content creators, and office managers with more power and better pay than they had before.

Travel agents did not disappear when Booking.com arrived. The ones who survived stopped booking flights and started selling expertise, curation, and experience, the things the algorithm cannot replicate.

The pattern is consistent across every technology revolution: the people who lose are the ones who refused to adapt. The people who win are the ones who learned the new tool first and used it to do things the tool alone cannot.

I also shared the Harvard Business Review finding I have written about on this Substack before, that only 2% of current layoffs are because AI has actually replaced someone. The other 39% are because employers believe AI will replace people within the next six to twelve months. The threat is partly real and partly fear. And fear is what you can act on right now.

I told them the truth: AI will change your job. It may eliminate some parts of it. But the people in the greatest danger are not the people in this room who are learning, they are the people who are not learning.

Something shifted when I said that. The anxiety in the room did not disappear. But it became purposeful rather than paralysing.

What surprised me about the questions

I gave them 30 minutes for Q&A at the end.

I expected questions about tools. Which AI is best? Is ChatGPT free? How do I use it for my business?

I got those. But the questions that caught me were different.

One participant asked: “Is AI biased? Because I’ve heard it doesn’t work as well for African languages.”

That is not a beginner’s question. That is a sharp, important question that a lot of people with much more technical exposure have not thought to ask. I had a slide on AI bias on how AI learns from human data and therefore inherits human biases, how facial recognition systems have shown bias against darker skin tones, and how African languages are underrepresented in training data. But I had not expected a first-time learner to surface it unprompted.

The answer I gave: Yes, AI has bias problems. Significant ones. And those biases affect African users disproportionately in facial recognition, in translation, and in credit scoring models that were trained on Western financial behaviour. This is both a problem and an opportunity. The people best positioned to fix bias in African AI systems are African builders who understand the context that was missing when those systems were built.

Another participant asked: “Can I put my business’s customer data into ChatGPT to analyse it?”

I had a slide on privacy on what not to share with public AI tools. But the question showed something I had not fully appreciated: people are already thinking practically about how to use these tools in their businesses. They are not just curious. They are ready to deploy. What they are missing is the framework to do it safely.

The section I spent the most time on

I had allocated 20 minutes to AI tools you can use today. I ended up spending closer to 35.

Not because the material was complicated. Because once I opened the laptop and started showing them things live, what ChatGPT actually looks like, how to write a prompt, what happens when you ask it a bad question versus a good one, the room came alive in a way that slides cannot replicate.

I asked a participant to give me a topic they were interested in. Someone said, “Starting a small business in Lagos.” I asked ChatGPT to help them write a business plan for a food delivery service targeting students in Yaba. In under 90 seconds, there was a structured plan on the screen.

The room went very quiet.

Then someone said, “That would have taken me a week.”

That is the moment I think about most when I reflect on the session. Not the applause. Not the questions. That sentence from a participant who suddenly understood, in a completely visceral way, what AI actually does to the economics of starting something.

It does not replace your judgment. It does not replace your knowledge of your own market. It does not replace your relationships or your ability to execute.

But it compresses the time between idea and first draft from days to minutes. And for a beginner with limited time, limited resources, and limited access to mentorship, that compression is genuinely life-changing.

The section that matters most for this audience

The part of the presentation I care most about is the section on AI in Nigeria and Africa.

Not because the tools section is not important. But because I think the most meaningful thing I can do as a Nigerian builder talking to Nigerian beginners is to help them see that the opportunity is specifically here, not just globally.

I talked about Flutterwave using AI to detect fraud and improve payment success rates. About Babyl using AI for health consultations in rural Rwanda. About logistics companies using AI to optimise routes across infrastructure that would defeat a Western algorithm.

I made the point I have been making on this Substack all year: Africa has unique problems that the world’s AI tools were not built to solve. The bias issues, the infrastructure constraints, the language gaps, and the financial exclusion are problems. And every problem is a product opportunity for someone who understands both the context and the technology.

Someone in that room in Apapa could build the next great African AI product.

I believe that. I said it out loud. And I meant every word of it.

What I would do differently

I had too much content for two hours.

Ten sections are too ambitious when you are teaching beginners. I covered everything I planned, but some sections moved faster than they deserved. The history of tech revolutions deserves more time. The ethics section, particularly the AI bias and privacy slides, deserved more time.

If I do this again, I would cut two sections and go deeper on the remaining eight. Better for them to leave with four things they really understand than ten things they half-remember.

I would also build more interaction into the middle of the session. The live demo at the end created the most energy. I should have done it earlier, perhaps as the opening hook, before the history section, to show people immediately what we were working toward.

And I would start the Q&A earlier. The best conversations occurred when participants responded to what they had seen, rather than waiting politely for the formal Q&A slot.

Why I’m writing this

I am sharing this not because speaking at SoftLearn was a major milestone. It is a free training programme in Apapa with 30 participants. By the metrics the startup world usually measures, it is a small event.

But something about standing in front of 30 people who are genuinely at the beginning who have never thought about AI before, who came on a public holiday to learn something new about technology, that clarified something for me about why I write this Substack.

I write for builders. For developers. For founders. For people who are already deep in this world.

But the builders of the next decade are in rooms like that one in Apapa right now. There are 30 people on a Friday morning, trying to understand something that confuses, excites and frightens them in equal measure.

The work of demystifying AI, making it accessible, making it specific to the African context, making it feel like an opportunity rather than a threat, that is not just a writing project. It is a responsibility that comes with knowing more than the people around you.

I did not build anything on May 1st. I did not ship a feature, close a deal or publish an article that went viral.

But I helped 30 people understand something they hadn't understood before. And at least one of them asked a question sharp enough to make me think harder about the answer.

That is enough.

I write about building AI products in Africa, what I am learning as a founder, and how the technology is reshaping opportunities across the continent. Subscribe to this Substack it is free, and every new piece goes directly to your inbox.

Aubrey Niederhoffer should be halfway through his sophomore year at UC Berkeley right now.

Instead, he is in Lagos.

Running a 28-person startup. Sitting on $7.3 million in seed funding. Named to the Thiel Fellowship. And already competing in the most punishing food delivery market on the African continent.

He is 19 years old.

I want to talk about what his story means, not for venture capital, not for the super app thesis, not for the Lagos food delivery wars, but for every African developer who is waiting for the right moment, the right funding, the right conditions, to build something real.

Because what Aubrey Niederhoffer did in the last twelve months is the clearest real-world demonstration I have seen of the argument I have been making on this Substack all year.

The gap between having an idea and shipping a product has never been smaller.

The question is whether you are willing to move before everything is perfect.

First, what actually happened here

Let me give you the verified story because the details matter.

Niederhoffer’s connection to Africa started with a geography game. As a tween, he became obsessed with GeoGuessr, an online game where you are dropped into a random location on Google Street View and have to guess where you are in the world. Africa kept appearing. He kept learning.

By the time he was 15, he had launched a recruiting company focused on the labour market in Eswatini, a small, landlocked country in southern Africa. He visited during school breaks.

When he enrolled at UC Berkeley’s Haas School of Business, he had already shut the recruiting company down and was building something new. In August 2025, after his freshman year, he co-founded Swoop in Eswatini alongside Edwin Ruiz. The platform originally launched under the name Thumo and gained 6,000 users in its first month.

That traction was enough to make a decision.

He dropped out of Berkeley, accepted a $250,000 grant from the Thiel Fellowship, and in the fall of 2025 relocated the entire operation to Lagos. Then, and this is the part that every developer reading this needs to sit with their team, rebuild the entire codebase from scratch using AI tools.

Not patched it. Not updated it. Rebuilt it. From scratch. With AI.

The updated app went live in April 2026 in Yaba, a densely populated neighbourhood on Lagos Mainland. The $7.3 million seed round, backed by Long Journey, Variant, Version One, Dune Ventures, Soma Capital, Zero Knowledge Ventures, Base Capital, and Walter Kortschak, was confirmed on April 23, 2026, by Fortune.

Swoop is currently the largest disclosed seed round for an African consumer startup in recent years.

The part that most people are missing

Every headline about this story focuses on the money. $7.3 million. The Thiel Fellowship. The Silicon Valley backers.

But the detail that should matter most to African developers is buried in paragraph eight of most articles.

His team rebuilt the entire codebase from scratch using AI tools.

Think about what that means in practice.

A 28-person team. A product that already had users. A full relocation from Eswatini to Lagos. A new market with completely different logistics, density, and user behaviour. And instead of trying to adapt the existing code to a new context, they started from zero, using AI tools to move faster than a traditional development cycle would allow.

This is not a small detail. This is the thesis.

The argument I have been making since I started this Substack is that AI has fundamentally changed the economics of building software. One developer with the right tools can now build in days what used to take a team of ten weeks. The barrier to shipping has collapsed.

Niederhoffer’s team did not spend six months refactoring old code. They did not spend three months on discovery and planning. They rebuilt the product from scratch in a new country, for a new market, fast enough to launch, raise $7.3 million, and compete with incumbents that have been in the market for years.

That is what AI-assisted development actually looks like when someone takes it seriously.

The Lagos bet and what it tells you about market selection

Let me be honest about what Swoop is walking into.

Lagos food delivery has a graveyard. HelloFood entered and left. Jumia Food entered, scaled, and exited in 2023. Bolt Food entered and retreated. OFood did the same. These were not small companies with thin resources. They were well-funded operations that underestimated what it actually costs to build last-mile delivery infrastructure in a city where traffic is unpredictable, roads flood seasonally, and the logistics challenge changes by neighbourhood.

Swoop launched in Yaba. It has only operated in fair weather. By Niederhoffer’s own admission, he does not yet know how the service will perform during Lagos’s rainy season, which paralyses roads and complicates delivery across the city for months every year.

So why does this still make sense?

Because Swoop is not building a food delivery company.

Food delivery is the wedge. The real bet is on becoming the daily interface through which Nigerians access financial services, payments, savings, and lending in a market where credit card penetration is low, and the fintech competition is between digital players, not entrenched banking infrastructure.

Niederhoffer said it directly: “In Africa, there’s no legacy banking infrastructure. You’re competing with other fintechs. Essentially, you’re not competing with credit cards. Those are not popular, and there’s a huge opportunity.”

He is taking the same playbook that Kaspi built in Kazakhstan and WeChat built in China use a high-frequency daily transaction to build the habit, then layer financial services on top of the trust and usage that creates.

The food delivery app is not the product. The food delivery app is the distribution strategy.

This is a point I have made before about the best African SaaS companies the ones that win are not selling software. They are selling outcomes embedded in daily behaviour that make switching almost impossible.

What a global founder choosing Lagos tells you

Here is something worth saying out loud.

The narrative about Nigeria, especially in global tech circles, has been about talent leaving. Developers relocating to Canada. Founders incorporating in Delaware. The brain drain conversation.

And then a 19-year-old from New York, who could have stayed at one of America’s best business schools and built from Silicon Valley, chose Lagos.

Not as a charity project. Not as an experiment. As a deliberate business decision based on a market opportunity.

He said it clearly: “Over time, I realised that the largest opportunities in many African countries weren’t in exports, they were in domestic markets.”

A teenager from the New York area looked at the global opportunity landscape and concluded that the best place to build his company was Lagos.

That is worth sitting with.

Because African developers who live here, who know the context, who understand the nuances that Niederhoffer is still learning, are still waiting. Waiting for the right idea to be perfect. Waiting for funding that feels certain. Waiting for conditions that will never fully arrive.

Meanwhile, someone who has only been in Nigeria since the fall of 2025 is already living, already funded, and already competing.

The three things Niederhoffer did that most African builders don’t

I want to make this practical. Because the goal is not to admire this story, it is to extract what is replicable.

One: He validated before he scaled.

Swoop did not launch in Lagos first. It launched in Eswatini, a small, manageable market and got 6,000 users before making any bigger bets. That traction de-risked the Lagos move. It proved the concept was real, gave the team operational experience, and gave investors something concrete to evaluate.

Most Nigerian developers launch in their hardest market first. They built for Lagos 25 million people, extreme competition, high operational complexity, without ever testing whether the core product works somewhere simpler.

Start somewhere you can get 100 users before you try to get 100,000.

Two: He used AI to move faster than the conventional timeline allows.

Rebuilding a codebase from scratch is not a small decision. It is expensive, risky, and time-consuming unless you have AI tools that compress the timeline dramatically.

Niederhoffer’s team did not agonise over whether to rebuild. They rebuilt. Because with AI-assisted development, the cost of starting fresh is no longer prohibitive.

The question every African developer building right now should be asking is: Am I using AI to compress my timeline, or am I building the way I would have built two years ago?

Three: He built a product where the first feature is the distribution strategy.

Food delivery is not the point of Swoop. Payments are the point. But you cannot launch a payments app in Lagos and immediately get daily active users.

You can launch a food delivery app, build a daily habit, and then introduce payments to users who already trust you and open the app every day.

The sequencing is the strategy. Which means the first thing you ship is not necessarily the thing you are building toward; it is the thing that builds the relationship with the user who will eventually want the thing you are building toward.

What is your food delivery app? What is the high-frequency, low-stakes entry point that earns you daily access to the user before you ask them to trust you with something more significant?

The honest question

Here is what I want to leave you with.

Aubrey Niederhoffer does not know Lagos the way you know it. He has never experienced a Lagos rainy season with a live delivery operation. He is learning the market in real time, at full speed, with $7.3 million and 28 people and the full force of some of Silicon Valley’s best investors behind him.

You know this market. You have been living in it your whole life.

The gap between you and him is not intelligence. It is not resources many of the tools he used to rebuild his codebase are free or nearly free. It is not an opportunity, because you are sitting in the same opportunity he flew across the world to access.

The gap is movement.

He moved. Before everything was ready. Before the rainy season, the question was answered. Before the unit economics were proven. Before he had a Lagos team fully in place.

He moved anyway.

That is the lesson.

Not the $7.3 million. Not the Thiel Fellowship. Not the Silicon Valley backers.

The willingness to move before it is perfect and to use every available tool to move faster than anyone expects you to.

I write about building products in Africa, what the best builders are doing differently, what the data actually says, and what I am learning while building my own. Subscribe to this Substack and every new piece comes directly to your inbox.

In April 2024, Paul Onwuanibe was on a cruise ship somewhere between Barbados and Miami, celebrating his brother’s 60th birthday.

His phone was barely working. The signal kept dropping. He wasn’t paying much attention to the notifications piling up.

Then he got to a port. The phone came alive. Calls. Messages. Social media alerts. All pointing to the same thing.

The Lagos State Government had issued a 7-day eviction and demolition notice for Landmark Beach Resort, the most visited destination in West Africa. The place Paul had spent 15 years and over $150 million building from a piece of marshland that had no roads, no power, and no water when he bought it in 2007.

He thought it was an April Fools’ Day hoax come early.

It wasn’t.

On April 29, 2024, government bulldozers moved through the property. What had taken six years to build was reduced to rubble in six hours. A $200 million resort. More than 80 businesses. Over 4,000 direct jobs. 3.5 million visitors a year. Gone.

The reason? The Lagos State Government said the property fell within the right-of-way of the planned 700-kilometre Lagos-Calabar Coastal Highway, a road whose plans were drawn up years after Paul had purchased the land.

Paul Onwuanibe estimated the loss at $80 million.

And here is what I want you to sit with as a builder:

Paul did not lose Landmark Beach Resort because he built it poorly. He lost it because he built it on land he did not ultimately control.

The Lesson Nobody Is Saying Out Loud

Most of the coverage of the Landmark demolition focused on the injustice. The lack of due process. The political implications. The government overreach.

All of that is real and worth discussing.

But there is a quieter lesson underneath the outrage that applies directly to every Nigerian SaaS builder sitting at a laptop right now, building something they plan to grow into a real business.

You can build something extraordinary, truly extraordinary, and still lose it overnight if you build it on infrastructure you do not own.

Paul built on physical land. His vulnerability was a government notice.

But the principle is the same for digital builders.

If your SaaS product depends entirely on WhatsApp Business API, Meta can change the terms and cut you off tomorrow. If your distribution is entirely built on Instagram’s algorithm, a platform update can erase your reach overnight. If your payments run through a single provider whose licence gets revoked, as Nigerian fintech has shown is possible your revenue stops moving. If your entire product is hosted on a free tier of a cloud service that changes its pricing, your unit economics collapse.

Every one of these is a version of the same 7-day notice that arrived on Paul’s phone between Barbados and Miami.

The question is not whether it will happen. The question is how exposed you are when it does.

Paul Built Everything. And Then Lost It.

Let me give you the full context of what Landmark Beach Resort actually was, because I want you to understand the scale of what was demolished and, therefore, the scale of the risk that every builder carries when they build without owning the foundation.

Paul Onwuanibe came back to Africa in the early 2000s after a career that had taken him through London, Frankfurt, Paris, Tokyo, and New York. He had spent six years helping build Regis, later known as IWG, into what became the world’s largest flexible office network. He had sold a 14-city African office business for $20 million.

And then he took every single penny of that $20 million, borrowed another $20 million, and put it all into a piece of marshland on Victoria Island that nobody wanted.

No roads. No electricity. No piped water. No infrastructure of any kind.

He built the roads himself. He installed the electricity. He created sea barriers. He solidified the land. And then, over 15 years, he built the Hard Rock Cafe, three hotels, a beach, an event centre, over 80 businesses, medical facilities, retail spaces, and a members club with 167,000 paid members.

The most visited destination in West Africa.

3.5 million visitors a year.

More visitors in a single year than some African countries receive in total.

And then came the 7-day notice.

Paul describes going through the five stages of grief. Denial. Anger. Bargaining. Acceptance. And then and this is the part I want you to pay attention to figuring out what to do next.

He did not quit.

He announced plans to enter two more African countries, establish a presence in three Nigerian states, and move Landmark’s headquarters out of Lagos. Because the skills, the experience, the relationships, and the brand those things were never in the building. Those things belonged to him. The building was an infrastructure. The real asset was portable.

What This Means for How You Build

There are three specific decisions that most Nigerian SaaS builders often make unconsciously that create the same kind of foundational exposure Paul experienced.

One: Building your distribution on platforms you do not own.

The most common version of this is a business that has grown its entire audience on Instagram, TikTok, or LinkedIn without ever building a channel it controls. When the algorithm changes, the reach disappears. When the account gets flagged, the business goes silent.

Paul’s equivalent was building on land whose ultimate ownership was contested by a government infrastructure project. The business was real. The customers were real. The revenue was real. But the foundation could be challenged by a decision made in a ministry somewhere that had nothing to do with the quality of what had been built.

Your email list is land you own. Your Substack subscribers are land you own. Your direct customer relationships people who have given you their contact information and their trust are land you own. Everything else is rented.

This Substack is not a vanity project. It is the only distribution channel I will ever own completely. Nobody can send me a 7-day notice to vacate it.

Two: Building your product on top of a single dependency.

Most early-stage SaaS products have a critical dependency that they have not thought seriously about. A single payment provider. A single AI API. A single cloud hosting provider. A single regulatory licence.

When that dependency fails, not if, the question is whether you built with enough modularity to survive it.

Flutterwave understood this instinctively. Their acquisition of Mono and their banking licence were not just growth moves. They were moves to eliminate dependencies. To own more of the stack. To reduce the number of third parties who could send them a 7-day notice.

The lesson is not to avoid dependencies entirely, that is impossible. The lesson is to know which dependencies are existential and build redundancy into those first.

Three: Confusing impressive metrics with real ownership.

Landmark Beach Resort had extraordinary metrics. 3.5 million annual visitors. 167,000 members. 4,000 employees. Over 80 businesses. These numbers were real.

But metrics do not confer ownership. Revenue does not confer ownership. Footfall does not confer ownership. Only the actual legal, technical, and contractual control of your critical infrastructure confers ownership.

For a SaaS business, that means: do you own your codebase? Do you control your data? Do you have direct relationships with your customers that exist outside of any single platform? Do you have contractual agreements with your key suppliers that protect you from unilateral changes?

If the answer to any of those is no, you have metrics without ownership. And metrics without ownership is a building on land someone else controls.

The Part That Should Actually Inspire You

I do not want to end on pure caution. That is not the lesson Paul Onwuanibe took from the demolition of Landmark Beach Resort.

When he was driving to meet a government official on the morning of the demolition, the worst morning of his business life, a friend called and asked him to stop by. Paul spent 30 minutes complaining. And when he finished, he asked his friend why he had called.

His friend’s wife had died that morning. His children were in Canada. He needed advice on how to tell them.

Paul said something about that moment that has stayed with me.

The losses are real. They are devastating. But perspective comes from understanding what you are actually measuring.

He lost $80 million in assets. He did not lose the thing that built them.

The skills that turned a marsh into a destination are portable. The relationships that brought Google, Microsoft, and IBM into his buildings are portable. The knowledge of how to read a market, find a waterfront, build roads, attract visitors, and create an experience that makes people come back is portable.

He is now expanding into Gambia, Liberia, and multiple Nigerian states. Not starting over. Continuing on better foundations, with lessons that cost $80 million to learn.

For a SaaS builder, the equivalent is this: the code can be rewritten. The product can be rebuilt. The relationships you build with customers are yours to take anywhere. The knowledge of what the market needs and how to deliver it is yours permanently.

What you cannot take with you is the thing built entirely on infrastructure you never owned.

Build the portable things first. Then use them to acquire the infrastructure.

The Practical Audit

Before you go back to building, do this. It takes 15 minutes and it may be the most valuable 15 minutes you spend this week.

Write down every critical dependency your product has. The payment provider. The AI APIs. The cloud host. The social media platforms are driving your traffic. The regulatory licences you need to operate. The data infrastructure your product runs on.

For each one, ask: What happens to my business tomorrow if this disappears?

If the answer is “it collapses immediately,” that dependency is your marshland. You are building something real on ground someone else controls.

You do not need to eliminate all of these immediately. You need to know which ones are existential and build a plan, even a slow one, to reduce that exposure.

Paul knew that marshland was risky. He bet on it anyway because the opportunity was real. But the lesson he carries forward is not to bet the entire basket on one piece of ground ever again.

Geographic diversification. Multiple leases. Multiple markets. Multiple locations.

The digital equivalent is: multiple distribution channels, multiple technical dependencies, multiple revenue streams.

Not because you are afraid. But because the opportunity of a lifetime can only be realised in the lifetime of that opportunity and a 7-day notice has a way of ending lifetimes very quickly.

One Last Thing

Paul Onwuanibe was asked what he would do differently if he could go back.

He said he would have paid more attention to the things that can go wrong that are outside your control. He would have tried to foresee and perhaps forestall what happened.

He also said: You cannot change the cards you are dealt. You can only change the hand you play.

That is not a resignation. That is a strategy.

Play the hand you have. But before you go all in, know which cards are yours to keep and which ones someone else can take back without warning.

I write about building products in Africa the decisions that determine whether something survives and scales, and the lessons that cost other people too much to learn quietly. Subscribe to this Substack and every new piece comes directly to your inbox.

You probably already know the story.

On Monday, a special assistant to President Tinubu posted on social media that the federal government had approved a $75 million investment in Flutterwave through the Ministry of Finance Incorporated. The post also claimed Flutterwave was preparing a $250 million IPO on the Nigerian Exchange.

Nigerian tech Twitter erupted. Headlines ran across every major publication. By midday, the story had spread globally.

By evening, Flutterwave had denied everything.

“We would like to clarify that the information circulating is inaccurate, including the reported $250 million figure. Flutterwave is not in any way close to an IPO and has made no announcements regarding a listing or fundraising tied to an IPO as described.”

The presidential aide deleted the original post. The Presidency issued no explanation. The Ministry of Finance said nothing. And Flutterwave was left standing before the entire global fintech investment community, correcting a story someone else had told about their own company.

This is not a story about $75 million.

This is a story about narrative, who controls it, what happens when you lose it, and why every builder in Nigeria needs to understand this before they learn it the hard way.

First, what actually happened here?

Let me reconstruct the sequence, because it matters.

In the last three months alone, Flutterwave has made three significant moves.

They acquired Mono, the open banking infrastructure startup, in an all-stock deal valued between $25 million and $40 million. They secured a microfinance banking licence from the Central Bank of Nigeria, allowing them to hold deposits and offer loans directly for the first time in ten years. And their CEO, Olugbenga Agboola, joined President Tinubu during Nigeria’s first UK state visit in 37 years as part of the Nigerian private sector delegation.

I wrote about this earlier this year. The moves are deliberate. Systematic. Each one extends Flutterwave’s ownership of the financial infrastructure stack.

Against that backdrop, a presidential aide posted that the government was taking a stake in Flutterwave’s IPO.

The post was specific. It mentioned $75 million. It mentioned the Ministry of Finance Incorporated. It mentioned a $250 million IPO tranche. It said the government would hold 30% of the IPO offering as an anchor investor. It described a formal due diligence process involving two of the world’s four largest accounting firms.

This was not vague speculation. Someone wrote those details down and posted them publicly.

And then Flutterwave said none of it was true.

The thing that nobody is talking about

Every publication covering this story is asking the same questions. Was there actually a deal? Did the government jump the gun? Is an IPO coming eventually? What is Flutterwave’s real timeline?

These are reasonable questions. But they are the wrong questions for a builder to be asking.

The question worth asking is this:

How did Africa’s most valuable private fintech company end up in a position where it had to publicly correct its own story, and what does that mean for you?

Because Flutterwave did everything right. They built an exceptional product. They acquired strategically. They got regulatory approval. They cultivated government relationships at the highest level.

And then someone else told their story. Publicly. Prematurely. With enough specific detail to be convincing. And they had to spend the credibility they had spent years building to correct it.

That is a narrative failure. And it is one of the most expensive things that can happen to a company, at any stage.

What narrative control actually is

Most builders think about their product. Their technology. Their team. Their funding.

Very few think systematically about their narrative, the story that exists in the minds of investors, customers, journalists, regulators, and the public about what their company is, where it is going, and why it matters.

But your narrative is an asset. A real one. One with measurable value.

When investors hear your company’s name, they have an instant mental model. When customers consider your product, they are buying into a story as much as a feature set. When regulators evaluate your compliance, they are partly evaluating the reputation that precedes you. When journalists cover your space, they slot you into a narrative framework that shapes how millions of people understand what you do.

That mental model, that narrative, is built deliberately or by accident. And if you are not building it deliberately, someone else will build it for you.

This is what happened to Flutterwave on Monday.

The government’s enthusiasm for the tech sector is genuine. The interest in Flutterwave specifically is understandable; they are the most prominent Nigerian tech success story of the last decade. But enthusiasm without coordination became a liability.

When the government announced an investment that a company immediately denied, it raised concerns about policy coordination, institutional discipline, and market maturity. Flutterwave chose to protect credibility with investors over preserving political convenience. That decision sends a strong signal: in global capital markets, reputation and trust carry more weight than premature applause.

That last sentence should be on the wall of every founder’s office in Nigeria.

The three specific ways builders lose control of their narrative

One: Premature announcements from people who are not you.

The Flutterwave situation is an extreme version of something that happens to builders at every stage. A well-meaning advisor mentions your startup to an investor before you are ready. A partner announces a collaboration before the terms are finalised. A journalist publishes details from a background conversation you thought was off the record.

You did not put that information out. You did not control the framing. And now you are responding to someone else’s version of your story instead of telling your own.

The protection against this is not secrecy. It is clarity. Everyone in your orbit, advisors, investors, government contacts, and strategic partners, should know exactly what can be shared publicly, what is under discussion privately, and what the consequences are of confusing the two.

Two: Letting your product speak for itself when it can’t yet.

Your product does not speak. You speak for it.

I see this constantly in Nigerian developer communities. Someone builds something genuinely impressive, puts it on GitHub, shares a demo, and then waits for the world to discover it.

The world does not discover things. The world responds to stories told by people who understand how to tell them.

Every feature you ship, every customer you sign, every problem you solve is raw material for a story. But it does not become a story until you frame it, publish it, and put it in front of the people who need to hear it.

If you are not telling your story consistently and deliberately, the narrative vacuum will be filled. By competitors. By people with partial information. By the market’s default assumptions about what a product like yours must be.

Three: Confusing momentum with narrative.

The most dangerous narrative trap is the one Flutterwave almost fell into through no fault of its own.

When things are going well, when you are acquiring companies, getting licences, meeting presidents, there is a temptation to let the momentum tell the story. Things are clearly moving. People can see the direction. Surely that is enough.

It is not enough.

The market is looking for a “lighthouse event” , a major exit or listing that proves the maturity of the Nigerian fintech space. The fact that the government is even in the Flutterwave conversation shows how central fintech has become to Nigeria’s economic narrative.

But being central to a narrative and controlling that narrative are two completely different things. The bigger your company becomes, the more other people want to write your story. Investors want to tell their LPs you are in their portfolio. Government officials want to signal proximity to success. Journalists want to break the news. Partners want to announce the collaboration.

None of these people are malicious. But none of them are you.

What Flutterwave got right , even in the middle of the chaos

I want to give credit where it is due.

Flutterwave’s response to this situation was fast, clear, and unambiguous. They did not hedge. They did not say “we are exploring various options.” They did not let the story run for a news cycle while they figured out what to say.

They said: this is inaccurate. Here is what is actually true. We are not close to an IPO.

That clarity is itself a form of narrative control , taking back the story by being the most authoritative source of truth about your own company.

They also made a choice that is worth noticing. Flutterwave appears focused on internal readiness rather than near-term fundraising. Whether and when it ultimately taps public markets remains an open question.

They chose credibility with the global investment community over political convenience with the Nigerian government. In a country where government relationships can determine regulatory outcomes, that is not a small choice.

It is the right choice. And it tells you something about how Flutterwave thinks about its long-term narrative , as a global financial infrastructure company, not as a government-adjacent success story.

The practical lessons for builders at every stage

You are not Flutterwave. You do not have a $3 billion valuation and a government trying to invest in your IPO.

But the narrative principles are the same at seed stage as they are at pre-IPO stage. And the habits you build now determine how you will handle the bigger moments later.

Control your announcement cadence. Every significant development in your company , a new customer, a product update, a partnership, a funding round , should be announced by you, in your own words, at a time of your choosing. Not leaked. Not pre-announced by a partner. Not broken by a journalist who got a tip. Make a discipline of announcing things yourself, in the right channel, with the right frame.

Brief everyone in your orbit. Advisors, investors, government contacts, strategic partners , everyone who knows things about your company that are not yet public should understand clearly what is and is not shareable. This is not paranoia. It is basic narrative hygiene.

Build your publication channel now. This Substack is mine. I use it to tell my own story , what I am building, what I am learning, what I believe about the market. When someone else tells a story about GinuxAI or BuySmart, there is a body of work they will be measured against. That body of work is the authoritative source.

You need that too. A newsletter. A consistent LinkedIn presence. A clear voice. Not for vanity , for control. The builder who has a strong publication channel has somewhere to go when the narrative needs correcting. The builder who does not has to fight on other people’s terrain.

Know the difference between information and story. The government had information about Flutterwave , meeting notes, financial data from the due diligence process, conversations with executives. But information is not a story. Story is information with framing, context, and intent. The aide who posted did not understand the difference. The result was a story told without framing, context, or the consent of the company it was about.

When you share information about your company , with journalists, with investors, in conference panels , always be conscious of the story that information will become in someone else’s hands.

One more thing worth saying

I started writing about Flutterwave earlier this year because their journey from payments API to banking licence is the clearest illustration I have found of what it looks like to build with intention.

Every move is deliberate. Every acquisition strategic. Every regulatory milestone part of a larger architecture.

The $75 million saga does not change that story. In some ways, it confirms it, because the government’s interest, even when misdirected, is a response to the real and undeniable progress Flutterwave has made.

But it also reveals the vulnerability that comes with being the most prominent company in your ecosystem. Everyone wants to be part of your story. And wanting to be part of a story has a way of making people think they have the right to tell it.

Your job as a builder, from the first day to the day you ring the bell on a stock exchange or hand your company to an acquirer, is to be the person who tells your story.

Not because the other versions are malicious.

But because only you know what it means.

I write about building products in Africa, what works, what the biggest companies are doing that most builders miss, and what I am learning while building my own. Subscribe to this Substack and every new piece comes straight to your inbox.

Less than 1%.

That’s the acceptance rate for the 10th cohort of the Google for Startups Accelerator Africa.

2,600 applications came in from across the continent. 15 startups made it through. Four of them are Nigerian.

The four: Bani, MasteryHive AI, Regxta, and Termii.

I want to talk about what those four startups have in common. Not because getting into a Google accelerator is the point, it isn’t. But the pattern behind their selection tells you something important about what it actually takes to build a product worth paying attention to in 2026.

And most Nigerian builders are doing the opposite of what these four got right.

First, who are they?

Let me make this concrete before I extract the lessons.

Bani is building cross-border payment infrastructure to reduce settlement delays for African businesses operating internationally. Payment friction across African borders is one of the most expensive, most persistent problems in the continent’s digital economy. Bani is building the plumbing.

MasteryHive AI automates transaction reconciliation, fraud detection, and anti-money laundering processes. If you have ever worked with or for a financial institution in Nigeria, you know that reconciliation is still being done manually in places where it absolutely should not be. MasteryHive AI is fixing that.

Regxta deploys alternative credit scoring for underserved businesses. Nigeria has 41 million SMEs. Most of them cannot access credit through traditional channels because they lack a formal credit history. Regxta builds the models that look at different signals to determine creditworthiness for businesses that the traditional system ignores.

Termii provides an AI-driven communications infrastructure for financial messaging, the notifications, OTPs, and transactional messages that fintech products depend on to function.

Now look at those four descriptions carefully.

What do they all have in common?

The pattern that got them selected

Every single one of them is B2B infrastructure.

Not a consumer app. Not a dashboard. Not a platform that asks users to log in and figure things out.

Infrastructure. The kind of product that other products are built on top of. The kind that, once embedded, is extremely difficult to remove.

Bani is the payment rails other fintech products need. MasteryHive AI is the compliance layer that financial institutions need. Regxta is the credit intelligence that lenders cannot operate without. Termii is the messaging backbone that every fintech product in Nigeria depends on for OTPs and notifications.

These are not nice-to-have products. They are must-have products. Products where the cost of switching is high, the dependency is deep, and the value delivered is directly measurable.

This is the first lesson. And it connects directly to something I have been writing about for months.

The best products do not help users work. They become infrastructure that other products and entire businesses are built on.

Flutterwave started as a payments API. Mono was an open banking API. Now Flutterwave has acquired Mono and got a banking licence. Why? Because owning the infrastructure layer is worth infinitely more than owning the interface layer.

These four Google-selected Nigerian startups understand that instinctively. They are not building features. They are building pipes.

Lesson two: They chose problems with density

Look at the sectors these four startups operate in.

Cross-border payments. Fraud detection and reconciliation. Credit scoring for SMEs. Financial messaging infrastructure.

Every single one of these problems affects thousands of businesses simultaneously. These are not niche problems with ten potential customers. They are dense problems where solving it once means you can sell it to hundreds, then thousands of companies without rebuilding from scratch.

This is the difference between a consulting project and a scalable product.

A consulting project solves a problem for one client, gets paid once, and moves on. A scalable product solves a problem that many clients share, gets paid repeatedly, and compounds.

The test for whether your product idea is dense enough is simple: can you name 50 companies in Nigeria right now that would pay for this? Not hypothetically, actually name them. If you can, the problem has density. If you are struggling after ten, you are probably too narrow.

All four of these startups pass that test easily. Every bank, every fintech, every lending platform, every digital business in Nigeria is a potential customer for at least one of them.

Lesson three: they built before they pitched

The acceptance rate for this programme is under 1%.

That means the selection committee is not picking ideas. They are picking products that are working.

Termii has been live for years. They power communications for some of the biggest fintech companies in Nigeria. They were not selected because they had a good pitch deck about financial messaging infrastructure. They were selected because they had a live product with real customers and real revenue.

The same applies to all four. These are not early-stage ideas that got lucky. These are products with traction, with case studies, with proof that the market is willing to pay.

This is the lesson that I think most Nigerian builders resist the most.

We want to apply for programmes, funding, and recognition before we have built the proof. We want validation before we have earned it. We want investors and accelerators to believe in the vision before we can show them the reality.

But every serious programme, every serious investor, every serious customer is looking for the same thing first: evidence that this works.

Evidence does not mean millions in revenue. It means one client who pays. It means a case study that shows the problem, the solution, and the measurable outcome. It means a product that is live and being used, not a prototype being polished.

Build first. Apply second. In that order, always.

Lesson four: They used AI as an ingredient, not the headline

This one is subtle but important.

All four of these startups use AI. The accelerator selected them specifically because they are leveraging AI to tackle key challenges.

But none of them leads with “we are an AI company.”

Bani leads with cross-border payments. MasteryHive leads with reconciliation and fraud. Regxta leads with credit access. Termii leads with communications infrastructure.

AI is how they deliver the solution, not what they are selling.

This distinction matters enormously.

“We use AI” is not a value proposition. “We cut your reconciliation time from three days to three hours” is a value proposition. “We help you reach previously uncreditworthy SMEs with confidence” is a value proposition. “We ensure your OTPs never fail and your customer never get locked out of their account” is a value proposition.

The companies building in 2026 that are winning are not the ones saying “AI-powered platform.” They are the ones saying “we eliminate this specific, expensive, painful problem”, and using AI as the engine that makes that possible.

If your pitch starts with the technology, you have it backwards. Start with the problem. Start with the cost of the problem. Start with what life looks like after the problem is solved. Then, almost as an afterthought, explain that AI is how you do it.

Lesson five: the programme itself is not the point

Here is something worth saying clearly.

Getting into the Google for Startups Accelerator is a validation signal. It is not a business model.

The accelerator is equity-free. It provides technical support, mentorship, and access to Google’s network. Since 2018, participating startups have collectively raised over $263 million. That is real value.

But the startups that will get the most from this programme are the ones that were already building something real before they applied. The programme accelerates what is already working. It does not create something from nothing.

I say this because I see a pattern in how Nigerian developers think about accelerators, grants, and competitions. We treat them as the goal. We optimise for getting in. We measure success by acceptance, not by outcomes.

The four startups selected today did not get in because they were good at applications. They got in because they were building products that were already working in a market that clearly needs them.

The accelerator is a reward for the work that came before it, not a shortcut to skip the work.

What this means for you

You do not need to get into a Google accelerator to build a product worth building.

But you do need to think like the founders who did.

Find a genuinely painful problem that affects many businesses or people simultaneously and has a measurable cost. Not a slightly inconvenient problem. A problem that is costing your target customer real money, time, or risk every single day.

Build something that solves the core of that problem. Not the full vision. The core. The thing that, if it worked perfectly, would make your first ten customers say they cannot imagine going back.

Get those first ten customers. Charge them. Document what changed for them. Make the case study specific and measurable.

Then, and only then, start applying to programmes, pitching to investors, or scaling the product.

The four Nigerian startups in this Google cohort did not stumble into a less than 1% acceptance rate. They built their way there, one customer and one solved problem at a time.

That path is available to every builder reading this.

I write about building products in Africa, what works, what doesn’t, and what the best builders on this continent are doing differently. Subscribe to this Substack, and I’ll send every new article directly to your inbox.

This morning, at 6:00 a.m., Nigeria’s Corporate Affairs Commission portal came back online.

For three days, from April 17 to this morning, the platform that every Nigerian startup, every business registration, and every compliance filing depends on was completely shut down.

Not for routine maintenance. Because it was hacked.

On April 15, the CAC confirmed a cybersecurity incident involving unauthorised access to parts of its internal systems. The commission processes up to 10,000 business registration requests daily. It handles 5,000 customer enquiries every single day. And for three days, every single one of those transactions was suspended while investigators worked to understand what was breached, what data was exposed, and whether Nigerian businesses, from startups to multinationals, had their corporate records compromised.

The attack is still being investigated. The full scope of what was accessed has not been disclosed.

But while Nigeria waits for the results of that investigation, I want to talk about something that nobody is saying loudly enough.

The CAC is not the only Nigerian digital platform sitting on a mountain of sensitive business data with security infrastructure that hasn’t kept pace with the scale of what it’s protecting.

A lot of Nigerian SaaS products are in the same position.

And most founders have never thought seriously about it.

Why this should matter to every Nigerian SaaS builder

Let me be specific about what the CAC actually holds.

Company registration records. Director information. Share structures. Beneficial ownership data. Annual return filings. Corporate compliance history. For thousands of startups, SMEs, and multinational operations across Nigeria.

When you register a company in Nigeria, you hand the CAC a comprehensive picture of your business. And until last week, you probably assumed that picture was safely stored.

Now think about your own product.

What data do your users hand you when they sign up? What do they enter into your platform? What transactions do you process, what records do you store, what personal or business information sits in your database right now?

If the answer is “quite a lot”, and for most SaaS products, the answer is quite a lot, then the CAC attack is not just a news story. It is a preview of the risk that your product carries every day.

And the uncomfortable question is: if someone came for your database tonight, how bad would it be?

The 95% problem

At GITEX Africa last week, just days before the CAC breach was disclosed, NITDA’s Director General Kashifu Inuwa said something that landed differently after the attack.

He said that 95% of digital security breaches are caused by human error.

Not sophisticated state-sponsored hacking. Not zero-day exploits that require advanced technical knowledge to execute. Human error.

Misconfigured servers. Weak credentials. Unpatched systems. Employees clicking phishing links. Default passwords that were never changed. APIs are left open without authentication.

The uncomfortable truth is that most of the security failures that lead to data breaches are not inevitable. They are preventable. They happen because nobody made security a priority until after something went wrong.

This is the pattern that has played out globally. And it is the pattern playing out in Nigeria right now, the CAC, Remita Payment Services, and Sterling Bank, all in the same month.

Inuwa also said something else that builders need to sit with: AI is making these breaches harder to identify. The tools available to attackers are getting better faster than the defences most platforms have in place.

Which means the window to get your security house in order is narrowing.

What Nigerian SaaS builders are actually doing wrong

I want to be honest here, including about things I have had to correct in my own products.

Storing more data than you need. The first mistake most SaaS products make is collecting and storing data they do not actually need for the product to function. Every extra field you store is an extra liability. If you do not need a user’s date of birth to deliver your service, do not ask for it. If you do not need to retain payment details, do not store them; use a payment provider that handles that responsibility. Data minimisation is not just a regulatory concept. It is a security practice that reduces your attack surface.

Weak authentication on admin panels. The most common entry point for attackers targeting SaaS products is not the user-facing frontend. It is the backend admin interface that founders build quickly, secure loosely, and forget about. Default credentials, no two-factor authentication, admin routes that are not rate-limited, these are the open doors that attackers walk through. If your admin panel is accessible from the public internet with a simple username and password, you have a serious problem today, not a theoretical future risk.

Unencrypted data at rest. If your database is compromised and your data is stored in plain text, an attacker who gets access to your database gets everything. Encrypting sensitive fields, passwords (with proper hashing, not encryption), personal identifiable information, and financial data means that a breach of your database is not automatically a breach of your users’ data. This is table-stakes security that too many Nigerian SaaS products skip because it adds complexity to the initial build.

No incident response plan. The CAC’s response to the breach was slow and vague partly because, like most organisations, they did not have a clear plan for what to do when this happened. Most Nigerian SaaS founders have never thought through: who gets notified if there is a breach, what do we tell users, how do we shut down compromised systems, what do we preserve for investigation? Having a plan before you need it is the difference between a controlled response and panic.

Treating security as a phase two problem. This is the biggest one. Security gets pushed to “after we get users,” “after we raise funding,” or “after we build the features we need.” But the cost of retrofitting security into a production system with real users is dramatically higher, in time, money, and risk, than building it in from the start. Every week you ship without proper security is a week you are accumulating technical debt that could end your startup.

What the NITDA regulation means for this

I wrote recently about Nigeria’s incoming AI regulation, the National Digital Economy and E-Governance Bill that gives NITDA enforcement powers over digital platforms.

The CAC attack has made that regulation more urgent, not less.

One of the requirements under the incoming framework is that organisations deploying AI systems, or handling significant volumes of user data, must implement governance and risk management measures proportional to the potential impact of their systems.

That language is directly relevant to the security failures the CAC attack has exposed.

When NITDA begins active enforcement, platforms that have not taken data security seriously will not just face reputational risk. They will face regulatory risk , fines, compliance orders, and potentially forced shutdowns.

The CAC attack, happening the same week as NITDA’s Director General was at GITEX Africa warning about cybersecurity threats, is the government making a visible point about why this regulation matters?

The question for Nigerian SaaS builders is whether you will take that point seriously before enforcement or after.

Five things to do this week

I want to be practical, not just cautionary.

One: Audit what data you are storing. Go through your database schema right now. List every type of data you hold. Ask whether you actually need each field. Delete what you do not need. For what you do need, make sure it is encrypted or hashed appropriately.

Two: Secure your admin access. Enable two-factor authentication on every admin account. Restrict admin routes to specific IP addresses if possible. Rate-limit login attempts. Change any default credentials immediately.

Three: Check your dependencies. Most SaaS products use open-source packages and third-party libraries. Many breaches happen through vulnerabilities in dependencies, not the code you wrote yourself. Run a dependency audit; tools like npm audit for Node.js or pip-audit for Python will flag known vulnerabilities in your stack. Update what needs updating.

Four: Set up basic monitoring. You should know when something unusual is happening in your system before your users tell you. Set up logging for failed authentication attempts, unusual data access patterns, and unexpected API calls. Simple tools like Sentry for error monitoring and basic server logging can alert you to anomalous activity before it becomes a full breach.

Five: Write a one-page incident response plan. Who on your team gets called first if there is a breach? What systems do you shut down? Who do you notify: users, regulators, investors? What data do you preserve for investigation? Write it down. Put it somewhere your team can find it. A plan you have never written is a plan you will not execute under pressure.

The bigger picture

The CAC attack is not an isolated incident. It is part of a pattern: government systems, fintech platforms, payment providers, all facing increasing pressure from increasingly sophisticated attackers.

And the lesson from every breach that has happened is the same. It was preventable. There were warnings. Nobody acted until it was too late.

Nigerian SaaS builders are operating in a market that is growing fast, attracting global attention, and about to come under serious regulatory scrutiny. The products that survive and scale will not just be the ones with the best features. They will be the ones that users trust with their data, and deserve to be trusted.

The CAC portal came back online this morning.

The question is: if your platform went down because of a breach tonight, would it come back?

I write about building SaaS, shipping products in Africa, and the practical decisions that determine whether something succeeds or fails. If this was useful, subscribe to this Substack so you don’t miss the next one.

Something interesting is happening.

International companies from Silicon Valley, London, and Berlin are actively hunting for Nigerian developers. Not as a last resort. Not because we’re cheap. But because we’re genuinely good.

Nigeria now has over 1.1 million developers, one of the largest tech talent pools in Africa. Lagos was ranked the fastest-growing tech ecosystem globally in 2025. Companies report that Nigerian engineers bring problem-solving skills, resilience, and creativity that they struggle to find elsewhere.

And yesterday at the GITEX Africa summit in Morocco, NITDA’s Director General Kashifu Inuwa said something that should be hanging on the wall of every Nigerian developer’s workspace:

“We want to keep the intelligence in our country. We want to be part of creating value, not just receiving technology.”

So here’s the question that’s been sitting with me all week.

If Nigerian developers are globally recognised as some of the most capable technical talent on the planet, and if even our own government is saying we should be creating value, not just providing labour, why are most of us still dependent on a salary that someone else controls?

Why are we the most sought-after talent in the world, working for other people’s wealth?

The gap between talent and wealth

Let me say something that might be uncomfortable.

Being technically excellent and being wealthy are two completely different things. And most Nigerian developers, myself included, for a long time, have confused one for the other.

We have spent years getting good at building. Really good. Genuinely world-class good, as the global demand for our skills is now confirming.

But building skill and wealth-building skill are not the same thing.

The top five wealthiest people in the world right now all have software engineering backgrounds. That is not a coincidence. But they did not get there because they were the best coders in the room. They got there because they figured out how to turn technical capability into business outcomes, and then own those outcomes rather than selling them for a salary.

The distinction is everything.

Right now, if you are a Nigerian developer contributing to a company’s systems, whether that company is in Lagos or London, you are generating value that is multiples of what you take home. A company does not pay you ₦5 million a year unless you are producing significantly more than ₦5 million in value. That gap, between what you produce and what you are paid, is the business model of employment.

And there is nothing wrong with that arrangement, until you realise that the skills creating that gap are yours. And you could be on the other side of it.

The stereotype that is keeping us poor

There is a belief that runs deep in Nigerian developer culture, and in developer culture globally, but it is particularly pronounced here.

The belief is that coding is the job. That technical skill is the product. The way a software engineer creates value is by writing excellent code.

And so we optimise for that. We learn new frameworks. We study algorithms. We get certifications. We become better and better at the craft.

Meanwhile, the people who are actually getting rich from software engineering are not the ones who are the best coders. They are the ones who learned to pair technical capability with something else: the ability to identify a business problem, communicate a solution in terms a non-technical person can understand, and charge appropriately for solving it.

Here is what that gap looks like in practice. Tell a business owner in Lagos that you can build a scalable microservices architecture with containerised deployment pipelines, and they will look at you blankly. Tell them you can make sure their staff never have to manually enter customer data ever again, and they will ask how quickly you can start.

Same capability. Completely different conversation. And only one of those conversations ends with someone paying you.

The engineer who can do both, understand problems at the business level and solve them at the technical level, does not compete with anyone. Not other developers. Not AI. Not outsourcing. That combination is rare and extraordinarily valuable.

Business people cannot build it. Most developers cannot sell it.

If you are sitting in Lagos right now with years of engineering experience, you already have the harder half. The half that took years to build, the logical thinking, the systematic problem-solving, the technical depth. The other half, learning to speak the language of business outcomes, is learnable in months if you are deliberate about it.

What “creating value” actually means for Nigerian developers

NITDA’s Director General used the phrase “creating value” at GITEX Africa yesterday.

I want to unpack what that means at the individual level, not the policy level.

Creating value as a Nigerian developer is not the same as writing code for a foreign company’s product. That is receiving a salary while someone else owns the value you create.

Creating value means owning the outcome.

It means finding a specific problem in your network, your community, your city, that you are uniquely positioned to solve. It means building a service or a product around that problem. It means charging for the outcome, not the hours. It means, over time, building something that generates revenue, whether you are at your desk or not.

This is not a lecture about entrepreneurship in the abstract. This is a practical observation about leverage.

Nigerian developers have three assets that most people in the world do not have simultaneously: deep technical skill, local market knowledge, and in-person access to businesses that are desperately underserved by technology.

That combination is the definition of leverage.

The logistics company in your area that is still running operations on WhatsApp messages and Excel sheets. The school that loses student records because nobody has built a proper system. The healthcare clinic that cannot track patient history across visits. The market trader loses sales because payment collection is manual and slow.

These are not abstract problems. There are problems you walk past every day. And you, right now, have the technical skill to solve every single one of them.

The question is whether you will build the bridge or keep working on someone else’s bridge.

Service before SaaS, and why this applies to Nigerian developers right now

If the idea of building your own business sounds complicated, I want to simplify it.

You do not start with a SaaS platform. You do not need VC funding. You do not need a co-founder, a team, or an office.

You start with a service. One problem. One client. One solution.

Find someone in your network running a business, any business. Ask them what frustrates them most. Listen properly. Not to pitch, just to understand.

Then offer to fix it. Charge for the outcome, not the time. Deliver something that works. Document what happened. Use that as your first case study.

That first client who pays you directly for solving a specific problem changes something in your brain that no salary ever does. It proves to you that your technical capability can generate revenue that you own. Not revenue you help someone else generate, but revenue that flows directly to you because of the value you created.

From there, you iterate. You find the next client. You refine the offer. You start to see patterns in the problems. You build systems. Eventually, you see whether there is a repeatable product underneath the service.

That is the path. Not a unicorn SaaS from day one. Not a complex business plan. Just: find a problem, solve it, get paid for the outcome, repeat.

The moment that changes everything

NITDA’s Director General also said something else at GITEX that I cannot stop thinking about.

He pointed to history. Previous industrial revolutions, he said, left Africa behind because we contributed raw materials and labour without capturing the value-added. We supplied the inputs, and someone else built the wealth.

“This time,” he said, “it is about value creation and building our own digital offerings.”

He was talking about national policy. But it applies equally to every individual Nigerian developer reading this.

You are a raw material if you are selling your hours. You are a value creator if you are selling outcomes you own.

The global demand for Nigerian developers proves that we have the raw material in abundance. The question is whether we will continue to export it to other people’s wealth-building projects, or whether we will start directing some of that capability toward our own.

You don’t have to quit your job tomorrow. You don’t have to choose between a salary and entrepreneurship in an instant.

But you do need to start the parallel path. One client on the side. One problem solved for your own revenue. One proof point that you can generate income that nobody else controls.

Because the companies paying to hire Nigerian developers are not doing it out of charity. They are doing it because the return on your skills is enormous.

The question is when you start capturing that return for yourself.

If you want to keep reading about building, shipping, and owning your revenue as a developer in Africa, subscribe to this Substack. I write about the real experience of building products here, what works, what doesn’t, and what I’m still figuring out.

Harvard Business Review just published something that every African developer needs to read.

They surveyed over 1,000 global executives and found that only 2% of layoffs happening right now are because AI has actually replaced someone’s job.

2%.

The other 39%? Companies are eliminating engineering roles because they believe AI will replace developers within the next 6 to 12 months.

And here’s the part that should make you stop scrolling.

Nine out of ten of those companies do not even have a vetted AI product ready to fill the roles they are cutting.

This means most of the developers being laid off right now are not being replaced by AI. They are being replaced by a PowerPoint slide that someone showed to a board. A projection. A fear. A guess.

And their careers are ending because of it.

This is not just an American problem

I know what you’re thinking. This is about Silicon Valley. This is about tech companies in San Francisco and New York. This does not apply to me in Lagos, Accra, or Nairobi.

Let me push back on that.

The same fear-driven layoff logic travels. The same executives who saw the PowerPoint in San Francisco are sharing the deck with their counterparts in Lagos. Nigerian banks are already talking about AI replacing operations roles. Telecoms are piloting AI for customer service. The consulting firms are selling “AI transformation” packages to every large enterprise on the continent.

The wave is not coming. It is already here.

And African developers, some of the most technically capable people I know, are sitting in the same vulnerable position as their counterparts everywhere else. Talented. Skilled. And entirely dependent on someone else’s decision about their value.

The instrument problem

There is a concept in aviation called Controlled Flight Into Terrain. CFIT.

It describes what happens when a perfectly functional aeroplane with fully trained pilots flies straight into the ground. Not because the engine failed. Not because of a storm. But because the instruments in the cockpit were feeding bad information. The altitude said fine. The speed was good. Everything looked normal. And then they hit the mountain.

I think about this every time I talk to a Nigerian developer who is doing everything right, studying, upskilling, getting certifications, learning the next framework and still feeling like something is off.

The instruments they are using to navigate their career are giving bad readings.

Those instruments are: get a promotion, negotiate a raise, become indispensable to your employer, and learn the hot new technology.

Every single one of those strategies assumes someone else is keeping the aircraft in the air.

Your employer. Your manager. Your company’s headcount budget.

But 66% of CEOs are planning cuts or hiring freezes right now. Tech unemployment has hit 4.6%, the highest in four years. Goldman Sachs is projecting 20,000 AI-driven job losses per month this year.

The instruments are lying to you. And you won’t feel it until you hit the mountain.

The real gap nobody is talking about

Here is where I want to get specific, because this is the part that I have lived personally.

When I started building my own products, GinuxAI, BuySmart, the things I write about here, I had the same problem that most African developers have when they try to operate independently.

I thought the market would pay me for my technical ability.

I was wrong.

Not because technical ability doesn’t matter. It does. It is the foundation of everything. But the market does not pay directly for technical ability. It pays for your ability to connect that technical skill to a business outcome that a non-technical person can see, feel, and write a cheque for.

That gap, between technical fluency and business communication, is the thing that is actually costing developers everything right now.

Here is what that gap looks like in practice.

You walk into a meeting with a business owner. You explain your solution using the language you learned on the job: APIs, pipelines, models, embeddings, latency, and infrastructure. You are accurate. You are thorough. You know exactly what you are talking about.

And the business owner across the table stares at you like you are reading from a manual in a language they do not speak.

Because you are.

Now, imagine instead you say: “I will make sure you never lose a customer to a slow response again.”

Same technology. Completely different conversation. And the second version closes deals.

The engineer who can do both, understand the problem at the business level and build the solution at the technical level, does not need to compete with anyone. There is no competition for that combination. Business people cannot build it. Most developers cannot sell it. The overlap is tiny and extraordinarily valuable.

Why this hits differently in Africa

I want to say something about the specific context of African developers, because I think we face a version of this gap that is more acute than what people in other markets experience.

In Nigeria, especially, there is a culture around technical skill that I deeply respect. Developers here work hard. They build genuinely impressive things under constraints that would stop most people: erratic power, expensive data, and limited access to tools and mentorship. The technical capability is real.

But the business communication piece is often missing. Not because African developers are less capable of learning it. But because the environment we trained in, whether that is a computer science programme at a Nigerian university, a bootcamp, or self-taught, grinding through Stack Overflow, rarely teaches it.

We learn how to build. We rarely learn how to explain what we built in terms of business outcomes. We learn how to solve technical problems. We rarely learn how to identify which business problems are worth solving and how to frame our ability to solve them in language that makes someone pull out their wallet.

And so we end up with the exact situation the Harvard Business Review is describing: commercially invisible and technically excellent developers, sitting in roles that someone else controls, waiting for a decision that could come any quarter.

The shift that changes everything

I am not going to tell you to quit your job tomorrow. That is not the point.

The point is to understand what you are actually missing and start developing it before you need it.

The missing piece is not another certificate. It is not a new programming language. It is not an AI tool.

It is the ability to walk into a room, listen to what a business owner actually needs, translate that need into something you can build, and explain your solution in terms they can feel.

That is a learnable skill. And unlike the years it took to build your technical depth, you can develop meaningful business communication ability in months, if you are deliberate about it.

Here is what that looks like practically for an African developer right now.

Start talking to businesses near you. Not pitching. Just listening. Ask them what frustrates them. What they do manually that should be automated. Where they lose money, time, or customers because of broken processes. You will hear the same things over and over, and those repetitions are your product roadmap.

Stop describing what you build in technical terms. Start describing outcomes. Not “I build machine learning models” but “I help businesses stop losing customers to slow responses.” Not “I build Chrome extensions” but “I help online shoppers never overpay again.” Practice this until it sounds natural.

Build one small thing that solves a real problem for a real business. Not a SaaS platform with seventeen features. One thing. One problem. One person who pays you for it. That first paying customer is worth more than any certification because it proves to you and to the market that you can connect technical skill to business value.

The developers who will win are not the most skilled

They are the ones who learned to communicate their skill in the language of business.

I have been building in public shipping products, writing about the process, and sharing what I learn because I believe that every African developer who masters this combination becomes genuinely untouchable. Not because AI cannot touch them. But because the thing they offer — deep technical understanding translated into real business outcomes in a specific market context that only they know — is not something AI replicates.

Your employer’s PowerPoint slide has no power over you if you have your own revenue.

The global tech consulting market crossed $400 billion in 2026 and is growing at 7% annually. Businesses everywhere need people who can actually implement AI in their operations — not talk about it, not promise it, actually implement it and explain why it works.

That person is you. You just have to learn to show up that way.

If you found this useful, subscribe to this Substack. I write about building SaaS, shipping products in Africa, and the things I’m learning as a developer trying to own my own revenue. Every new post goes directly to your inbox.

Something important is happening in Nigeria right now.

And most developers building AI products here have no idea it’s coming.

While everyone’s been focused on funding rounds, Product Hunt launches, and the latest AI tools, the Nigerian government has been quietly assembling the most significant piece of tech legislation this country has ever seen.

It’s called the National Digital Economy and E-Governance Bill.

And if you are building anything with AI in Nigeria — any SaaS product, any AI-powered tool, any app that collects or processes user data — this bill is going to directly affect how you build, what you ship, and what happens if you don’t comply.

I want to break it down in plain builder language. Not legal jargon. Not policy speak. Just what it means for you — someone sitting in Lagos, Abuja, Port Harcourt, or Ibadan with a product in production or a laptop with a half-built idea.

First — why is this happening now?

Nigeria has been trying to regulate AI since 2021.

The Artificial Intelligence and Robotics Research Regulatory Agency Bill was introduced that year, and went nowhere. More bills came in 2023 and 2024. They also went nowhere.

But 2025 changed the calculation. The government published a National AI Strategy. The Nigeria Data Protection Commission started actively enforcing data rules — issuing compliance notices to over 1,300 organisations in a single enforcement drive. The conversation shifted from “should we regulate?” to “how do we regulate and how fast?”

Now in 2026, lawmakers are expected to pass the National Digital Economy and E-Governance Bill — possibly as early as the second quarter of this year.

This one is different from the previous attempts. It’s not just a proposal sitting in committee. It’s a foundational statute. And it has teeth.

What the bill actually does — in plain English

Let me walk through the parts that matter most for builders.

NITDA becomes the super-regulator.

The National Information Technology Development Agency will be given formal authority over all AI systems deployed in Nigeria, in both public and private sectors. Think of NITDA as Nigeria’s equivalent of what the EU’s regulators are for the AI Act. They will have the power to audit your product, classify its risk level, demand corrective action, and shut you down if you don’t comply.

If you’re building AI in Nigeria, NITDA is now your regulator. Full stop.

AI systems will be classified by risk.

The bill introduces a risk-based framework — borrowed heavily from the EU AI Act approach. Not every AI product gets the same level of scrutiny. The higher the potential impact on real people, the heavier the compliance requirements.

High-risk categories include AI used in finance, public administration, automated decision-making, and surveillance. If your SaaS product touches any of these — credit scoring, loan approvals, hiring decisions, health assessments — you’ll be in the high-risk bucket and subject to mandatory annual audits.

For most early-stage builders working on productivity tools, research assistants, or consumer apps, the requirements will be lighter. But you still need to know which category you’re in.

You may need a licence to deploy.

This is the one that will surprise most developers.

Under the bill, developers will be required to obtain formal licences or registrations before deploying AI systems in the Nigerian market. This isn’t just for big companies. If you’re shipping a product that uses AI to make decisions affecting Nigerian users, you may need regulatory approval before you go live.

The details of what exactly triggers the licensing requirement are still being defined — NITDA will develop specific regulations after the bill passes. But the principle is clear: the era of “build fast, ship faster, ask questions never” for AI products in Nigeria is ending.

Fines are real — and calculated on revenue.

Non-compliance won’t just be a letter from a government agency. Sanctions under the bill include fines of up to ₦10 million — about $7,000 — or up to 2% of your annual gross revenue in Nigeria, whichever is higher.

For a startup doing ₦50 million in annual revenue, 2% is ₦1 million. For a company doing ₦500 million, it’s ₦10 million. The penalty scales with your business, which means ignoring compliance gets more expensive the more successful you become.

There’s also a regulatory sandbox — and this is actually good news.

The bill formally establishes a regulatory sandbox for AI and digital innovation. This is a mechanism that lets companies test new AI products within a controlled regulatory environment — with oversight and predefined safeguards — before going fully live.

For Nigerian builders, this is an opportunity. If you’re working on something innovative that doesn’t fit neatly into existing categories, the sandbox gives you a way to ship, learn, and comply simultaneously. It’s how the government is trying to say “we want innovation” while still building guardrails.

There’s a second bill. And it’s even more aggressive.

While the Digital Economy Bill gets most of the attention, there’s a second piece of legislation called the Digital Sovereignty and Fair Data Compensation Bill that builders should know about.

This one targets primarily foreign digital companies — but its implications ripple out to Nigerian builders too.

The headline: all data belonging to Nigerian users collected by any digital company must be stored and processed within Nigeria. Foreign companies will need to establish local data centres or mirror servers here. Any cross-border data transfer will require approval from NITDA.

And here’s the number that got global attention: foreign companies that use Nigerian data to train AI models will be required to contribute 2% of their annual Nigeria revenue to a Nigeria AI Development Fund. For the big players — Google, Meta, OpenAI — that’s significant money. For Nigerian builders who rely on foreign AI APIs to power their products, it raises questions about how those costs get passed down the chain.

Financial sanctions under this bill go much higher than the Digital Economy Bill — up to 10% of annual Nigerian turnover or ₦1 billion, approximately $733,000.

This bill is still more aggressive and more contested than the Digital Economy Bill. It may be amended significantly before it passes. But its direction signals something unmistakable: Nigeria is moving toward data sovereignty, and builders who are planning for the long term need to factor that into their architecture decisions now.

What this means for you specifically

Let me get practical. If you’re a Nigerian SaaS builder, here are the four things to do right now — not when the bill passes, but now.

One: Audit what your product actually does with data.

Go through your app and write down, in plain language, every type of data you collect from Nigerian users, where it’s stored, how it’s processed, and who else touches it (APIs, third-party services, hosting providers). Most founders have never done this formally. It’s time to do it now. This audit is the foundation of any compliance work you’ll need to do later.

Two: Identify your risk category.

Read through the high-risk categories. Does your product make automated decisions that affect users’ access to services, money, or opportunities? If yes, you’re probably in the high-risk bucket. If your product is a productivity tool, research assistant, or consumer utility that doesn’t make high-stakes decisions, you’re likely in a lower-risk category. Knowing where you sit tells you how urgent your compliance work needs to be.

Three: Watch NITDA’s guidance closely.

The bill’s passage is one thing. What matters next is the specific regulations NITDA publishes to implement it. These will define exactly what licensing looks like, how risk categories are formally classified, and what the sandbox application process involves. Sign up for updates from NITDA directly. This is not a set-and-forget thing — it’s an ongoing conversation between regulators and builders that will evolve for years.

Four: Design for compliance from the start.

If you’re building something new today, build it with compliance in mind. This doesn’t mean slow down. It means think about data minimisation — collect only what you need. Build in human oversight mechanisms so automated decisions can be reviewed and overridden. Document your AI governance decisions. These things are easier to build in at the start than to retrofit into a product that’s already in production.

My honest take

Here’s what I believe about this regulation — and I’ll be direct.

The instinct of most founders when they hear “government is going to regulate AI” is dread. More red tape. More bureaucracy. More reasons to move slowly.

I don’t think that’s the right read.

Nigeria has 220 million people. It has one of the fastest-growing digital economies in the world. It’s projected to hit $18.3 billion in digital economy revenue this year. That market is real, and it’s expanding.

A clear regulatory framework — even an imperfect one — makes that market more legible to investors, more trusted by consumers, and more stable for founders. The companies that will win in Nigeria’s AI economy over the next decade are not the ones that built fast and ignored the rules. They’re the ones who built carefully, earned user trust, and didn’t blow up when enforcement came.

NITDA’s Director General said something worth sitting with: “Regulation is not just about giving commands. It’s about influencing market, economic, and societal behaviour so people can build AI for good.”

That’s the right framing. Not a regulation as an obstacle. Regulation as infrastructure for trust.

Nigerian builders have always built under constraints — power cuts, currency volatility, infrastructure gaps, and limited capital. We’ve made extraordinary things anyway. Compliance is just another constraint to build around. And we know how to do that.

The window before enforcement is your advantage

Here’s the practical truth about regulation timelines.

The bill passes. Then NITDA develops specific regulations. Then there’s an implementation period. Then enforcement begins.

Between now and active enforcement, there’s a window — probably 12 to 24 months — where founders who engage early, build compliance frameworks, and potentially participate in the regulatory sandbox will have a significant advantage over those who wait.

The EU AI Act had a similar dynamic. The founders and companies that engaged with the regulation during its development period shaped its final form and were ready to operate when it took effect. The ones who ignored it scrambled.

Nigeria’s regulation is coming whether we engage with it or not. The question is whether you’ll be the builder who was ready — or the one who wasn’t.

I’m watching this closely because it directly affects GinuxAI — an AI research assistant I built for students and researchers in Nigeria and across Africa. As the regulatory environment clarifies, I’ll keep writing about what it means for founders building here.

If you’re building AI products in Nigeria and want to stay ahead of this, subscribe to this Substack. This is exactly the kind of thing I’ll keep tracking and translating into plain builder language as it develops.

Further reading:

• IAPP: Nigeria moves toward comprehensive AI regulation (April 8, 2026)

• Nigeria’s National AI Strategy — NITDA/NCAIR

• National Digital Economy and E-Governance Bill (public hearing, November 2025)

A few days ago, I came across a video that stopped me mid-scroll.

The guy speaking, Bugo, a software engineer turned entrepreneur based in LA, said something I haven’t been able to shake since.

He said: only 0.04% of the world’s population is actually building with AI right now.

Not using it. Not paying for it. Building with it.

Out of 8.1 billion people on this planet, roughly 2 to 5 million are the ones actually creating things with AI. Writing code. Shipping products. Building tools. Connecting systems.

Everyone else, 99.96% of the world, is either a passive user, an occasional chatbot consumer, or completely untouched by AI entirely.

I sat with that number for a while.

And then I thought about us, African developers. Nigerian engineers. Ghanaian builders. Kenyan developers shipping code at 2 am on a bad internet connection.

We are in that 0.04%.

And most of us have no idea what that actually means.

Let me tell you where I was six months ago

I was building.

Not shipping. Not selling. Not talking to users. Just building.

Feature after feature. Flow after flow. Tweaking the UI, improving the AI responses, and refining the onboarding. Telling myself every week that it wasn’t ready yet.

I was doing what most African developers I know do — hiding behind the craft. Using “it needs more work” as a shield against the vulnerability of putting something real in front of real people.

I thought my job was to build the best possible product.

I was wrong.

My job, our job, has changed completely. And most of us haven’t caught up to that reality yet.

The bottleneck has moved

Here’s what Bugo said in the video that I keep coming back to.

A few years ago, the bottleneck in software was fulfilment. Building things was hard. It took teams. It took time. It took serious engineering skill to ship something that worked reliably.

That bottleneck is gone.

With tools like Claude, Cursor, and other AI coding assistants, one developer can now build in days what used to take a team of ten weeks. The engineering barrier to shipping software has collapsed.

But here’s what hasn’t collapsed: getting clients. Getting users. Making people aware that your product exists and convincing them that it solves their problem.

Distribution is now the hardest part.

Not coding. Not architecture. Not infrastructure. Getting the product in front of the right people and making them care, that’s where the real work is now.

And this is where most African developers, myself included, have been asleep.

We optimise for the thing that got easier. We ignore the thing that got harder.

We keep building. We forget to sell.

What 0.04% actually means in Africa

Let me bring this home.

Nigeria has over 200 million people. Ghana has 33 million. Kenya has 55 million. Ethiopia has 120 million.

Across the continent, we have close to 1.4 billion people.

If we apply Bugo’s numbers, 0.04% building with AI, that’s roughly 560,000 people across the entire continent who are in the builder class right now.

560,000 builders. In a market of 1.4 billion people.

The businesses in your city, the logistics company two streets away, the healthcare clinic your parents use, the agricultural cooperative your uncle runs, the school your younger sister attends, almost none of them have AI integrated into how they operate.

Not because they don’t need it.

Because nobody has shown them what it can do. Nobody has built the bridge between what AI is capable of and the specific problems they face every day.

That bridge-builder could be you.

That is not a small opportunity. That is a generational one.

The three things you actually have

Bugo talks about something he calls your “unique advantage”, the overlap between your experience, your network, and your location.

I want to translate that to where we are.

Your experience. You’ve been building in a context most Silicon Valley developers have never touched. You’ve built products for users with intermittent internet. You’ve thought about data costs. You’ve built for devices that are two or three generations behind. You understand payment fragmentation, currency volatility, and what it means to design for a user who has never had a bank account.

That context is not a handicap. It is a competitive advantage the moment you start solving African problems for African markets.

Your network. Think about the people you actually know. Not LinkedIn connections. Real people, family, friends, former colleagues, people from your church or mosque, people from your university. Now ask yourself: how many of them run a business or work inside one? How many of them have no AI in their operations whatsoever?

Almost all of them. Every single one is a potential conversation. Every conversation is a potential client.

Your location. This one matters more than people realise. If you are in Lagos, Accra, Nairobi, or Kampala right now, you have physical access to business owners that no remote agency in London or New York can replicate. You can walk into a meeting. You can be introduced by someone they already trust. You can show up.

That in-person trust is something money cannot buy from a distance.

The mistake I made — and what I changed

I spent months building GinuxAI in private.

GinuxAI is an AI research assistant for students and researchers. It helps them generate topics, find materials, structure their work, and get unstuck when they don’t know where to begin.

The product itself was solving a real problem. Students in Nigerian universities, Ghanaian polytechnics, and Kenyan research institutions experience the blank page paralysis, which is universal and acute in academic settings where resources are scarce and guidance is inconsistent.

But I was so focused on making the product perfect that I forgot the people it was built for had no idea it existed.

I launched on Product Hunt recently. And the act of launching — of putting it publicly in front of people and asking for their response — taught me more in 48 hours than six months of building in private.

I heard things I needed to hear. What was confusing? What wasn’t clear? What people wished it did differently.

None of that feedback was available to me while I was building in silence.

The launch was uncomfortable. It was exposed. And it was the most valuable thing I did since I started the project.

Service before SaaS — the hardest thing to accept

This is the part I wrestled with the longest.

Bugo is direct about it: for 99% of developers starting in business, a service beats a SaaS every time.

SaaS takes months to build before you validate. A service gets you revenue this week by talking to people. SaaS requires you to guess what users want. A service lets users tell you what they need before you build a thing. SaaS needs a distribution infrastructure you probably don’t have yet. A service spreads through the relationships you already have.

This doesn’t mean don’t build products. GinuxAI is a product. BuySmart, my open-source Chrome extension, is a product.

But before I built either of them, I should have talked to more people. I should have validated the pain more aggressively. I should have offered to help manually first — and only automated it once I understood exactly what the help needed to look like.

Most of us skip that step. We’re engineers. We want to build.

But the business doesn’t start when you write the first line of code. It starts when someone pays you to solve their problem. And the fastest path to that is a conversation, not a codebase.

What I want you to do this week

Not this month. This week.

Write down ten people in your network who run or work in a business. It doesn’t have to be tech. In fact, it’s better if it isn’t.

Call five of them. Not a message. A call.

Ask them one question: “What’s the most frustrating, time-consuming thing in your work right now?”

Don’t pitch anything. Don’t mention AI. Just listen.

You will hear something you can solve. I promise you that. Because 99% of the businesses around you have not yet been touched by what you already know how to do.

That gap is your opportunity.

And it is closing faster than most people think.

The developers who move now — who start having conversations now, who start bridging the gap now — will be the ones who look back in five years and say they were early.

The ones who wait for the product to be perfect will look back and say they missed it.

One more thing

If you’re a student or researcher reading this — someone who has felt that blank page paralysis, who has stared at a research topic and not known where to begin — I built something for you.

GinuxAI is an AI research assistant that helps you generate focused topics, find relevant materials, structure your chapters, and answer complex questions so you can stop being stuck and start actually writing.

It’s live. It’s real. And I’d love for you to try it.

👉 producthunt.com/products/ginuxai

If you try it and have thoughts — good, bad, or confused — reply to this post or find me on LinkedIn. I read everything.

We are in the 0.04%. The question is what we’re going to do with it.

Today is the day.

GinuxAI is live on Product Hunt.

And I want to write this post while it’s still happening — while the nerves are still fresh, while the notifications are still coming in, while I still remember exactly what it felt like to click publish on something I’ve been building in private for months.

Because there’s a version of this post I could write in two weeks — the cleaned-up, lessons-learned, “here’s what I’d do differently” retrospective. And I’ll probably write that too.

But this one is different. This one is the raw version.

What GinuxAI actually does

Before I get into the launch story, let me tell you what I built — because I want you to understand the problem first, not the product.

If you’ve ever had to write a research paper, a thesis, or a serious academic project, you know the feeling.

You open a blank document. You stare at it. You know you need to write something about a topic you’ve been assigned — or worse, a topic you’re supposed to choose yourself. And you don’t know where to start.

Not because you’re incapable. Not because you’re lazy. But because research has a specific kind of paralysis built into it. There are too many possible directions. Too many sources. Too many ways to structure the work. And nobody has given you a map.

This is the problem I kept seeing. Not just in myself — in students, in early researchers, in professionals trying to write reports they’ve never written before.

They don’t struggle because they can’t research.

They struggle because they don’t know where to begin.

GinuxAI is built to solve exactly that:

• You tell it your subject area, and it generates focused research topics worth pursuing

• It finds relevant materials — papers, sources, references — so you’re not starting from a blank search bar

• It structures your work into chapters and sections, giving you a framework before you write a single word

• It answers complex research questions in context, not just generic summaries

It’s not trying to write your research for you. It’s trying to get you unstuck so you can write it yourself.

That distinction matters.

Why I stayed in “build mode” too long

Here’s something I don’t think founders talk about enough.

Building feels productive. Shipping feels exposed.

For months, I was adding features, improving the AI responses, tweaking the UI, refining the onboarding flow. Every week, I had a reason why it wasn’t ready yet.

The topic generation could be sharper. The source suggestions could be more relevant. The chapter structuring needed another pass.

And some of that was legitimate. Some of it was fear wearing the costume of diligence.

The truth is: I wasn’t ready to show people something they might not like.

Product Hunt forced my hand. It gave me an external deadline that I couldn’t negotiate with myself out of. Launch day was launch day.

And here’s what I discovered when I actually shipped:

A product nobody sees is the same as a product that doesn’t exist.

I’d heard that sentence a hundred times before. It didn’t land until it was about my own product. Until I realised that all those weeks of “improving” were improvements nobody had experienced yet. That every hour I spent refining was an hour a real user didn’t spend finding GinuxAI.

The product I launched today is not perfect.

It’s real. And real beats perfect.

The reality of a Product Hunt launch — what nobody tells you

Everyone who talks about Product Hunt makes it sound like two things: either a magic rocket ship that sends you to 10,000 users overnight, or a complete waste of time that nobody cares about.

The reality is more human than either of those.

Here’s what the first hours of launch day actually look like.

You post. You share it everywhere you can — WhatsApp groups, Twitter, LinkedIn, Telegram channels, email lists. You personally reach out to people you know and ask them to show up and support.

Then you wait.

And the waiting is uncomfortable in a way that’s hard to describe. It’s not anxious exactly. It’s exposed. You’ve made something, you’ve shown it to the world, and now the world gets to decide what it thinks.

The first few hours are everything. The Product Hunt algorithm is sensitive to early activity — upvotes, comments, and the velocity of engagement. If you don’t show up strong in the morning, it’s very hard to recover by afternoon.

So you stay active. You respond to every comment. You answer every question. You thank every person who takes a minute to engage.

And somewhere in that process, something shifts.

It stops being a launch and starts being a conversation.

The four things I actually learned

I had a version of these lessons in my notes, written as bullet points. Let me give you the full version instead.

One: Clarity beats complexity - always.

The hardest thing about launching GinuxAI wasn’t building it. It was explaining it.

When you’ve spent months building something, you understand every nuance of how it works. You know the technical decisions, the tradeoffs, the edge cases. And when someone asks you, “What does this do?” you want to explain all of it.

But people don’t want all of it. They want one sentence.

“What does this do for me, right now, in plain language?”

The simpler your answer, the better the response. Not because your audience is unsophisticated — but because clear language signals a clear product. When you can explain your SaaS in one sentence, you’ve understood your own value proposition. When you can’t, you haven’t.

I rewrote my Product Hunt tagline seven times. The final version was the shortest. It also performed the best.

Two: Distribution is the other half of the job.

I’ve written about this before in the context of other products. But it hits differently when it’s yours.

You can build something genuinely useful and have nobody see it. Not because it’s bad. Just because the world is noisy, and nobody knows how to look.

Product Hunt is one distribution channel. Your personal network is another. Your Substack is another. Twitter threads, LinkedIn posts, developer forums, WhatsApp groups — all of it is distribution.

And here’s the uncomfortable truth: the founder who builds a mediocre product and markets it well will outperform the founder who builds a great product and doesn’t tell anyone.

That’s not fair. But it’s true.

Ship, then market. Not ship, then wait.

Three: Feedback is more valuable than praise.

The upvotes feel good. I won’t pretend they don’t.

But the comments that changed how I think about GinuxAI weren’t the “amazing product!” ones. They were the ones who said:

“I tried this and couldn’t figure out how to get from step one to step two.”

“The topic suggestions were good, but the sources felt generic.”

“I’d use this if it supported my specific research format.”

Every one of those comments is a product roadmap item. Every piece of genuine friction a user reports is a gap between what I built and what they actually need.

Praise tells you people like you. Feedback tells you how to get better.

Optimise for feedback, not applause.

Four: Momentum is a choice you make every day.

Here’s the thing about launching that I didn’t fully understand until I did it.

The launch is not the event. The launch is the start of a habit.

Products that die after launch day don’t die because of the launch. They die because the founder stops showing up. The posts stop coming. The updates stop shipping. The conversations stop starting.

The founders who build real traction share consistently — not just on launch day. They post updates when something breaks. They share what they’re learning. They write articles like this one. They show up in communities where their users already are.

Momentum is not something that happens to you. It’s something you build, every single day, one post and one conversation at a time.

What’s next for GinuxAI

This launch is the beginning, not the destination.

The roadmap I’m working toward includes sharper research accuracy — the AI suggestions need to get more precise for individual fields of study. The user experience needs to get smoother, especially for first-time users who arrive with no context. I want to add more structured output formats for different types of research. And I want to eventually support more African academic contexts specifically — the research frameworks, citation styles, and institutional requirements that students here actually work with.

None of that happens overnight. But it all starts today.

To every African builder reading this

I want to end with something direct.

GinuxAI is built for students and researchers. But the reason I’m writing this post — the reason I’m sharing the uncomfortable parts, not just the highlights — is because I know builders are reading this who are still in “build mode.”

Still perfecting. Still refining. Still waiting until it’s ready.

It will never be ready the way you think it needs to be.

What you have right now — if it solves a real problem for a real person — is enough to ship. And shipping is the only way to know whether you’ve built the right thing.

The most valuable thing I did today wasn’t building a better feature.

It was telling the truth about what I made and asking people to try it.

Do that. Do it scared. Do it before you think you’re ready.

You will learn more from one week of real users than from six months of building in private.

Support the launch → producthunt.com/products/ginuxai

If you launched something publicly and you want to share your experience — or if you’re sitting on a product you haven’t shipped yet — reply to this post. I read every response.

Over the past few years, I kept running into the same problem.

I’m on Jumia, looking at a product.
The price looks reasonable - but is it actually a good deal?

So I open multiple tabs.
Compare prices manually.
Read reviews across different platforms.

Twenty minutes later, I’m still unsure.

This isn’t just a personal inconvenience.

It’s a structural problem in how e-commerce works across African markets.

And I decided to build something to solve it.

From Problem to Product

I built BuySmart - an open-source, AI-powered Chrome extension designed to help users make better purchasing decisions across platforms like Amazon, eBay, AliExpress, Walmart, and Jumia.

Instead of manually comparing prices and reviews, BuySmart:

• Detects products automatically on supported sites

• Compares prices across the web

• Uses AI to analyse whether a deal is fair

• Recommends whether to buy now or wait

All within seconds.

No tab switching. No guesswork.

Why This Matters (Especially in Africa)

E-commerce in Africa has unique challenges:

• Prices vary significantly across platforms

• There is little to no price history transparency

• Most global tools don’t support African platforms like Jumia

This creates friction for everyday users when making purchasing decisions.

BuySmart is my attempt to reduce that friction - starting with price intelligence.

But more importantly:

It’s an example of building locally relevant solutions with global-grade engineering.

The Technical Approach

I designed BuySmart as a modular, developer-friendly system:

• Frontend: Chrome Extension (React + TypeScript)

• Backend: FastAPI (Python)

• Search Layer: Self-hosted SearXNG

• AI Layer: OpenRouter (LLM abstraction)

• Data Extraction: Multi-layer scraping (Tavily, Deepcrawl, HTTP fallback)

The system is fully containerised and runs with:

docker compose up -d

No vendor lock-in. No mandatory paid services.

This was intentional.

Building for Accessibility, Not Just Innovation

Many developer tools assume:

• access to paid APIs

• strong currencies

• scalable cloud infrastructure

That’s not always realistic in African markets.

So I designed BuySmart to be:

• self-hostable

• low-cost

• accessible without a credit card

• flexible across environments

Because innovation shouldn’t be gated by geography.

Open Source as a Strategy - Not Just a Choice

I made BuySmart open source for a reason.

Not just for visibility - but for ecosystem contribution.

There are entire segments of African e-commerce that are still underserved by developer tooling.

And I don’t believe one person should solve that alone.

Where the Community Comes In

BuySmart is already functional.

But its real potential lies in community contribution.

Here are areas where developers can immediately make an impact:

• Adding support for more African e-commerce platforms

• Implementing price history tracking

• Improving currency intelligence

• Expanding browser compatibility

• Enhancing UI/UX (yes, including dark mode)

This is not just about contributing code.

It’s about collectively building infrastructure for smarter commerce in Africa.

What This Represents

For me, BuySmart is more than a Chrome extension.

It represents:

• building solutions rooted in local realities

• applying AI to practical, everyday problems

• contributing to open source in a meaningful way

• enabling other developers to build on top of the work

The Bigger Picture

African developers are already building world-class systems.

But there’s still a gap when it comes to:

tools built specifically for African users.

That’s where the opportunity is.

Not just to participate globally
but to lead locally.

Get Involved

If you’re a developer interested in contributing:

• ⭐ Star the repo

• 🍴 Fork it

• 🛠 Pick an issue

• 🚀 Ship something

👉 GitHub: https://github.com/kingztech2019/buysmart-extension

Final Thought

The best software doesn’t just demonstrate skill.

It solves real problems and enables others to build on top of it.

BuySmart is my contribution.

If you’re building something too, keep going.

We need more of this.

Recently, Flutterwave secured a banking licence in Nigeria.

On the surface, it looks like another fintech milestone.

Headlines focused on deposits, lending, and their implications for growth. Founders congratulated the team. The ecosystem celebrated.

But there’s a deeper question most people are not asking:

How did a payments API evolve into a bank?

And more importantly:

What does that journey teach you about how to build your SaaS product today?

Start Small. Solve One Problem Deeply.

Flutterwave didn’t start as a bank.

They started with one thing:

Accepting payments across Africa.

Not a dashboard-heavy platform.
Not a full financial suite.
Not a “super app.”

Just infrastructure.

An API that worked.

And that was enough.

Businesses adopted it not because it had the most features, but because it reliably solved a real, painful problem.

That’s the first lesson:

Start narrow. Go deep. Own one problem before expanding.

Most SaaS founders do the opposite.
They try to build everything at once: dashboards, analytics, automation, before a single user truly depends on the product.

Flutterwave started with the pipe.

They Didn’t Just Build Software — They Built Infrastructure

There’s something subtle most people miss.

Flutterwave wasn’t just building software that people log into.

They were building infrastructure that other products depend on.

That’s a completely different game.

Software gets used.
Infrastructure gets embedded.

And once you’re embedded, you’re hard to replace.

Instead of chasing end users, Flutterwave focused on developers and businesses — the people building products.

And those builders brought users with them.

So the question for you becomes:

Are you building a tool… or something others can build on?

Because the closer you move toward infrastructure, the stronger your position becomes.

The Quiet Shift Toward Owning the Stack

For years, Flutterwave processed billions in payments.

But there was a catch.

They didn’t fully control the entire flow.

Banks still held deposits.
Third parties handled parts of the financial stack.

Which means value was being shared or leaked at every layer.

Now, with a banking licence, that dynamic changes.

They can move closer to:

• owning deposits

• controlling more of the transaction lifecycle

• capturing more value internally

And this leads to one of the most important lessons:

Great SaaS products evolve by reducing dependency on external layers.

Every time your product relies heavily on another system to complete its core value, you are giving up control.

Think in Systems, Not Features

Most SaaS products grow reactively:

• A user requests a feature

• You build it

• A competitor launches something

• You copy it

Over time, you end up with a bloated product.

But companies like Flutterwave expand differently.

They build toward a system.

Each step connects.

Each layer strengthens the whole.

Not random features but a deliberate stack.

So instead of asking:

“What feature should I build next?”

Ask:

“What layer of the system am I trying to own?”

Where SaaS Builders Get It Wrong

Many founders are obsessed with interfaces:

• dashboards

• UI

• user flows

But users don’t actually care about your interface.

They care about the outcome.

Flutterwave’s users don’t care about dashboards.

They care about:

Money moving reliably.

That’s it.

Everything else is secondary.

What This Means for You

If you’re building SaaS today, especially in emerging markets, here’s what you should take seriously:

1. Start With a Painful, Specific Problem

Not a platform. Not a vision. One problem that matters.

2. Build the Backend First

Your real value is not your UI, it’s your infrastructure.

3. Think in Stacks

Every feature should connect to a bigger system you’re building.

4. Reduce Value Leakage

Identify where your product depends on third parties, and gradually own more of that flow.

5. Own the Outcome

Don’t just help users do something.
Help them achieve something.

One More Thing

There’s a quiet pattern here.

Flutterwave didn’t try to look impressive.

They focused on becoming indispensable.

And there’s a difference.

Impressive products win attention.
Indispensable products win markets.

They didn’t rush to build everything.

They built the foundation…
Then expanded…
Then deepened control…
Then captured more value.

And one day, they became a bank.

Final Thought

The real lesson isn’t about fintech.

It’s about how great products evolve.

They don’t start big.

They start small…
solve deeply…
expand deliberately…
and eventually own the system.

So instead of asking:

“What SaaS should I build?”

Ask:

“What part of the system can I own, and expand from there?”

Because the builders who win…

Don’t just build features.

They build the pipes.

A few weeks ago, I wrote about how I wasted months building a SaaS nobody used.

That experience forced me to rethink something uncomfortable:

Maybe the problem wasn’t just my idea… maybe it was how I was building.

While reflecting on that, I came across a new shift happening quietly in the ecosystem, one that might completely change how we think about SaaS.

That shift is AI agents.

And tools like OpenClaw are at the centre of it.

The Problem with Traditional SaaS

Most SaaS products today follow the same pattern:

• Build a dashboard

• Add features

• Ask users to log in and figure things out

But here’s the truth:

Users don’t actually want dashboards, they want outcomes.

Think about it:

• Nobody wants a CRM

• They want more sales

• Nobody wants a project management tool

• They want the work to get done

Yet most SaaS still requires:

• manual input

• constant monitoring

• repetitive actions

We built software that helps people work…

But not software that does the work.

Enter AI Agents (And Why This Changes Everything)

AI is no longer just about answering questions.

We are moving into a new era where software can:

• take actions

• execute workflows

• interact with real tools

• make decisions

This is where OpenClaw becomes interesting.

Instead of just generating text, it can:

• run tasks

• automate processes

• connect with APIs

• act like a digital operator

In simple terms:

Traditional SaaS → tools you use
AI agents → systems that work for you

This is a fundamental shift.

How SaaS Builders Can Leverage This Shift

This is where it gets practical.

If you’re building SaaS today, you don’t need to abandon everything — you need to adapt your approach.

1. Build “Agent-First” Products

Instead of designing dashboards first…

Start with this question:

“What task can I fully automate for the user?”

For example:

Instead of:

• a CRM dashboard

Build:

• An AI agent that:

  • captures leads

  • follows up automatically

  • updates records

  • sends reports

The user doesn’t manage the system.

The system manages the work.

2. Turn Your SaaS Features into APIs (Not Just UI)

In the agent era:

Your backend becomes more important than your frontend.

Instead of focusing on:

• buttons

• dashboards

Focus on:

• clean APIs

• modular services

• automation endpoints

Why?

Because tools like OpenClaw can plug into your APIs and use them directly.

Your SaaS becomes:

infrastructure for intelligent agents

3. Build “Skills” Instead of Features

Think of your product as a collection of capabilities.

Instead of:

• “feature list”

Think:

• “what can this system do autonomously?”

Examples:

• send emails

• analyze data

• trigger workflows

• respond to users

Each of these becomes a reusable skill that an agent can execute.

4. Create AI Employees, Not Just Tools

This is where things get really interesting.

You can now build:

• customer support agents

• sales outreach agents

• operations assistants

• research assistants

Instead of selling:

“software access”

You’re offering:

“automated outcomes”

That’s a completely different value proposition.

5. Ship Faster MVPs

One of the biggest advantages:

You don’t need to build everything from scratch anymore.

Instead of:

• full UI

• complex workflows

You can:

• connect APIs

• define tasks

• let the agent handle execution

This means:

• faster validation

• quicker iterations

• less wasted effort (something I learned the hard way)

The Reality (And Risks You Shouldn’t Ignore)

This shift is exciting — but it’s not magic.

There are real challenges:

• Security risks — agents executing actions must be controlled

• Complexity — setting up reliable workflows is not trivial

• Debugging — harder than traditional systems

• Trust — users may hesitate to give control to AI

So while the opportunity is huge:

You still need solid engineering and thoughtful design.

What I Would Do Differently Now

Looking back at my failed SaaS…

If I were to rebuild it today, I wouldn’t start with:

• a dashboard

• a feature list

I would start with:

“What outcome can I fully automate for my users?”

Then I’d build:

• APIs first

• workflows second

• minimal UI last

And possibly plug an agent system like OpenClaw on top of it.

Final Thoughts

We are entering a new phase of software:

• From tools → to operators

• From dashboards → to automation

• From users doing work → to systems doing work

The question is no longer:

“What SaaS should I build?”

The better question is:

“What work can I eliminate for my users?”

Because in the near future, the best products won’t just help people work.

They will work for them.

If you’re a builder, now is the time to start thinking differently.

Because the shift is already happening.

Most developers are stuck.

Not because they can’t code.
But because they don’t know how to get clients.

I recently went through a session where dozens of developers shared their biggest struggle:

• “I don’t know what to sell”

• “I’ve tried cold emails, no replies”

• “I don’t have a network”

• “I built something… but nobody uses it”

And the truth is simple:

You’ve been given incomplete advice.

The Biggest Mistake Developers Make

Most developers follow this path:

Build → Launch → Hope → Silence

They spend weeks or months building something…

And then try to find clients.

That’s backwards.

The Correct Order (This Changes Everything)

The real order is:

Problem → Demand → Validation → Payment → Build

Yes, payment comes before building.

That might feel uncomfortable.

But think about it:

• When you hire a plumber → you pay first

• When you buy a car → you pay first

• When businesses buy software → they pay first

So why should your SaaS be different?

Why Most Client Acquisition Advice Fails

You’ve probably heard:

• “Go on Upwork”

• “Send cold emails”

• “Post content”

• “DM people on LinkedIn”

These aren’t wrong.

They’re incomplete.

Because they all ignore one thing:

Trust

Trust Is the Only Currency

People don’t buy your code.

They buy:

• Confidence

• Understanding

• Results

Everything in client acquisition comes down to:

• Familiarity

• Consistency

• Competence

• Relevance

No trust → no clients.

The Two Ways to Get Clients

There are only two:

1. Outbound (you go to them)

• Cold email

• LinkedIn outreach

• Networking

2. Inbound (they come to you)

• Content

• SEO

• Referrals

But here’s what most people get wrong:

You don’t start with inbound.

You start with outbound.

The Fastest Way to Your First Client

Not a cold email.
Not content.
Not ads.

Your network.

“But I Don’t Have a Network…”

You do.

Your network includes:

• Friends

• Family

• Ex-colleagues

• Schoolmates

• LinkedIn connections

• Even people in your phone contacts

The mistake is thinking:

“They don’t need my service.”

They don’t have to.

They need to know someone who does.

How to Reach Out (Without Being Salesy)

Don’t pitch.

Inform.

Instead of:

“Do you need a website?”

Say:

“I help [specific people] solve [specific problem].
Do you know anyone who might need this?”

That small shift changes everything.

Why This Works

Because people are wired to help.

And referrals are powerful.

One referral = 1,000 cold leads

• Higher trust

• Higher close rate

• Zero acquisition cost

The Real Problem With Developers

Developers treat client acquisition like coding.

Logical.
Optimized.
Automated.

But it’s not.

Client acquisition is emotional.

It’s about:

• Relationships

• Conversations

• Trust

Why Most People Quit Too Early

Here’s the reality:

• Week 1 → Excited

• Week 3 → No results

• Week 6 → Doubt

• Week 9 → First client

Most people quit at week 3.

The “Gun to Your Head” Test

Here’s a powerful question:

If you had 2 days to get a client… could you?

Most developers can’t.

And that’s the real problem.

What Actually Works (High-Level)

From the session, the most effective methods were:

🔥 Best (High Trust)

• Warm network

• Referrals

• Strategic relationships

• In-person networking (e.g. Chamber of Commerce)

⚠️ Mid (Requires Skill)

• LinkedIn outreach

• Cold email

❌ Worst (Low ROI)

• Upwork

• Fiverr

• Generic platforms

A Powerful Insight Most People Ignore

You don’t need more leads.
You need more trust.

What I’m Doing Differently Now

Instead of:

• Building blindly

• Sending random outreach

• Hoping for results

I focus on:

• Understanding real problems

• Validating before building

• Building relationships first

Final Thought

If you’re a developer trying to build a SaaS or get clients:

Stop asking:

“How do I build this?”

Start asking:

“Who actually needs this?”

That one question will save you months.

Subscribe if you want:

→ Real SaaS lessons
→ Client acquisition strategies that actually work
→ Practical backend + AI insights

No fluff. Just execution.