ToLABs

The problem

ToLABs is my friend's project, and I'm helping build it. It connects independent brands with the local stores and cafés that stock them. The first version was a directory on a webpack site. Brands and stores applied, an admin reviewed them, and the approved ones got a public page. You could find a maker there, but you couldn't buy anything. I rebuilt the site in Next.js so members can sell from their own page, with ToLABs taking no commission and never holding the money.

What I built

• Membership. Sign-up with an emailed code, an onboarding profile, and an admin review queue that publishes approved members to the brand and store directories.
• A shop for every seller. Products with variants and photos, pickup and shipping settings (domestic and international rates), and a site-wide shop that pulls everything together.
• Checkout and orders. Guest checkout with a cart per seller, an order page for the buyer, and an orders desk for the seller: status changes, tracking numbers, order history, and the emails that go with each step.
• Admin and design. Review, event and member tools for the admins, and a redesign of the public site, the member dashboard and the emails.

I wanted the site to cost as little as possible to run, so I picked tools with a free plan. It runs on Next.js and React on Vercel, with Postgres, auth and file storage on Supabase. Members get read-only access to the database, and every write goes through a server action that works out the seller from the session. The ordering logic lives in Postgres functions, tested with pgTAP, next to Vitest unit tests and a Playwright run through the main buying path.

The AI workflow

For me, ToLABs was the first project I built fully on my brains vault and the spec-driven workflow from Spec to ship. It's also where I learned to design pages with Claude Design, and I used Stitch for the redesign. Plain HTML pages from Claude Design were very useful for quick mocks, and I built the email templates the same way.

Decisions worth explaining

The order reference is the receipt

Card payments come later, so the shop launched on private pay. The seller writes their own instructions (an Interac e-Transfer, a bank transfer, cash at pickup) and the buyer pays them directly.

The first design had the buyer upload a receipt, and orders with no receipt expired after 48 hours. I dropped both. Now the buyer quotes a short order reference in the transfer message. The bank notification the seller already gets carries that reference, and the seller marks the order paid or cancels it. Shopify's manual payments work the same way. The change removed a storage bucket, an upload flow and a scheduled job. It also means an unpaid order stays on the seller's desk until they deal with it, instead of disappearing on a timer.

A product is public only when someone can buy it

A product shows on a seller's page only when it can actually be ordered. The seller has to be approved and have their shop switched on, with payment instructions filled in. The item also has to be digital, or the seller has to offer pickup or shipping.

That rule is one SQL function in the WHERE clause of the public views, and nothing about it is stored. A listing can't be visible while checkout would fail, and there's no flag to fall out of sync. The seller's dashboard says which part is missing. Before this, products showed up with an "Ask about this item" button until the seller set up payment, which left buyers on pages they couldn't buy from.