Home / The City Table

Hustle #006 / The City Table

The City Table: eight steps, one build.

A table-planning app with guest rules and seating history. The app is public; encrypted save/reload and two-account database isolation have been tested. Public-signup email and privacy work remain.

What we did

01 / Choose one customer

2 October

Plan a dinner without starting the seating from scratch.

  • The founder asked for a table-plan maker. She wanted to upload guests and say who should not sit together.
  • The founder required seating history. The app should remember earlier neighbours so the next plan can avoid repeating them.
  • The founder required flexible tables. The plan needs different table shapes and sizes rather than one fixed layout.
02 / Check the idea and the costs

2-3 October

Check the planner and the storage route.

  • The agent scoped the seating tools. Guest lists, rules, dinner history and table layouts became distinct parts of the prototype.
  • The agent chose account-backed storage on Supabase. The database needed signed-in ownership rules before any real guest data could be accepted.
  • The agent kept hosting free for the prototype. Cloudflare Pages hosts the app; no pricing or billing has been launched.
03 / Give it a name and a home

3 October

Give the app its own name and home.

  • The founder chose The City Table. The agent prepared the app under that name.
  • The founder approved public hosting. The agent deployed the app on Cloudflare Pages and connected thecitytable.co.uk.
  • The agent kept the public face simple. The app and account route are available without a paid-plan or customer claim.
04 / Make one thing people can buy

3 October

Build and test the planner before charging.

  • The agent built the guest, rule and dinner screens. The planner supports guest tools alongside the visual table layout.
  • The agent added encrypted sync. A signed-in user can save and reload a workspace using a passphrase; the server stores ciphertext.
  • The agent left the paid offer unfinished. There is no live checkout, settled price or claim of sales.
05 / Put it in front of real people

3 October

Put a real app in front of the founder.

  • The agent delivered a private preview first. The founder could review the planner before a public deploy.
  • The agent found the preview's network limit. The hosted preview blocked external calls, so real sign-in testing needed normal web hosting.
  • The agent deployed the public app after approval. The Cloudflare Pages route made real backend testing possible.
06 / Learn from the first response

3 October

Fix the phone layout and prove the boundaries.

  • The founder flagged the mobile layout. She said the app looked better but was not mobile friendly.
  • The agent fixed phone, tablet and desktop layouts. It checked the welcome screen, plan, guests, rules, dinners and account menu without horizontal overflow.
  • The agent tested a fresh-session reload. The encrypted saved data came back unchanged; a wrong passphrase was rejected.
07 / Hand over one repeatable job

3 October

Make saved work safe to repeat.

  • The founder ran the database isolation test. The result confirmed a second user could not read, write or delete the first user's rows.
  • The agent tested two real confirmed accounts. The second account could create its own workspace but could not read or change the first account's workspace or snapshots.
  • The agent erased the test workspaces. Both accounts were left with no saved test guests or snapshots.
08 / Improve it, change it or stop

3 October

Keep the public-signup limit visible.

  • The agent found email-sender limits. Supabase's built-in sender was rate-limited; reliable public signups need a proper email route.
  • The agent found a confirmation-link problem. A test link expired before confirmation; the next email flow needs protection against links being consumed by mail checks.
  • The agent kept privacy and signup work open. A tested prototype is not a finished customer launch. Email delivery and privacy checks come before real guest data.
3 October 2026

Today's update

  • The public planner and account-backed encrypted sync are built.
  • Save/reload, wrong-passphrase rejection and two-real-account isolation passed overnight.
  • The agent erased the fictional guest test data after the checks.
The build lesson

Biggest learning

  • Testing the database is separate from testing a usable signup route.
  • A preview can hide network limits; a real hosted app is needed for a full account round trip.
The next test

Next step

  • Set up a reliable signup-email route and handle single-use confirmation links safely.
  • Finish the privacy review before inviting customers to save real guest data.

Use the build checklist for your own idea