Calmo Cafe | reservations, ordering, and café operations

A friend of mine is leaving blue-collar work to open a brunch café in Toronto. He is an immigrant bootstrapping wherever he can, and the default path (OpenTable, listing products, an agency site) gets expensive before the business has proven itself. Toronto's café scene is crowded, and independents on main streets feel the margin pressure first. Opening into that is a real bet, not a lifestyle project. I told him I would take the website, partly as a favor and partly because tools like Cursor, Vercel, and Supabase made it realistic for one person to ship something that used to mean hiring an agency. The question I gave myself was simple: could I cover what he actually needs at roughly $0, without locking him into reservation SaaS before the café has earned the right to pay for one?

For a brand-new café in a saturated city, the expensive part isn’t having a website. It’s the stack of defaults you’re told you need: a booking platform with monthly fees, a listing product that wants a cut of attention, and a site that looks fine but doesn’t match the place you’re trying to build. My friend doesn’t need enterprise covers optimization. He needs people to find Calmo, understand the vibe, see the menu, and, when a group wants a set time, request a table without him living on the phone. Walk-ins still matter, and paying for OpenTable before the doors are proven felt like the wrong place to spend money when rent, labour, and food costs are already the things that sink independents. So the product question wasn’t how to build the best reservation system; it was how to build the smallest honest one that keeps his money in the business.

I scoped bookings as a request rather than an instant book. Guests leave name, email, phone, party size, date, time, and optional notes; the request lands as pending; he or whoever’s on shift confirms from a simple admin inbox; and only then does the guest get the confirmation email, with modify, cancel, and add-to-calendar. A few choices came straight from keeping the system cheap and maintainable: PIN login for staff instead of a full accounts product, a 30-day window with 30-minute slots tied to real hours, and email that can fail without killing the booking so the request still saves. I also used the project as practice: Supabase for the data model and statuses, Resend for the email lifecycle, Vercel to ship, and Cursor to move faster than I would have two years ago, because the learning was how I could afford to do the favor well.

For guests: branded landing (hero, about, menu, gallery), request-a-table flow, whole-pie advance ordering with pickup scheduling, wholesale and private-event inquiry forms, success states, and tokenized manage links once staff confirms. For the operator: PIN admin, inbox and schedule views, preparation lead times, restricted dates and capacity constraints, confirm / cancel / complete / no-show, and a light audit trail. Under the hood: Next.js, Supabase, Resend, Zod, Vercel, with Square POS and payment workflow considered for transaction fees and operational overhead.

The right commerce experience for a small hospitality business is not just a prettier website. Whole-pie orders need lead times and blackout dates. Pickup windows have to match how the kitchen actually runs. Payment infrastructure carries transaction fees that matter at brunch margins. I weighed custom ordering flows against maintenance cost and merchant fees, favoring flows the operator can run without a second full-time admin job. Revenue lift and error reduction are not claimed here; the product goal was honest operations first.

If traffic grows, the next gaps are capacity rules so large parties do not collide, tighter same-day service views, and clearer Square checkout where custom flows stop being worth the fee math. Deposits and no-show holds can wait until the café has a reason to care. I wrote a separate note on the design passes, because making operations work and making the site feel like the room turned out to be different problems.