Brian Saizi
Operations · Marketplaces · Automation

I keep a marketplace healthy, and I build the systems that run it.

Six years in Johannesburg driver operations at Bolt, from the first step of the onboarding funnel to a driver's first accepted trip. Along the way: city management, partner deals, driver forums, and the Looker, Databricks and Apps Script automation behind the numbers. In 2026 I also built my own Linux, my own local AI and a WhatsApp marketplace, because operations is better when you can build your own tools.

Driver onboarding & activationCity & supply operations Partner negotiationSQL · Databricks · LookerApps Script automation Node · Python · TypeScriptLinux from scratchLocal AI

At a glance

Operations Specialist, Driver Engagement at Bolt. Two promotions in five years. Johannesburg. Open to operations, supply, marketplace and analyst roles, on-site, hybrid or remote.

6+
years in driver ops
3
roles at Bolt, 2020 to now
3
systems built in 2026
20–100
drivers per forum I host

Figures inside the demos below are illustrative and marked illustrative. Numbers marked measured come from real test runs and logs on my machine.

The story

From a service desk to the supply side of a city

I started where most operations people start: answering the phone. On an IT service desk I learned that a queue is a funnel, that every ticket has a reason it is stuck, and that the fix that matters is the one that stops the next ticket. In 2020 I took that habit to Bolt, into a city where thousands of drivers were trying to get on the road.

A driver's journey is a funnel with people in it. Sign-up, documents, vetting, activation, first trip, then the long tail of staying online and earning. My work was to walk that funnel every day, find where drivers fell out, and fix it with whoever owned the step: product, support, the city team, or me on the phone calling leads who had stalled. Then I taught the next person to do it, and the next team.

Supply is not a number. It is a driver who decided this morning that going online was worth it.

So the job grew outward. Peak and off-peak campaigns to match supply to demand hour by hour. City visits to see the pick-up points at malls with my own eyes, and relationships with the people who run those malls so that drivers were not moved on by security. Partner signings such as Kasi Money and Best Drive, and a negotiation with Vodacom to unlock value for drivers, because an engaged driver is one who gets more from the platform than trips. Forums of twenty to a hundred drivers, where I gave the update, took the feedback, and brought it back. Meetings with government officials and business partners when a signing needed a signature.

And underneath it, the data. I automated the reporting that fed partners and in-house teams: Looker looks joined on a common key with Databricks data, status checks, and the email that went out on schedule through Google Workspace scripting, so nobody had to build the same sheet twice. When I managed several cities at once, that is what let me keep each one profitable and under spend.

In 2026 I decided that if I could run operations, I could build the tools too. The three builds further down this page are the result: an operating system, a local AI, and a marketplace that runs on WhatsApp.

    Demo 1 · Data visualisation

    The driver funnel, step one to accepted illustrative

    Every stage loses people. The job is to see where, size it, and pick the lever. Move the sliders to see how a fix at one step changes the number of drivers who reach their first accepted trip, and what each activation costs.

    What I did with this view at Bolt: identify the drop-off step, then fix it with the owning team. Documents stalled? Call the lead and walk them through the photo. Vetting slow? Chase the queue. Activated but no first trip? A targeted incentive in the first week.

    Demo 2 · Supply and demand

    Peak and off-peak campaigns illustrative

    Demand peaks twice a day. Supply does not follow by itself. A campaign pays drivers to be online in the hours that matter. Switch the campaign on and watch the coverage gap close, then watch the cost of closing it.

    demand (riders requesting)supply (drivers online)campaign hours
    Demo 3 · Business sense

    Several cities, one budget illustrative

    Two KPIs I watched above all others when I ran more than one city: contribution margin per city, and spend against budget. Growth you cannot afford is not growth. Pick a quarter and see how the cities compare.

    net revenue, R thousandspend, R thousandspend above the city's own revenuemargin % = (revenue − spend) ÷ revenue
    Demo 4 · Automated reporting

    Looker and Databricks to an inbox, on schedule

    The problem: several teams and partners needed the same numbers every morning, pulled from different Looker looks and a Databricks table, joined on a common key, with a status check so nobody acted on stale data. The fix: a scheduled Google Apps Script that did the whole chain and sent the email. Press run to watch it.

    1 · Pull the looksLooker API: three looks, one per source (sign-ups, documents, activations). waiting
    2 · Pull the tableDatabricks SQL: trips by driver for the same window. waiting
    3 · Join on the keydriver_id joins all four sets into one row per driver, then rolls up per city. waiting
    4 · Status checksRow counts, freshness, nulls on the key. Fail any check and the email says so instead of sending numbers. waiting
    5 · SendGmail from Apps Script to partners and in-house teams, sheet attached, every weekday at 07:00. waiting

    Joined report illustrative

    The email that goes out

    Press run.
    The shape of the script 
    // Google Apps Script, scheduled trigger: weekdays 07:00
function morningReport() {
  const looks  = [41, 42, 43].map(id => lookerRun(id));          // sign-ups, documents, activations
  const trips  = databricksQuery("SELECT driver_id, city, trips FROM trips_daily WHERE d = current_date()-1");
  const rows   = joinOn("driver_id", ...looks, trips);           // one row per driver
  const checks = [rowsPresent(rows), freshWithin(rows, 24), noNullKeys(rows)];
  const byCity = rollUp(rows, "city");
  const sheet  = writeSheet("Morning report", byCity);
  const body   = checks.every(c => c.ok) ? summarise(byCity) : "Checks failed: " + failed(checks);
  GmailApp.sendEmail(recipients(), "Morning report " + today(), body, { attachments: [sheet.getAs("application/pdf")] });
}

    Shape only: the real script's queries and recipients belong to the company. The pattern, pull, join, check, send, is the one I reuse.

    People and partners

    The part of operations that does not fit in a dashboard

    Driver forums, 20 to 100 drivers

    I host them, give the update and the speech, take the feedback in the room, and bring it back to the teams that can act on it. Drivers tell you in person what they never type into a support chat.

    Onboarding and training teams

    I have onboarded multiple team members and trained in-house teams of six to ten in the funnel work: how to read the drop-off, how to call a stalled lead, how to run the trackers so the reporting stays true.

    Partner signings and management

    Kasi Money and Best Drive signed on as local partners. A negotiation with Vodacom to unlock value for drivers, so that staying engaged on the platform pays beyond the trip. Then the ongoing management that keeps a partnership alive after the signing.

    Malls, stations and pick-up points

    City visits to walk the pick-up and drop-off points, and relationships with mall management so the points stay where the map says they are and drivers are not moved on.

    Government and business negotiations

    In the room with government officials and business partners for the key negotiations and signings, representing the operation and the drivers who depend on it.

    Leads, by phone

    From step one of the funnel I have called leads myself: the stalled sign-up, the rejected document, the activated driver who has not taken a trip. Then I taught others to do it, and handled peak and off-peak demand and supply campaigns while city visits carried on.

    These are my own accounts of the work. Company figures stay with the company; the demos above show the methods with illustrative numbers.

    Builds · 2026

    Three systems, built from scratch on an 8 GB laptop measured

    The underlying layer. Everything here runs on a MacBook Air with 8 GB of memory, at no monthly cost, and every change is scored with tests before it is switched on.

    Alto Code OS

    My own Linux for the M1 MacBook Air, booting beside macOS. Built with Buildroot and the Asahi kernel inside a Debian virtual machine I launch from a 92-line Swift program. Full-disk encryption, a firewall that drops everything inbound and only lets DNS out over TLS, and a kernel patch that centres the console in a window because the left of my screen is damaged. On 7 October it got a native compiler and developer tools so it can build its next version itself.

    Shell · Python · Swift · C · Buildroot/Kconfig · GRUB · LUKS2 · nftables

    A personal AI that runs locally

    A Node agent driving a 4-billion-parameter model in Ollama with a 32K context, an embedding router that classifies every ask into one of six kinds before acting, a tool loop where every number in an answer must come from a tool's output, 293 skills retrieved by meaning, and free stand-ins for paid services. A rooted Samsung phone on a USB cable computes the embeddings to free the laptop's memory. 43 versions, each installed with backup, checksum, tests and automatic rollback.

    Node (ESM) · Python · Ollama · llama.cpp · MLX · Whisper · PostgreSQL/Odoo

    Alto Engine, a WhatsApp marketplace

    One Cloudflare Worker running two small South African ventures: a WhatsApp sales bot that delivers a free Google-review audit and takes PayFast payment, and a painters marketplace where homeowners post jobs and painters claim them, all inside WhatsApp. Four SQLite-backed Durable Objects, two cron jobs, forced tool-use with a language model for structured replies. Live at go.altoreviews.com for R0 a month in fixed cost.

    TypeScript · Cloudflare Workers · Durable Objects · WhatsApp Cloud API · PayFast

    Scoreboard: the tests that gate every change

    Each test suite ends in a SCORE line. A change ships only at full marks; otherwise it rolls back by itself.

    The console window

    The left strip of my laptop screen is damaged. Rather than live with it, I patched the kernel's console driver to draw inside a window and put three choices in the boot menu. The simulator test measures the window from screen pixels. Pick an entry.

    The AI, version by version

    Each version is one installed update with its own tests. Drag to scrub.

    Demo 5 · The AI applied to driver support

    A support assistant that answers from the handbook and shows its source

    Driver questions repeat: documents, payouts, going online, pick-up points. The method from my AI fits this exactly: split the handbook into pieces, rank them against the question, answer only from the best piece, and quote the line it came from. If nothing matches, say so instead of guessing. This runs in your browser with a sample handbook written for the demo; the real version runs the same way on a local model with no cloud, or behind the WhatsApp bot in Alto Engine.

    Hi, I am the driver-support demo. Ask about documents, payouts, going online, trip requests, pick-up points, ratings, cancellations or campaigns.

    How it decides

    1. The question is cut into words and stems, with driver slang mapped to handbook words.

    2. Every sentence of the handbook gets a BM25 score against those words.

    3. The best sentence names the section; the answer is that section's steps, with the matching sentence quoted as the source.

    4. Below a score threshold the assistant declines. No match, no answer.

    In my AI the same gate is tighter: every fact in an answer must be found word for word in a named source, or it is dropped. Scoring and verification happen in a sandbox copy before any change goes live, with precision and recall measured per kind of ask.

    Languages and tools

    What I work in

    Data and reporting

    • SQL on Databricks
    • Looker dashboards and looks
    • Google Sheets and Apps Script automation
    • Gmail and Workspace scripting
    • Python for scripting and data pulls

    Operations

    • Driver onboarding funnels and activation
    • City and supply/demand operations
    • Fleet and partner management
    • Campaign design and measurement
    • Training and forums

    Building

    • JavaScript and Node (ESM)
    • TypeScript on Cloudflare Workers
    • Python tooling (OpenCV, ffmpeg, MLX)
    • Shell, Make, Buildroot, Linux internals
    • Swift (Apple Virtualization), C (kernel patch)

    AI and messaging

    • Ollama, llama.cpp, local models and embeddings
    • Retrieval by meaning, BM25, verification
    • WhatsApp Cloud API bots
    • PayFast payments, Google Places
    • Meta and Google Ads for demand tests
    Contact

    Let's talk

    Johannesburg. Open to operations, supply, marketplace and analyst roles, and to teams that want someone who can run the operation and build the tools.

    LinkedIn   Email