Should you build your own Zencal?

Build a personal replacement for Zencal in an empty repository.
Use Next.js 15, TypeScript, PostgreSQL, Drizzle ORM, Google Calendar OAuth, and Resend; do not offer alternative stacks.
The core loop is: read one calendar, publish booking pages with availability, collect optional payments, create conflict-safe bookings, and send confirmations and reminders.
Make the first run work locally with one documented command.
Store all user data locally by default and make export straightforward.
Put secrets in .env, ship .env.example, and never commit credentials.
Implement one account with configurable working hours, buffers, minimum notice, and booking horizon.
Connect Google Calendar using OAuth and store refresh tokens encrypted at rest.
Calculate availability in UTC and render it in the visitor's detected timezone.
Reserve slots transactionally, create calendar events, and prevent concurrent double booking.
Send confirmation, cancellation, and reminder email with signed management links.
Add an admin booking list, event-type editor, audit log, and calendar reconnect flow.
Include clear empty, loading, success, and recoverable error states.
Add input validation, safe filenames, and graceful handling of unavailable APIs.
Write focused tests for the core transformation and one end-to-end happy path.
Create a README with setup, architecture, permissions, data location, and backup steps.
Do not add accounts, billing, telemetry, analytics, or a hosted control plane.
Deliberately leave out Microsoft and Apple calendar support.
Deliberately leave out team round-robin routing.
Deliberately leave out payments, CRM workflows, and enterprise controls.
Finish by running the tests and listing the exact commands used.