How it's being built
The first one that needs a real database.
My other tools live on your own device. This one can't — a shared supplier directory only works if it's, well, shared. So I'm planning it carefully and in the open: the data model, who can see what, and a demo you can click, all before the app itself.
Step 1 · Plan the database before the app
A multi-tenant app lives or dies on its data model. So the first ask wasn't "build it" — it was "design it, and let me read it first": the tables, the search index, and the exact rules for who can see and edit what.
Before any app code, propose the Postgres schema and row-level-security policies for a multi-tenant supplier database. Photographers see only their own events; approved suppliers are shared across everyone; you can only edit the ones you created. Add a trigram index for typeahead.
Wrote three ordered migrations: the schema (with a pg_trgm index on business_name for the typeahead), RLS that isolates each photographer's events and settings while sharing the approved supplier pool, and a note that seed rows stay read-only to everyone but the service role. Left it all for review before touching the app.
Step 2 · Let couples in without a login
Couples shouldn't need an account to fill in a form. But I also didn't want to weaken the security to let them in. The answer was to give each wedding an unguessable link, and let that link — and nothing else — reach the database, through a few tightly scoped functions.
Couples have no login — just a secret token in their form link. Let them read their event, search suppliers for the typeahead, and submit, without opening up the tables to anonymous users.
Added three SECURITY DEFINER functions keyed on the form token: one to load the event, one to run the typeahead (honouring the photographer's 'only my country / only my suppliers' toggles), and one to submit — which locks the form and queues any brand-new suppliers for moderation. The tables stay closed to anonymous access; the token is the only key.
Step 3 · Make the idea clickable first
A schema is hard to have an opinion about. A form you can type into isn't. So before the backend goes live, I built the couple's form as a browser-only demo on sample suppliers — the real feel, and the very same code that turns their answers into the six copy outputs.
Build the couple's supplier form as a front-end demo on sample Scottish suppliers, with typeahead auto-fill. On submit, generate the six outputs: website links, an email list, Instagram handles for Stories, role-and-handle lines for posts, a hyperlinked HTML blog credit block, and a CSV.
Built the form with a fuzzy typeahead over sample suppliers, add/remove rows, and a photographer row pre-filled. Submitting shows all six outputs with copy buttons and a CSV download, plus a preview of what would land in the Pending queue. The output generators are pure functions, so Phase 1 reuses them on the real event page unchanged.
Reading the plan yourself
The full proposal — file structure, schema, the privacy and GDPR position, and the decisions still to make — lives in the repo under docs/supplier-app/, with the database itself under supabase/.
The build log
Where it's up to.
Every step, newest first. Tap an entry to read the thinking behind it.
ProposalThe foundation, up for reviewBefore any backend code, the reviewable bones: the full Supabase schema, the row-level-security policies, the tokenised couple-form functions, and a seeding plan — plus a browser demo of the couple's form so the idea is something you can actually click.
The plan asks for the file structure, schema SQL and RLS to be proposed before the real app is built. So this drop is exactly that: three ordered Postgres migrations (tables + pg_trgm typeahead index, RLS for tenant isolation and the shared pool, and the SECURITY DEFINER functions that let couples fill the form with no login), a seeding strategy that starts from my own existing suppliers, and a proposal doc pulling it together. Alongside it, a front-end preview of the couple's supplier form: type a business name, watch it auto-fill from a sample Scottish directory, submit, and get the six copy outputs back — website links, an email list, Instagram handles for Stories, role-and-handle lines for the grid, a hyperlinked HTML blog credit block, and a CSV. No database yet, on purpose. The demo's output code is the same code Phase 1 will reuse.
Want to be one of the first in?
I'm gathering a small founding group of UK photographers to shape this and use it free while the directory grows.