Skip to content
Back to systems
Becca’s Bubble

The pitch, built rather than described

Becca’s Bubble

Retail Storefront & Booking Prototype

A shop, a class-booking surface and a full admin back office for a candles and breathwork studio — built as a clickable prototype so a prospective client could walk through the experience instead of reading a proposal about it.

Pitch prototype · for a prospective client, not an engagement

The Becca’s Bubble library on a laptop — guided video, book and lesson courses above a row of candles.
Type
Pitch prototype, in-house
Surface
Vue 3 SPA, three audiences
Data
Mock data, no backend
Scale
~5.4k lines · 10 admin views

The system

What it does

Most agencies answer a brief with a deck: some positioning, a moodboard, a rough sitemap, and a number. It is cheap to produce and almost impossible to react to, because nobody can tell from a slide how a thing will feel to use.

This is the other approach. The brief was a candles maker who also runs breathwork sessions — two businesses sharing one audience — so the pitch was built as something to click through: a storefront for the candles, a booking surface for the sessions, a member area for people who have paid, and the admin back office that runs all three. Ten admin views with working editors, because "we will handle the admin side" is exactly the promise a deck cannot make credible.

It is deliberately hollow underneath. No backend, no accounts, no real checkout — the data is mocked and the cart lives in the browser. Every hour spent on infrastructure at this stage is an hour spent before anyone has agreed what is being built, and the point was to settle the experience while it was still cheap to change.

Who uses it

Shopper

Browses candles, sessions and the library, and builds a cart that survives a page reload.

Member

A separate signed-in area for people who have booked — their courses, their sessions, their orders.

Owner

The back office: orders, products, sessions, library content and members, each with its own editor.

Features

What was built

Everything listed is in the repository — not a roadmap.

  • 01

    Three audiences, one prototype

    Public storefront, member area and admin back office all built out — so the walkthrough covers the whole business rather than just the part a customer sees.

  • 02

    A back office that actually opens

    Ten admin views with working create and edit screens for products, sessions, library content and members — not a screenshot of a dashboard.

  • 03

    Cart that survives a reload

    Line items, quantities and an AUD total held in a store that persists to the browser, so a demo can be interrupted and picked back up.

  • 04

    Two businesses, one audience

    Candles and breathwork sessions modelled side by side rather than as separate sites, which was the actual question the brief posed.

  • 05

    Brand system, not a colour scheme

    The identity — lotus mark, six-colour palette, surface tints — expressed as design tokens mirrored into utilities, so the look is consistent by construction rather than by discipline.

  • 06

    Deployable as static files

    Hash routing and a pure client build, so the prototype can be put on static hosting and sent as a link rather than scheduled as a screen-share.

  • 07

    A course library that plays

    Courses hold modules, modules hold lessons, and a lesson is video, PDF or reading with its own duration. The player resumes at the first thing not finished and marking one complete moves the count — the learning side is a working surface, not a catalogue page.

  • 08

    Orders through to fulfilment

    An order carries a customer, an item, an AUD total and a status that moves Paid to Packing to Shipped to Delivered, with Refunded off to one side. The back office filters on it and advances it, so the shop is modelled past the checkout rather than stopping at it.

  • 09

    Sessions as bookable things

    Breathwork sessions are scheduled items with spots against them, bookable from the front and editable from the back — the same object seen from both ends rather than a calendar image.

  • 10

    Member records on both sides

    A member has a detail view in the back office and a dashboard of their own, so what the studio sees and what the person sees are two views of one record.

Beyond the prototype

What a real build adds

Deliberately out of scope for the prototype

The prototype answers what the experience should be. Everything below is what it would take to make it real, and all of it was consciously left out — a pitch that spends a fortnight on authentication has spent it before anyone agreed to the work.

  • Accounts and sessions

    Real sign-in for members and staff, with the admin surface behind an actual permission check rather than an unguarded route.

  • Checkout and payments

    A payment provider, order records that outlive the browser, and receipts — the point where a cart becomes revenue.

  • Real bookings

    Session capacity, waitlists and cancellations, which are the parts of a class business that actually generate admin work.

  • Stock that counts down

    Inventory tied to orders, so a handmade run of forty candles cannot sell fifty.

  • Nuxt
  • Node.js
  • Fastify
  • Supabase
  • Fly.io
  • Redis

Designed to run on: Nuxt, Node.js, Fastify, Supabase, Fly.io, Redis.

Interface

The parts worth looking at

Plate 01

The storefront

The shop as a customer meets it — candles priced, described and addable to a cart, which is where the brand does most of its work.

The storefront
Plate 02

Sessions to book

The breathwork side listed and filterable, each session carrying what it is and when it runs before anyone commits to it.

Sessions to book
Plate 03

The member area

What someone sees once they have booked: the session itself, what to expect, what to bring, and the way in when it starts.

The member area
Plate 04

Admin back office

Revenue, upcoming events and recent orders on one overview — the half of the pitch a deck cannot show.

Admin back office
Plate 05

Members, and what they are worth

Every member with their bookings, orders and lifetime spend in one table, so the studio side is a record rather than a mailing list.

Members, and what they are worth

Stack

What it was built with

Dependencies actually in use, not everything in package.json.

  • Vue
  • TypeScript
  • Tailwind CSS

Framework

  • Vue 3
  • TypeScript (strict)
  • Vite
  • Vue Router

State

  • Pinia
  • Persisted state

Interface

  • Tailwind CSS v4
  • Reka UI
  • Design tokens
  • Lucide

Hosting

  • Static hosting
See the other systems

Software Is Never Really “Done.” Neither Are We.

Let’s talk about how your business runs today, what a tailor-fit system could look like, and what it means to have a technology partner who doesn’t disappear after launch. Just need to hire a developer or a BI analyst? That conversation is just as welcome — and stands entirely on its own.

Two routes, one form. Say which one fits and we will reply to arrange a short discovery call — no pitch deck, no obligation.

Tell us what you need

I need

Goes straight to the founding team. No autoresponder, no sales sequence.