Client work · dakshinfoods.caA family kitchen was paying rent on software that couldn't run their business.
Dakshin Foods is a South Indian kitchen in New Westminster, BC. Their real business is tiffin meal plans — prepaid, home-delivered meals cooked fresh every weekday. Their software was a generic ordering site. I replaced it with an operations platform built around how their day actually works.
one real kitchen in New West — and its whole day, in softwareThe meal plans lived everywhere except in the software.
The ordering site handled takeout, and that was it. Subscriptions — the heart of the business — were tracked in the owner's memory and a WhatsApp scroll. Renewals got chased by hand. The kitchen cooked from a mental list. Drivers got addresses over text, one at a time. Sales from the Clover till reconciled against nothing.
And for the privilege of not solving any of that, the SaaS charged a monthly fee.
The spec came from watching a real day, not from a feature list.
Before writing code, I mapped the owner's actual morning: what gets cooked, how boxes get packed, who drives where, which customers are about to run out of meals, who still owes an e-Transfer. Every screen in the platform corresponds to a step she was already doing by hand.
The features aren't clever. They're hers.
An owner console and a kitchen that runs off one screen.
Subscriptions with prepaid delivery credits — plans priced by tier, zone, and pickup versus delivery, a payments ledger built for Interac today and cards later, and renewal nudges with prefilled WhatsApp links so chasing a renewal takes one tap.
Kitchen & dispatch — the day's cook sheet, printable box labels that carry allergy notes, and a dispatch board that assigns boxes to driver runs. Deliveries for the next day generate themselves overnight.
A driver app and a customer portal that remove the phone tag.
The driver app is a phone-first PWA: today's route, per-stop delivery notes, and photo proof-of-delivery with location — so “where's my tiffin?” has an answer with a picture attached.
The customer portal lets customers pause deliveries, skip a day (the credit rolls forward), switch plans for their next term, and see their billing — things that used to be a phone call each. The public site carries the menu and live meal plans.
The part nobody sees is the part that makes it safe.
Underneath: a 25-table Postgres schema where row-level security is the real product boundary. Drivers can't read customer records — each stop carries a snapshot of only what that delivery needs. Nightly jobs generate the day's boxes from live credit balances, so the cook sheet is derived from the truth rather than retyped. And a Clover POS history warehouse syncs the till nightly, so revenue finally reconciles across walk-ins, web orders, and meal plans in one view.
The owner runs it herself.
Enrolments, dispatch, renewals, refund-a-missed-box — all owner-operated, day in, day out. The SaaS subscription is gone. When something new comes up in her day, the platform grows a screen for it, because it's hers.
Software that fits the business, instead of a business bent around software.
Have a business running on spreadsheets and group chats?
This is the kind of project I take on: watch how the work actually happens, then build the system that fits it.
Tell me about it