- Built for
- A curated events business in Austin
- Role
- Product direction, design, build, and handoff
- System
- Cloudflare Workers, D1, Workers AI
- Where it stands
- Final demo and updated guides delivered September 3, 2026. Owner approval and the remaining setup steps come before use with real applicants.
The problem
My client runs a curated events business in Austin. He chooses who comes to each event, and every evening gives him more to remember about the people he has met. He needed a way to use that knowledge when planning the next one.
I connected the public application form to a private workspace where he can review the original answers and decide whom to invite. Each person’s record keeps their application separate from his own observations, so he can tell what someone said about themselves from what he learned by meeting them.
The host chooses every guest.
When he asked for help finding people for a particular kind of event, I built a copilot called Build a room. He describes the event and gets a draft to edit, along with people to consider and reasons for each suggestion. I added a check that drops a suggestion unless at least one supporting excerpt appears in that person's saved record. After he creates the event, he can add each person to Thinking about; inviting them is a separate decision.
How a guest record gets written.
I started capture with one text box, where he can write about someone in his own words and review a set of AI-generated tags before saving the record. Voice capture uses the same box. The original paragraph stays with the person, and he can edit every tag before saving, including the details that matter to him about what kind of event would suit them.
The host's note
Met Rosa at the gallery opening. Ceramicist, hosts a supper club of her own, big on live music. Wants people who actually talk. Do not seat her next to a monologuer.
Suggested tags
Reviewing the proposed guest list.
I built the Guest List Check to put a few easy-to-miss facts beside the list he is editing, including who is coming for the first time and who he knows only through an application. It also flags older records and any pair he has marked to keep apart. These checks update as he changes the group.
The room
- Imogen R.known
- Theo M.known
- Dev A.met once
- Sasha K.form-only
- Rosa V.met once
- Marcus L.form-only
Guest List Check
Keep apart: , a past clash he recorded
- 4 of 8 seats decided
- 2 first-timers, 2 returning
- 1 known only from an application
- 1 may be out of date: nothing new noted in over six months
A keep-apart warning names both people at the top of the check. I left the final decision with the host, who may know something the record has yet to capture.
Recording what happened after the event.
I brought event close forward in the build so he could record what happened at the first event, while he still remembered the conversations. He marks attendance and any pairs that hit it off or had friction, then saves a first impression of people he met that night.
Sasha K.
Met once- Attendance
- Came
- With Dev
- Hit it off
- First impression
- “Quieter than her form. Landed every question she asked.”
Saving a first impression changes a person's status from form-only to met once. The application is still there, alongside what he observed himself. At the next event, he can look back at those notes and see who has already met.
The build and the handoff.
- Jul 18v1, the roster
The first working roster, with people, notes, and tags.
- Jul 23The founder consultation
I changed the plan around one guest list per event and added the Guest List Check.
- Aug 13He tested it
His first session exposed a missing way to search the roster inside an event. I added Find someone and voice capture that day.
- Aug 17Guides and maintenance
I added the handoff guides, automated checks, and backup and alerting support.
- Aug 29Build a room
I added the event copilot he asked for, plus a Prep sheet assembled from his records.
- Sep 3Final demo
I updated the guides to match the finished demo and sent it to him for approval.
Between July 18 and September 3 the build took 95 commits, and it stands at 8,800 lines of JavaScript, HTML, and CSS over 12 tables and 4 migrations. It ships with 14 unit tests, 3 smoke suites, 18 documents running past 2,300 lines, and 2 Workers: one for the private workspace, one for the public form.
- Seven guides
- An owner's manual and quick start for everyday use, with an operations guide, AI fact sheets, known limitations, a demo-to-pilot checklist, and a privacy notice for applicants.
- Maintenance
- Weekly database export implemented; storage and credentials still need setup
- Public form limited to ten submissions per minute per IP address
- Error notifications available once an alert destination is configured
- Automated tests on every push and pull request
- Private workspace
- I separated the public application form from the host's workspace. The private API checks the host's signed access token on each request; the public API can read an open event and accept an application.