Founder · Live productEvery tiffin kitchen I met had the same five problems. So I built the fix once — for all of them.
Tiffinware is software that home-style meal-subscription kitchens rent to run their business: subscriptions, the morning cook sheet, delivery routes, drivers and payments, in one place. It is the Dakshin problem turned into a product anyone can buy — $99 a month, flat, with no cut of orders.
who's eating tomorrow? who paid? who's driving?Building one kitchen’s platform showed me every kitchen’s problem.
Building Dakshin Foods' operations platform made one thing obvious: every tiffin kitchen in Metro Vancouver is asking the same five questions each morning: who is eating tomorrow, what do we cook, who has paid, who is delivering, and did anyone pause.
Their options were generic restaurant software — which doesn't understand a subscription to food, or a customer skipping Tuesday — or marketplaces that take a percentage of every order from a business already running on thin margins.
Flat price, no commission — because they can’t afford to give a cut.
$99 a month, or $79 billed yearly. Unlimited customers, drivers and staff. A kitchen that doubles its orders pays exactly the same. Pricing isn't a spreadsheet exercise here; it's the whole pitch.
The platform shouldn't take a cut of a business that can't spare one.
An owner console where the morning runs off one screen.
A cook sheet that locks at the kitchen's cutoff — portions per dish in real measures, container counts, allergy notes — and one-click printable box labels.
Delivery zones by postal-code prefix, routes that build themselves in GPS-optimised order, card payments through Stripe, e-Transfer reconciliation, and weekly menus published per plan.
A customer portal that carries the kitchen’s brand, not mine.
Each kitchen gets its own subdomain and branding; Tiffinware is invisible. Customers skip a day or pause in two taps before the cutoff, see this week's menu, pay by saved card, and watch their tiffin move from the kitchen to their door with the driver's name on it.
The tenant is resolved from the host, never a hardcoded path — that shortcut breaks white-labelling the moment a kitchen shares a link.
A driver app on the App Store and Google Play.
A native Flutter app: the day's stops already in driving order, the route handed to Maps in batches, photo proof at each door, notes from the kitchen, and live progress back to the owner. It keeps working offline and syncs when signal comes back.
Drivers are hired on terms, set themselves up, and see their own pay per day. Getting it through both stores meant a privacy policy, demo accounts reviewers could actually sign in with, and a resubmission after App Review.
Sixteen reports, because a kitchen is a business.
Profit and loss with food-cost percentage, subscriptions and MRR, cohort retention, revenue at risk, delivery performance by area, driver pay reconciliation, GST collected, demand by weekday — each with a date range the owner controls, built from shared components so the demo kitchen and a real one compute them the same way.
Six problems that don't show up in a feature list.
The payment rail with no webhook
TrapMost customers in this market pay by Interac e-Transfer. It arrives as an email, not an API event, and the sender’s address often looks nothing like the name on the account.
FixThe platform reads the transfer notifications, matches each one to the right subscription, remembers a sender once an owner confirms it, and turns the leftovers into an overdue list with one-tap reminders.
The reconciler that reported success
TrapPayment matching was quietly rolling back every insert. A case-insensitive text comparison raised an error inside the transaction, so each row failed while the batch said “done”.
FixFixed the type mismatch, then made failure loud: a reconciler that can’t fail visibly is worse than none. Live-database scenario suites now run against every money path.
An invite link that took over accounts
TrapStaff invites were bearer tokens. Whoever happened to be signed in when they opened the link got the role — and could demote the only owner.
FixAn invite now has to match the signed-in email, and a kitchen can never lose its last owner. Cross-role tests probe it as each role, from outside the database.
A 32-stop day showing a 9-stop route
TrapMaps deep links silently cap the number of waypoints. A driver tapping “open route” saw the first nine stops and nothing told them the rest existed.
FixThe driver app batches the route — “See next 9 stops in Maps”, deliver, tap again — and keeps the GPS-optimised order instead of letting Maps reshuffle it.
Labels that have to fit a real box
Trap“Looks fine in the browser” isn’t a test for a sticker on a container. One long kitchen note grew its own row and walked the whole sheet off the page.
FixLabel layout is checked by a script (npm run check:labels) against the real sheet dimensions, and tested with a real kitchen’s rows — which found three defects the fixtures never could.
One door for every subscription change
TrapPause, skip, resume, switch plan, cancel — five screens each writing state their own way is how credits and billing drift apart.
FixEvery change goes through a single database function. Cross-tenant admin is a closed set of audited functions, never loosened row-level security.
- 3
- surfaces + a native driver app
- 16
- built-in business reports
- 189
- database migrations
- 43
- Postgres tables, 400+ functions
- 205
- commits, Jul → Sep 2026
- 0%
- commission, by design
Live, honest about it, and onboarding the first kitchens.
The marketing site, the owner console, the customer portal and the driver apps on both stores are all live, with a full demo kitchen anyone can click through without signing up. SaaS billing is built and tested — and deliberately switched off while the first kitchens come on board.
No paying-customer numbers to brag about yet. The software is the receipt.
Running a subscription business on WhatsApp and a notebook?
I build the system that fits how your day actually works — and then keep it running.
Tell me about it