Building

Things I have made outside the day job, and the reasoning underneath them. These are small on purpose. They exist so that when I make an architecture call at work, I have recently paid the price of one myself.

The thesis

Every marketplace I care about has the same bottleneck, and it is never the software. It is supply-side liquidity and regulatory gating. Getting sellers onto the platform and keeping them compliant is the hard part. The app is the easy part, which is exactly why so many people build the app first.

I learned that the expensive way. Years ago I spent about a year setting up a fast-food business in India: a small idli concept with a model that stretched across dine-in, delivery, catering, franchising, and cloud kitchens. I registered the domains. I built out the plan. It closed at a loss.

What I took from it was not that food is hard. It was that I had solved the wrong problem carefully. Everything I build now starts from the constraint rather than the interface.

Projects

live in production · solo

Homemade

A hyperlocal two-sided marketplace connecting home cooks with people nearby who want to eat what they make. Next.js and TypeScript on Vercel, PostgreSQL on Supabase. I designed it, built it, secured it, deployed it, and I operate it.

It is running as a pilot with a handful of cooks in a single ZIP code. That is deliberate. I would rather learn what actually breaks at three cooks than guess at three hundred.

The second attempt at a market I already paid tuition in. Built around the supply side and the compliance surface first, with the customer experience following from those constraints instead of the other way round.

The engineering decision I am most attached to: authorisation lives in the database as row-level security rather than in the application layer. Not because it is more elegant, but because of the failure direction. A policy I forget to write denies access. An application check I forget to write leaks data. When you are the only reviewer on the team, you design for the mistake you can survive.

side project

RE Analyzer

A housing inventory analysis tool built on ZIP-level listing data, with a pipeline that ingests, normalises, and serves market signal at neighbourhood granularity. FastAPI and Python, with an embedded SQLite-compatible database at the edge.

An exercise in how cheap a real data product can be if you refuse to over-provision. It runs for roughly a dollar a month. Every architecture decision is written down with the alternative I rejected and why.

Why I keep doing this

I have spent twenty years building platforms that serve someone else's product. That is real work and I am good at it. But there is a gap between reviewing a design and living with one, and the only way I know to close it is to ship something end to end and then run it for a while.

Everything on this page is small. None of it is where my ambition is. What it does is keep me honest about what production actually costs, so that when I tell a team their approach will not survive contact with real users, I am speaking from something more recent than memory.