BoomYep Bakery

Businesses, addresses, documents, products, price variants and admins — with enums for type-safe categories and statuses.

RLS on every table, so each bakery owner can only ever access its own data.

A trigger derives each bakery's application status from the state of its uploaded documents. Status logic lives only in the database — never duplicated in application code — so the database and the UI cannot drift.

Each bakery receives payouts to its own connected account (85% of subtotal) — a legal requirement under Florida's Marketplace Facilitator Act, not just a design choice. The account.updated webhook keeps charge and payout readiness in sync.

All mutations return discriminated result types, so no unhandled error ever reaches the client.

Twilio Verify on bakery signup.

React Email templates for application submitted, approved, rejected, document re-submission and password reset.

Powered by Mapbox.

Supabase Storage for legal documents and product photos, with path-prefix policies that scope every file to its owning bakery.

One migration per logical change, applied and verified before each commit.

React Server Components by default; client components only where interactivity is actually needed.

Account creation, business info, document uploads and confirmation.

Per-document approve / reject that drives the status trigger.

Create, edit and delete products, dynamic price variants, photo upload, category grouping and visibility toggles.

Editable bakery settings and a dashboard that adapts to the application status.

For the business-facing side of the marketplace.

Status is computed by a trigger, never recomputed in JavaScript.

Following the Stripe convention, to avoid floating-point rounding errors.

Chosen for legal compliance and to keep the platform out of the money-custody path.

noUncheckedIndexedAccess catches undefined access at compile time.

Keeping validation and authorization on the server for every mutation.