Tassel

Problem

I have shot graduation sessions for several years and have talked with other photographers who do the same work. The same three problems come up:

• Scheduling happens over direct messages, with no shared calendar. Double-booking and last-minute changes are common.
• Pricing is negotiated each time. Photographers have no reference for what similar sessions cost, and students cannot tell whether a quote is reasonable.
• Details like location, length and deliverables are agreed informally, with no record either side can check.

Underneath these is discovery. Photographers are spread across Instagram, personal sites and group chats. A student cannot see all their options, and a good photographer with a small network does not get found. Tassel starts with a shared directory, since scheduling and pricing structure depend on having one.

What exists now

Version 0 is a clickable prototype with no backend. Every screen runs on made-up data that is labeled as demo data: a feed of recent work, search and filters, photographer profiles, side-by-side comparison, booking requests, an inbox, messages and reviews. Its purpose is to test the flow with photographers and students before building the data model.

What comes next

1. Walk photographers and students through the prototype and note where the flow breaks.
2. Build version 1: accounts, booking, messaging and reviews, with event tracking from the start.
3. Pilot with a single graduating class.

The main measure of success is completed sessions per week during the booking window. Pricing suggestions wait until the pilot produces real booking data.