Executive Summary

Tolu Fagbola is usually described as a founder with two unrelated companies: LearnFlo, a learning platform, and Vimedra, a US healthcare navigation company. The more useful reading is that both are orchestration layers, products that sit between fragmented institutions and the person forced to coordinate them. Fagbola uses the word himself. “I call myself the orchestrator,” he told Techpoint Africa, adding: “I don’t write code; my team does that, but I build the systems.”

That framing explains his career better than the sector labels do, and it also sets the limit of what can be claimed. An orchestration layer becomes infrastructure only when institutions depend on it, and the public record on both companies is thin: one named feature interview, two company pages and one product podcast. This profile therefore treats the pattern as the finding and the traction figures as company-reported.

Introduction

The conventional framing of a serial founder is a list: a company in education, then a company in health. It tells a reader the sectors and nothing about the design problem. The sectors in this case are less informative than the position each product takes, which is the same in both: between a system that has the resources and a person who cannot reach them.

This profile treats Fagbola the way an operator would treat a case study. It asks what each product coordinates, who pays, what the evidence shows, and where the pattern stops. It is evergreen: the latest dated source is a Techpoint Africa feature published on 6 March 2026, and no news event is claimed.

Who Is Tolu Fagbola?

According to the Techpoint Africa feature, written by Delight Sunny for its Techpoint Diaspora series, Fagbola was born in London with Nigerian roots, attended primary and secondary school in Nigeria, and returned to the United Kingdom at 18 after a university strike interrupted his studies at the University of Ilorin. He holds a first degree in Communications and Visual Culture, a master’s in Communications Management, and a master’s in Organisational Psychology and Behaviour. He says he has lived in the UK for 30 years.

His career began in telecommunications around 2003, in training and development. That origin matters because it is where the orchestration instinct appears. Training is a coordination problem: the content exists, the learners exist, and the work lies in getting one to the other at the right time in the right format.

In 2008, Fagbola partnered with a US-based friend who was building a learning management system, combining it with his training background. The first deployment to Nigerian banks failed because of bandwidth limits. The team rebuilt the product with local developers introduced through his brother, and the second version worked. Fagbola says the company still stands.

The episode is small, but it carries the pattern. The product was sound; the environment around it was not, and the fix was a local rebuild around the constraint rather than a defence of the original design.

What Does an Orchestrator Do That a Platform Does Not?

A platform aggregates participants and lets them transact. An orchestration layer does something narrower and harder: it takes responsibility for a sequence that spans institutions, and it is judged on whether the person at the end of the sequence gets through it. A platform is measured on volume. An orchestration layer is measured on completion.

The distinction is not Fagbola’s own vocabulary beyond the single word “orchestrator,” and the publisher’s term for the economic end state is infrastructure. The two words describe different stages. Orchestration describes what a product does. Infrastructure describes what an economy cannot do without. Most orchestration layers never become infrastructure, and the question for an operator is what would have to be true for one to cross.

That test is applied in the sections below. It asks three things: whether the institutions on each side of the layer rely on it, whether switching away from it is costly, and whether someone other than the founder can state what it earns.

LearnFlo: Orchestrating Training Between Institutions and Learners

Fagbola built LearnFlo in 2017, while living in London, as a platform to help higher institutions and trainers move their teaching online. He told Techpoint Africa that it pivoted in 2022 to focus on higher institutions. The reported figures are more than 30,000 users and more than ₦5 billion in fees processed, and the company has grown, in the feature’s words, without external funding. Those figures come from the founder’s account to a publication, not from an audited source.

LearnFlo’s own website describes something somewhat different from the pivot. It presents LearnFlo as a platform for individuals selling online courses and for corporate training providers that need a learning management system. It lists video, audio and document hosting, live video conferencing, instant payment, student management, and pricing in naira and dollars. A free plan carries a 15% transaction fee and a ₦5,000-a-month plan carries 8%. The page names no founder, partner or customer.

The two accounts are not necessarily in conflict. A company can describe a higher-education focus in an interview and keep a self-service product page for course sellers. They do describe different customers, and the public record does not say how the two fit together. This article states both and does not reconcile them.

The model is instructive in one respect. Naira pricing, instant payment and a fee that scales with sales suggest a product aimed at Nigerian conditions, the lesson the 2008 deployment taught. For comparison, Tade Oyerinde’s Campus attacks education from the supply side by repricing faculty and decoupling teaching from geography. LearnFlo sits at a different point in the same chain: it does not change who teaches, it changes how an institution delivers what it already has.

The verdict is that LearnFlo is an orchestration layer with a stated customer shift and a public product that points somewhere narrower; its status as infrastructure cannot be shown from the available evidence.

Vimedra: Orchestrating Care Between Systems and Patients

Vimedra is the more consequential case because it operates where the coordination failure is expensive. Per Techpoint Africa, Fagbola co-founded it in 2024 with his brother, a US Army veteran and computer scientist. It is a US-based company that uses voice AI and predictive algorithms to prevent emergencies among underserved patients. The feature describes a patent-pending algorithm that layers social information onto medical data to build a risk profile.

The company’s site description says that Vimedra “connects patients to care with AI navigation agents Phoebe and Jacob.” Its podcast, Phoebe’s Pulse, released on 11 May 2025, describes Phoebe as an empathetic AI health navigator trained in the social determinants of health, and Jacob as a behind-the-scenes assistant that supports human patient navigators with real-time guidance. That split is the design logic in one line: an agent that works with the patient, and an agent that works with the staff who coordinate the patient’s care.

The feature reports an Alabama health centre pilot, a signed health centre as the first client, a partnership with a University of Alabama researcher, and US$100,000 in AWS credits to build the risk model. The feature reports no priced funding round for Vimedra, and none is claimed here. The credits are a cloud-computing grant, not revenue and not equity.

The economic argument is in a quote Fagbola gave Techpoint. “We realised that the people costing the healthcare system the most are the ones least served,” he said, adding: “Instead of a $40,000 emergency bill, maybe $3,000 in groceries and transport solves the issue.” The figures are illustrative, a founder’s example of the mechanism and not a measured result. The mechanism is the useful part: shift spending upstream, toward the non-clinical need that precedes the emergency.

This is the same bet that Toyin Ajayi’s Cityblock makes with people whose clinical, behavioural and social needs are split across organisations. The difference is the instrument. Cityblock coordinates through care teams under contracts with health plans and health systems. Vimedra, on the evidence available, coordinates through software agents and navigators. Whether the two models converge is a question the evidence cannot answer.

The verdict is that Vimedra has the clearest orchestration thesis in the pair and the least public proof of traction.

The Operator Pattern: Three Moves Across Two Companies

Reading the 2008 rebuild, LearnFlo and Vimedra together produces a pattern of three moves, each of which is visible in the sources.

  • Rebuild around the constraint. The failed bank deployment became a local build, and LearnFlo is priced in naira and dollars, with instant payment.
  • Sit between, not above. Both products connect an institution to an individual, rather than replacing either.
  • Stay light on capital. LearnFlo is reported as self-funded and Vimedra reports cloud credits, not a priced round.

The third move is the one capital allocators should read most carefully. Operating without external funding supports the discipline reading: the company had to earn its way. It also supports a less flattering reading: no outside investor has tested the numbers. Both are consistent with the record.

The verdict is that the pattern is real, but a pattern across two small data sets describes a method, not a track record.

What the Public Record Does Not Show

A profile built on one named feature interview and company-owned pages has predictable blind spots, and stating them is part of the analysis. The sources reviewed give no revenue figure for either company. They name no LearnFlo institutional customer and no Vimedra payer, and they give no number of Vimedra patients enrolled. They describe a patent-pending algorithm without publishing a validation result, and they report US$100,000 in cloud credits without a priced funding round.

None of this suggests the companies are weak. It marks the line between a documented design and a demonstrated business, and it tells a reader which claims in this article come from the founder and which from the companies’ own pages. Each figure above is attributed to its source for that reason.

Where the Pattern Stops

An orchestration layer becomes infrastructure when the parties on both sides cannot route around it. The clearest example in this publication’s coverage is Flutterwave, which moved from gateway to infrastructure through a sequence of licences, data and products that made each layer harder to replace. It is a test case because it shows how many separate dependencies must form before the word applies.

Applied to Fagbola’s companies, the test returns an incomplete answer. Switching costs, the second criterion, are unknown for both: nothing in the sources describes contracts, integration depth or renewal. Earnings, the third, are unstated: no revenue figure appears for either company.

A comparison with the health side clarifies the gap. Incredible Health reports, on its own figures, a change in hiring cycle time and has a defined buyer in the hospital. Vimedra has a defined problem and a pilot. The gap between those two states is where further evidence will have to fall.

Hypothetical: if Vimedra signs several health centres and reports a measured change in emergency visits among enrolled patients, the claim moves from a mechanism to a result. If it does not, the orchestration thesis stays a design.

The verdict is that Fagbola’s companies meet the first test and leave the other two open, which is a finding, not a failure.

An Operator’s Checklist: Four Questions Before Building an Orchestration Layer

The Operator column exists to turn a profile into a working method. The record on Fagbola’s companies supports a four-question checklist, applied below to what the sources actually show. The right-hand column is deliberately blunt about what is missing, because a gap in the public record is also a gap an operator would need to fill in their own business.

QuestionWhat it testsWhat the sources show
Who completes the sequence?Whether the product owns an outcome, not only a transactionVimedra describes agents that move a patient toward care; LearnFlo describes course delivery and payment
Who pays for completion?Whether revenue follows the outcomeLearnFlo shows a fee on sales; Vimedra’s payer is not stated in the sources reviewed
What did the constraint force?Whether the design fits local conditionsThe 2008 rebuild and naira pricing suggest local fit
What would prove dependence?Whether institutions would notice if the layer disappearedNo source describes renewals, integration depth or replacement cost

On Monday morning, an operator running a similar layer would do three things. First, write down the completion event, the single moment at which the person has been connected to the resource, and count it. Second, name the payer in one sentence; if the sentence needs a conditional, the revenue model is not yet a model. Third, log every case in which a customer worked around the product, because workarounds are the earliest evidence that dependence has not formed.

These are not claims about Fagbola’s practice, which the sources do not describe. They are the questions the sources make it possible to ask, and they are the ones a diligence team would put to either company.

The verdict is that an orchestration layer should be run on completions and workarounds, not on user counts.

Why This Matters for Founders and Capital Allocators

For founders building in the diaspora corridor, the profile offers a model of the coordination role. The role is available wherever a resource exists and the person who needs it cannot reach it. The sources suggest it can be started with little outside capital, but it still has to prove it can be paid for, and the useful discipline is to state on day one who pays for completion.

For capital allocators, the diligence questions are specific. Who is the paying customer, the institution or the individual? Is the fee tied to volume or to completion? What would the product’s record show after 12 months in one setting? These questions apply to any orchestration company, not only to this one.

The profile also belongs in a larger pattern. The pillar on diaspora operators argues that founders who move between markets build the layers that others rely on. Fagbola is a case of the first half of that claim, with the second half still to be shown.

Key Takeaways

  • Fagbola’s two companies are best read as orchestration layers, products that take responsibility for a sequence spanning institutions, not as unrelated ventures.
  • LearnFlo’s reported 30,000 users and ₦5 billion in fees are founder-reported, and the company’s public product page describes a course-selling platform alongside the higher-education focus.
  • Vimedra pairs a patient-facing agent with a staff-facing one, which is a clear design but, on the public record, a pilot-stage proof.
  • Both companies show a method of rebuilding around local constraints and staying light on capital, which is a pattern across two cases and not a track record.
  • Orchestration becomes infrastructure only when institutions cannot route around it, a test that neither company has yet been shown to meet.

Conclusion

The profile’s central claim is modest. Fagbola has built two products in the space between institutions and people, and he describes himself as the person who designs the system rather than writes the code. The evidence supports the design and the stated results and does not yet support a claim about dependence.

That leaves a measurable question for a later article: whether the institutions on each side of these layers begin to rely on them in ways that can be counted.