Breez: multiple calendars, one view to share
My schedule lives across Google accounts for personal life, school, work, and projects. Apple Calendar brought them together for me, but sharing that combined schedule with my partner still meant separate subscriptions or a script copying events into another calendar.
Visit Breez (opens in a new tab)Personal, school and work calendars combine into one Shared View, with Busy time suggesting privacy controls. Fictional calendar content, not product UI.
I wanted one combined calendar she could view or subscribe to. That became Breez.
I owned the product, UX, technical direction, deployment, and acquisition. Codex agents implemented all the code; I steered the design, flows, animations, and high-level architecture.
Make the shared view the product
Breez connects Google, Outlook, and ICS calendars. A View combines selected calendars and lets each show Busy time, titles and times, or full details. The recipient gets one link to view the calendar or subscribe in their own calendar app. My partner successfully subscribed to mine.
Sharing is opt-in. Existing calendars start as Busy only in a new View, and calendars connected later stay out of existing Views until added. Users can disable sharing or refresh the link.
Keep the scope from drifting
The hardest part was staying focused. I explored manual and repeating blocks, plus a shorter calendar showing available and unavailable time. Each direction added complexity and clutter, so I pulled back to creating and sharing Views. Event editing stayed outside the core experience.
I was building from my own needs and comparisons with existing tools. I hadn't interviewed users, so those expansions were possibilities I imagined rather than needs I'd heard from customers.
Keep syncing from blocking the experience
Hourly refresh felt like a reasonable starting balance of freshness and cost. I also wanted an immediate sync when someone connected a calendar, so they could see it working.
But early linking was slow and error-prone: backend cold starts were exceeding request timeouts. I directed changes to extend the deadlines and start the first sync in the background, with visible progress and a retry path. Users could return to the calendar while events loaded.
I saw better latency and fewer errors during the second ad campaign, though I don't have a quantified comparison. That technical improvement didn't lead to additional observed View creation.
Learn from where people stopped
I launched the current version in late September 2026 and spent about $150 across LinkedIn and ChatGPT Ads. Over roughly two weeks, 16 people I didn't know signed up. Eight connected ten calendars; one created a View. These are early counts with approximate timing and uncertain channel attribution.
Breez solved my sharing problem, but few new users reached View creation. I suspect some didn't understand what a View was useful for. I didn't collect user feedback, so that remains a hypothesis; returning use also wasn't closely tracked.
My biggest lesson is to stay focused and let user feedback guide pivots. Next time, I'd spend more time understanding why people stop before chasing another hypothetical version of the product.