Ten modules taught you Excel, SQL, cleaning, statistics, Power BI, Python, AI-review and communication one at a time, each with its own tidy dataset. This is what happens when a founder hands you all of it at once, six days before an investor meeting, for a business you've never looked at before — and one line from an investor email is the only brief you're given.
Femi Balogun runs Ridewell, a three-year-old last-mile delivery startup working out of Yaba — forty motorcycle riders moving parcels across Lagos for fourteen online sellers who don't want to build their own logistics arm. Ridewell is six days from a funding review with its two investors, the kind of meeting that decides whether the next twelve months happen at all.
Every earlier drill in this course handed you one clean dataset at a time. This one hands you a business's entire messy operational reality, with a deadline that was already tight before you arrived.
An hour ago, Femi forwarded you one line from an investor's email, with no other context: "Your late-delivery rate is trending up quarter over quarter. Explain why, and what you're doing about it, before Thursday." That's the entire brief. Everything else — what "late" even means in Ridewell's own data, which riders or zones or sellers are actually driving it, whether the fix Femi already rolled out is working — you have to find yourself, in what's sitting on Ridewell's laptop today.
This is deliberate. Every client you take on after this course will start exactly like this — a stranger's operation, a vague question standing in for a much sharper one, and a deadline that doesn't move. The capstone is not harder because the analysis is new. It's harder because nothing has been scoped for you first, and the business itself is the mess.
A ninety-day delivery-log export, an operations database with a genuine join trap buried in it, four weeks of pilot data Femi already half-believes solved the problem, an intern's AI-drafted analysis that needs checking, and a board deck due Thursday — this is engineered to exceed what a careful analyst can fully verify in six days. What you chase, what you flag as unverified, and how you defend that choice in the walkthrough is being assessed as closely as the analysis itself.
Five inputs, all live at once, exactly as they'd land in a real first week with a founder who has never worked with an analyst before. Every module's disciplines are needed somewhere in this — nothing here is solvable with only one module's toolkit.
Rather than being handed a pre-built dataset, construct a realistic version of each input yourself — a ninety-day delivery log with the specific messiness described above, a real riders/orders/sellers/zones database with the overlapping-pilot trap actually built in, four weeks of before-and-after pilot numbers that could honestly go either way, and a short AI-drafted analysis with real, specific flaws planted in it. This is itself part of the assessment: a capstone built on inputs you designed with real judgement about what a messy first week actually contains is a stronger piece of work than one built on a thin or unrealistic version of the mess.
Treat this as live, not static — a sixth seller Femi forgot to mention, a rider dispute that surfaces mid-week, a follow-up question from an investor's associate arriving before you've finished the first pass. Real client weeks don't pause while you catch up, and neither should this one.
Every deliverable draws on a specific earlier module. None of them are new skills — this is entirely about applying what you already have, on a real business, under real time pressure.
The SQL investigation isn't just module 3's join syntax typed out against a new schema — it's your own judgement about whether the priority-zone overlap is quietly inflating a rider's late count before you present that rider as the problem. The pilot verdict isn't just "yes it worked" or "no it didn't" — it's module 5's discipline of naming exactly how confident four weeks of noisy data actually lets you be, even when a founder wants a cleaner answer than that. Every deliverable is the module's discipline, not just its shape.
Submitting the seven deliverables is not the end of the capstone. A short walkthrough — five minutes presenting the work, followed by being challenged on it — is where the judgement behind the deliverables actually gets tested, not just the finished output.
A polished dashboard proves you can produce good work. A well-handled challenge proves you can defend the number behind it — which is what a board is actually trusting an analyst with.
Not a tour of all seven deliverables in equal depth — that's too much for five minutes and dilutes the parts that matter most. Instead: the single hardest judgement call you made this week, what you chose to leave unverified and why, and one thing you'd do differently with another day.
Expect direct questions that press on the actual judgement, not just the output — the kind a real founder, or a course assessor standing in for one, would genuinely ask:
Not defensiveness, and not instant capitulation either. A well-handled challenge sounds like: stating the reasoning plainly, acknowledging genuinely if the challenge reveals something that was actually missed, and holding the verdict if it was actually right and the reasoning still holds under pressure. This is the same three-way check discipline from module 8, turned on your own analysis instead of an AI tool's output.
Every capstone gets challenged, including strong ones — it's built into the format deliberately, not triggered by a weak submission. Treat a hard question as a normal part of the format, not a signal you're about to be told you failed.
Not on whether every row of ninety days of data got checked, whether the dashboard looks polished, or whether the Python script is elegant. On whether the judgement behind an unreasonable six days' worth of decisions was sound, defensible, and honestly reported.
Every module's drill tested one discipline against one tidy dataset. This tests whether all ten disciplines survive contact with each other, at once, under real pressure, for a business you've never seen before — which is the actual job, on the actual first week of any real engagement. That is the entire promise of this course's title: an analyst whose numbers can actually be trusted, not just one who can run a query.
You now have a complete, honestly-labelled portfolio piece spanning every module in this course — exactly the kind of documented, defensible case study module 10 described, built under real assessed pressure rather than a practice exercise. Use it. It is, quite literally, the proof that your numbers hold up when someone pushes back on them.