Mini Pancake Co.

Overview

Mini Pancake Co. is a small mini pancake business in Mazatlán, Mexico. v1 was a 5-page vanilla HTML/Bootstrap college site — pretty, static, useless for the actual business. v2 is a full React single-page application: product catalog with cart, WhatsApp-integrated checkout, a 5-step event booking wizard for parties, and an admin dashboard. Two real revenue streams (retail orders + party packages) running off one codebase.

The brief

Pivot 01 — Architecture

A 5-page static HTML site with no commerce, no booking, no admin. Adding a product meant editing HTML directly. Every order happened over WhatsApp manually because the site couldn't capture them.

Options I considered

• A

  Layer Bootstrap modals onto the static site for cart UX

  Postpones the rebuild, doesn't solve persistence or admin. Buys weeks, costs months.

• B

  Use a SaaS like Shopify with a custom theme

  Solves commerce instantly but locks the owner into monthly fees and removes the WhatsApp workflow entirely.

• Rebuild as a React SPA with Context + localStorage, deploy via GitHub PagesChosen

  Most code to write upfront, but full control over both flows, no recurring cost, and the data layer stays swappable for a real API later.

What I shipped & why

React 18 + Vite + Tailwind + Framer Motion, HashRouter for GitHub Pages compatibility, Context for cart and bookings, localStorage as the persistence layer. The architecture decision is to keep the data layer abstracted — a single context module — so swapping to a real backend later is a one-file change, not a rewrite.

Pivot 02 — Checkout

Built a clean React product grid, search, sort, detail modal with topping picker, and cart. Wired it up to a generic checkout form. The owner pushed back: customers don't use forms here, they WhatsApp. The cart was a dead end.

Options I considered

• A

  Stripe Checkout — proper card payments

  Adds a payment processor fee, requires KYC, breaks the WhatsApp habit customers already trust. Solves a problem nobody had.

• B

  Email order to the owner via EmailJS

  Owner doesn't check email in the workflow loop — orders would land in a channel she's not in. Same dead-end as the form.

• WhatsApp deep link with a pre-filled order message (items, toppings, quantities, total)Chosen

  No card payments captured digitally — but matches the existing trusted channel exactly. The cart becomes an order builder, not a payment form.

What I shipped & why

Replaced the form with a single CTA that opens WhatsApp with a pre-formatted message. One tap, customer lands in the chat they already trust, owner's workflow is preserved, and the cart logic still produces a clean structured order. The site becomes a storefront and an order builder — the channel stays where it already worked.

Pivot 03 — Admin

The shop covered retail. Party bookings — the higher-revenue flow — still went through DMs with no structure. The owner had no view of pending vs confirmed bookings. The site was half a product.

Options I considered

• A

  Push bookings into a Notion database via API

  Owner now has to learn Notion. Adds a third tool to the stack. Free, but introduces friction in the daily workflow.

• B

  Auto-generate a Google Sheet from each submission

  Solves capture but not management — owner can see bookings, can't actually confirm/cancel/track from the spreadsheet without manual edits.

• Build a password-gated admin dashboard inside the same React app, persisting to localStorageChosen

  Bookings live in the device that opened the dashboard — but for a single-owner business, that's the right tradeoff. Full CRUD, no extra tools, same brand.

What I shipped & why

Built the 5-step booking wizard (Package → Date+Time with 7-day-min → Event details → Contact → Review) and the admin at /#/admin: stat tiles for total/pending/confirmed/revenue, full bookings table with confirm/cancel/delete, and packages overview. Same component library as the public site — every admin screen still feels on-brand.

The stack

Each tool earned its place. Here's why.

Outcome

Shipped a deployed production e-commerce + booking app with two real revenue flows running off one codebase: a product catalog with cart and WhatsApp checkout, a 5-step party booking wizard, and a 3-tab admin dashboard. Built on React 18 + Vite + Tailwind + Framer Motion, deployed via GitHub Actions to GitHub Pages. The original 5-page static site rebuilt into something the owner could actually run two streams of her business through.

What I learned

1. 01

   Build with the channel, not against it. WhatsApp checkout sounds unconventional but matches how customers actually buy — and the result is higher conversion than forcing a card form into a small-business context.

2. 02

   Two flows, one design system. Encoding the brand into Tailwind tokens once let the e-commerce, the booking wizard, and the admin all stay visually consistent without re-deciding anything per screen.

3. 03

   A site without an admin is just a brochure. The moment a small business has any real volume, the dashboard is what turns the site into a tool they can actually run revenue through.