Systems · 4 built, none in production
The software side.
Four operational systems for the businesses that run this economy — parking, retail, rent and school fees. Every one of them settles money through M-Pesa, which is why they are one body of work rather than four hobbies.
The same problem shows up in all four: a small business collects money from many people, the record of who paid is a book or a WhatsApp thread, and the reconciliation happens in somebody's head at the end of the month. Getting the settlement path right once is worth more than building four of them badly.
None of these has a paying customer, and none is running in production. One is at pre-pilot and three are in development. Line counts below measure size, not revenue and not quality — they are here so a reader can tell the difference between a platform and a weekend, which is a distinction four confident-looking names would otherwise blur. When one of these takes real money from a real customer, this paragraph changes and not before.
The four
~120,000 lines in total, built soloCameras read plates at the gate, an on-site agent runs the lane through network loss, drivers pay on exit, and a barrier opens on a dry contact.
Python · FastAPI · Go · PostgreSQL/TimescaleDB · React
Status: Pre-pilot — backend feature-complete, never run on a real gate · Case study →
One shared inventory and payments engine, with a separate front end per trade rather than a theme switcher, so each industry gets its own vocabulary.
TypeScript · Turborepo monorepo · Supabase
Status: In development
Rent collection and tenant ledgers where M-Pesa payments reconcile automatically, so “who has paid this month” always has a current answer.
TypeScript · Cloudflare Workers · Hono · D1/Drizzle · React 19
Status: In development
Fee ledgers and payment matching built around the term cycle, offline-capable because the connection is not a given.
Python · Django · PostgreSQL · Redis
Status: Backend only — payment engine passing 19/19 tests, no front end yet
Why four, and why three of them are paused
The obvious criticism of this page is that it shows four unfinished things, and that starting is easier than finishing. It is a fair criticism and the honest answer is that it was true for a while.
What changed is the sequencing. ParkSense is the only one being taken to a customer right now; the other three are deliberately on hold rather than being nudged forward a little each week, because four systems at twenty-five percent attention each is how none of them ever meets a user. Three active projects is the limit that works for me, and security consulting is currently two of the three.
What the four share is more useful than any one of them: the same settlement problem, solved once. The M-Pesa integration, the idempotency handling, the reconciliation sweep and the webhook verification are the same engineering in every case — which is also why the payment integration reviews I sell are the thing I have most reason to be good at.
What I am working on this month is dated and says which of these is moving.
If you operate one of these businesses
ParkSense is looking for one pilot site — a small car park, an estate, an office block or a church — and the arrangement is free service in exchange for being the first real installation and letting me write about what breaks. If that is you, the first conversation is short.