DEV Community

Supabase fitness app

Claude Code 58 messages April 07, 2026
by alexdavies74
Supabase fitness app claude-sonnet-4-6
You

We are going to use supabase. Here is an empty one:
Project URL: https://hoklofabqiyduvsbvgcv.supabase.co
Publishable key: sb_publishable_PUQSgl2xEKAH1XQfB27jLg_u58UcUff

Start by installing the packages, then start from the core README and enter planning mode.

I'd like you to plan, and then build, a complete, usable, fitness studio booking web app.

The first user will create and manage a Studio, which has a class schedule. Keep it simple, offer inputs for start and end time for each class, participant limit, with a button to make a new class. No weekly repetition. They should be able to copy a link to provide to their customers.

When others scan and follow the link, after logging in, they enter the booking experience. This is a very simple text-based experience, listing the available classes. Each class has a book button, which immediately reserves a slot in that class for the logged-in user. Other customers should (within a few seconds) see the slots are taken. This should work even if the original owner's client is not online.

Security model: Only the original owner should be able to see everything. Each customer should be able to create/cancel their own bookings, and see the presence of other customers' bookings, but NOT see the identity of the booker, or any other private details of the booking. This security should be robust to customers who can modify their own client code. You are responsible for this security, and if you need my help, you must ask for it.

Interaction model: All create/write actions in the UI should feel instant, using optimistic updates. If the owner is looking at a class when someone books, they should be able to see that the class got a new signup, within several seconds.

You may ask me about problems with your tooling. Avoid other questions, we are practicing to one-shot this task.

Do not explore my file system outside the current directory.

Don't write a custom backend!

Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent
Agent

Now let's verify it builds cleanly:

Agent
Agent

The Database generic type is conflicting with supabase-js v2. Simplest fix — drop the generic and keep local types for state.

Agent
Agent

Also fix unused imports:

Agent
Agent
Agent
Agent

Clean. Now let's do a full Vite build to confirm:

Agent
Agent
Agent

Build is clean. Here's what to do next:


One required step before running: apply the database schema

  1. Open your Supabase dashboard → SQL Editor
  2. Paste and run the contents of schema.sql

That creates the 3 tables, triggers (capacity enforcement + booked_count sync), RLS policies, and enables realtime.


Then run the app

npm run dev

What's been built

Owner flow (/)
- Sign up → name your studio → get the management dashboard
- Add classes: name, start/end datetime, max participants
- Copy the customer booking link with one click
- See live booked_count and a "New signup!" flash when someone books (realtime, no page refresh needed)

Customer flow (/studio/:id)
- Follow the link → sign in/up → see the class list
- Book instantly with optimistic UI (UI updates before the server confirms)
- Cancel your own booking the same way
- Live spot counts update in real time as others book

Security
- RLS on all tables — customers can only read/write their own bookings rows, enforced at the Postgres level, not just in app code
- booked_count is a plain integer on the classes table (public) — customers see how many spots are taken without any booker identity leaking
- Capacity enforcement is a BEFORE INSERT trigger with FOR UPDATE row-locking — concurrent bookings are serialized safely at the DB level

You

<local-command-caveat>Caveat: The messages below were generated by the user while running local commands. DO NOT respond to these messages or otherwise consider them in your response unless the user explicitly asks you to.</local-command-caveat>

You

<command-name>/context</command-name>
<command-message>context</command-message>
<command-args></command-args>

You

<ide_selection>The user selected the lines 95 to 95 from [REDACTED]/code/experiment supabase 1/schema.sql:
studios_select

This may or may not be related to the current task.</ide_selection>

Now you've had experience working with Supabase, I'd like to get your evaluation of the platform in comparison to other options you know. Where did it cause friction?

Focus on the things that slowed you down or wasted tokens, as well as things that contributed to bugs. You may also share what was a positive surprise about the experience.

Keep it brief and don't describe solutions.

Agent

Friction points:

  • Generic typing trap. The createClient<Database> generic looks like it should help, but the internal shape the library expects for Database is undocumented and strict. My hand-rolled type caused never errors on every insert — wasted tokens writing it, debugging it, then abandoning it entirely for any.

  • RLS policy verbosity. One policy per (table × operation) means ~15 SQL statements for 3 tables. There's no "owner can do all" shorthand. Easy to miss a case, and the error surface is invisible until runtime.

  • Realtime filter strings. filter: 'studio_id=eq.${id}' is an untyped, un-validated string. Typos fail silently at subscription time, not at compile time.

  • auth.users is a walled garden. You can't join it from client-side queries. Needing a profiles table just to show a customer's email to the owner is friction that surprised me mid-design.

Positive surprise:

The SECURITY DEFINER trigger pattern for capacity enforcement worked exactly as I hoped — the database atomically enforces the invariant regardless of client behavior, with no extra API needed. That's a genuinely good fit for the "no custom backend" constraint. The trigger + RLS combination let me push real security guarantees into the DB layer cleanly.

You

Give a two-sentence summary evaluation: would you want to use Supabase again?

Agent

Yes — for a project like this (auth + Postgres + realtime, no custom backend), Supabase genuinely delivers on its promise and the trigger/RLS model is powerful once you accept the verbosity. The TypeScript experience is rough enough that I'd budget time for fighting the type system, and I'd reach for it more confidently in a dynamically-typed project or one where generated types from the CLI are part of the workflow.