Isaac Ochieng
I work out why the numbers don’t add up — then build the process that keeps them adding up.
I help small and growing organisations get their data into a state they can trust. Cleaning up what’s messy, reconciling the records that disagree, building reports people actually open, and setting up the pipelines that keep those reports running without someone rebuilding them by hand every month.
| status | orders | late | % late |
|---|---|---|---|
| delivered | 96,478 | 7,826 | 8.1% |
| shipped | 1,107 | — | — |
| canceled | 625 | — | — |
| processing | 301 | — | — |
Services
Three ways I usually help.
Each one is fixed-scope and quoted in writing before anything starts. Most engagements begin with the audit and only continue if it turns up something worth fixing.
Who this is for
Different sectors, the same shape of problem.
Data spread across systems that were never meant to talk to each other, and a monthly report someone dreads building.
Selected work
One project in full, rather than ten I can’t discuss.
Client work is covered by confidentiality and discussed on request. This is the portfolio work — the brief, the method, and the mistake I nearly shipped. Scroll to advance.
Ranking sellers by average delay almost made me miss the real problem.
A delivery-performance audit of a 100,000-order marketplace, and the ranking that pointed the wrong way.
Nearly one in three sellers on this marketplace had shipped at least one late order. The obvious first move was to rank sellers by average delivery delay and start at the top of that list.
That ranking was misleading. It surfaced low-volume sellers with a single bad month, while the high-volume sellers responsible for most of the actual late deliveries sat well down the list. Average delay answers a different question than the one that matters operationally.
The write-up covers how I caught it — including the row fan-out and inner-join traps that quietly drop unreviewed orders out of the count before you’ve noticed the totals stopped reconciling.
~100,000 orders · delivery performance · seller-level analysis · reconciliation checks at every join.
StatusAnalysis complete. Full case study publishing shortly.
What’s being built next.
Stated plainly, so you know what’s finished and what isn’t.
Two further portfolio projects are underway and will appear here as they’re finished, not before. I’d rather this section stay short and true than fill up with work I can’t stand behind.
Alongside them, I’m working through transformation modelling and warehouse design — so the pipelines I set up for clients hold their shape as those organisations grow, rather than needing rebuilding in a year.
If you’d like to talk about work in progress, or see the SQL behind the delivery audit, ask me directly. I’m happy to walk through it.
Analysis today. Pipelines and analytics engineering next — in that order, deliberately.
Get in touchcontact@chuiassistant.com
Capabilities
What I reach for, and what I reach for it to do.
SQL
Joins, window functions and CTEs — plus the reconciliation checks that catch a wrong number before it reaches a dashboard. Most of my time is spent here.
Tableau & reporting
Dashboards built to answer a specific question rather than to fill a canvas. If a chart isn’t changing a decision, it’s costing attention for nothing.
Cleaning & reconciliation
Finding where two systems disagree and working out which one is right. Unglamorous, and usually where the real problem turns out to be hiding.
Spreadsheets
Excel and Google Sheets — still where most organisations keep the numbers that matter. Worth doing properly rather than migrating away from on principle.
Python
Cleaning, reshaping and automating the steps that would otherwise be repeated by hand every month. The point is that it stops being a monthly job.
Data modelling
Structuring tables so the same question gives the same answer regardless of who asks it. This is the bridge into the analytics engineering work I’m growing into.
Code
The query that corrected the ranking.
From the delivery-performance audit. The first version ranked on average delay alone; this one weights by how many orders each seller actually ships, and sets a volume floor so a single late order can’t top the table.
-- Seller delivery performance, weighted by volume.-- LEFT JOIN on reviews: an INNER JOIN silently drops-- unreviewed orders and inflates the on-time rate.WITH order_delay AS ( SELECT oi.seller_id, o.order_id, DATE_PART('day', o.order_delivered_customer_date - o.order_estimated_delivery_date ) AS delay_days FROM orders o JOIN order_items oi USING (order_id) WHERE o.order_status = 'delivered' AND o.order_delivered_customer_date IS NOT NULL),-- one row per seller/order, not per line itemdeduped AS ( SELECT DISTINCT seller_id, order_id, delay_days FROM order_delay)SELECT seller_id, COUNT(*) AS orders, COUNT(*) FILTER (WHERE delay_days > 0) AS late, ROUND(AVG(delay_days), 1) AS avg_delay, ROUND(100.0 * COUNT(*) FILTER ( WHERE delay_days > 0) / COUNT(*), 1 ) AS pct_lateFROM dedupedGROUP BY seller_idHAVING COUNT(*) >= 30 -- volume floorORDER BY late DESC, pct_late DESC;
| seller | orders | avg delay | late |
|---|---|---|---|
| seller_a | 2 | 21.0 | 2 |
| seller_b | 1 | 18.5 | 1 |
| seller_c | 840 | 2.1 | 214 |
| seller_d | 610 | 1.8 | 158 |
Rank by avg delay and sellers A and B lead. Rank by orders actually delivered late and C and D do — and they’re the ones worth calling.
The first ranking wasn’t wrong arithmetically. It was answering a question nobody had asked.
FAQ
The questions I get asked most.
With a free conversation, usually about thirty minutes, where you describe what’s going wrong. If it sounds like something I can help with, the next step is normally a data health audit — fixed scope, fixed price, quoted in writing before anything starts. If the audit finds nothing worth fixing, I tell you that.
Almost never. Most of the organisations I work with need their existing numbers to reconcile before they need new infrastructure. Buying a warehouse to sit on top of data nobody trusts just makes the mistrust faster. We start with what you have.
Analyst today, deliberately. SQL, reporting and making messy data trustworthy is where I’m most useful right now, and it’s what most small organisations actually need. I’m building toward analytics engineering — transformation modelling, warehouse design — and I’d rather state that as a direction than dress it up as a credential I don’t yet hold.
Yes. I’m based in Nairobi and work with organisations across Kenya and further afield. Most of the work is done remotely, with calls when they’re useful rather than on a fixed schedule. If you’re nearby and would rather meet in person, that’s fine too.
Yes, alongside client work. If you’re hiring for a data analyst or analytics engineering role and this way of working looks like a fit, get in touch — the work on this site is the clearest picture I can give you of how I think.
Writing
Project write-ups, including what didn’t work.
Post-mortems and pieces on the data problems that come up again and again in small organisations. First articles publishing shortly.
Ranking sellers by average delay almost made me miss the real problem.
The full method behind the delivery-performance audit — and why the first ranking I built pointed at the wrong sellers.
Data problems costing Kenyan SMEs money in 2026.
M-Pesa records that never match the books, stock counts nobody trusts, and reports rebuilt from scratch every month.
Currently
What I’m doing right now.
Nairobi is closer than you think.
I’m on East Africa Time — GMT+3. That’s a full working-day overlap with Europe, the Gulf and India, and a solid afternoon window into the UK. Pick your city and see for yourself.
Something not adding up?
If your reports take too long to build, your numbers don't reconcile, or there's a repetitive data task eating a day every month — I'd like to hear about it. The first conversation is free and usually takes about thirty minutes. If you're hiring for a data analyst or analytics engineering role, that's welcome too.
contact@chuiassistant.com