Situation
I founded the Bay Area Metal Detecting Association (opens in a new tab) in 2022 to connect detectorists, support lost-item recovery, and advocate for the hobby. Members were coordinating in a private Facebook group and email. That works until you need a real directory: who is nearby, who can help recover a ring, who should get meeting invitations.
Constraint
This is a volunteer community. There are no member dues. The product had to be cheap to run, simple to maintain, and respectful of privacy. It also had to be a place I could practice the same AI-native, specification-driven loop I use at work—on a system I fully own.
Decision
I built a server-first Next.js membership directory rather than bolting another plugin onto WordPress.
- Specify the membership object (profile, location, recovery availability, communications) before drawing screens.
- Use AI-assisted implementation in Cursor against that spec, then review the result as a product owner—not as a tourist in the codebase.
- Keep the public association site for story and recovery intake; put operational membership in an app designed for it.
The public face of the community remains bayareadetecting.com (opens in a new tab). The directory is the operational product behind it.
Outcome
- A working, AI-native membership management app in the same stack this portfolio uses.
- A community that still does the human work: lost-item recovery, beach and park cleanup, and in-person meetings.
- A portable proof point for hiring managers: I will specify the system, prototype it, and ship it.
What I would do again
Pick a real user (a detectorist with a lost-ring call at dusk) and design the directory around that job to be done—not around an admin CRUD template.
What I would change
I would publish a public changelog and anonymized metrics (members helped, recoveries referred) so the product’s value is as visible as the origin story.