Calmo Cafe — a reservation flow that skips the early SaaS bill

Overview

A friend of mine is leaving blue-collar work to open a brunch café in Toronto. He’s an immigrant bootstrapping wherever he can, and the default path — OpenTable, listing products, an agency site — gets expensive before the business has proven itself. That risk isn’t abstract: across Canada, restaurant closures have been climbing again after the post-pandemic rebound — on the order of ~7,000 closures in a recent year, with forecasts pointing to thousands more through 2026 — and independents on main streets take the hit hardest. Toronto’s café and brunch scene is already crowded, with well over a thousand cafés in the city, and Toronto alone accounting for roughly a third of Ontario’s brunch restaurants. Opening into that is a real bet, not a lifestyle project. I told him I’d 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 brief I gave myself was whether I could cover what he actually needs at roughly $0, without locking him into a reservation SaaS before the café has earned the right to pay for one.

The problem

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.

Approach

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.

What I built

For guests: a branded landing (hero, about, menu, gallery), a request-a-table flow, a success state, tokenized manage / modify / cancel links, and a calendar file once confirmed. For the operator: PIN admin, inbox and schedule views, confirm / cancel / complete / no-show, and a light audit trail so actions aren’t a black box. Under the hood: Next.js, Supabase, Resend, Zod, Vercel. Statuses that match how a small room actually runs — pending → confirmed → cancelled (guest or restaurant) / completed / no-show.

What I learned

What's next

If he opens and this gets real traffic, the next gaps are obvious: capacity so two big parties can’t collide, maybe SMS, and a tighter “today” view for service. Deposits and no-show holds can wait until the café has a reason to care. I’m less interested in turning this into a startup than in keeping it useful for him, and honest about when $0 stops being enough.

Tech stack

• NNext.js
• RReact
• TTailwind
• SSupabase
• RResend
• ZZod
• VVercel
• CCursor