Back to work
Technical Leadership · AILive · Public

CalendarPA + AdaPA

A scheduling SaaS built solo from zero to paying users in seven days.

Summary

CalendarPA is a multi-provider scheduling platform with an AI assistant, AdaPA, that books meetings over web, SMS, email, and MMS. I built it solo — product, architecture, security, launch, and go-to-market — from nothing to 50 paying subscribers with zero downtime.

The Problem

Real scheduling spans Google, Microsoft, and Apple calendars, payments, and constraints ordinary tools cannot express. Doing it reliably means solving double-booking, encrypting sensitive availability, and keeping background sync correct under load — without a team.

Approach

  • Shipped a public beta in 7 days, removed the allowlist 10 days later, and hardened the risky paths before expanding surface area.
  • Built durable event-driven background work on Inngest so sync and notifications survive failures and retries.
  • Added an AI assistant (AdaPA) that turns plain requests into structured, reviewable scheduling actions.
  • Wrote over 10,000 unit tests completing in under 30 seconds, with continuous integration and gated production security mitigations.

Architecture

  1. 01Next.js 16 + TypeScript frontend on Vercel.
  2. 02PostgreSQL (Neon serverless) via Prisma for the data model.
  3. 03Inngest for durable, event-driven background work (sync, reminders, retries).
  4. 04Redis (Upstash) distributed locks to prevent double-booking under concurrency.
  5. 05AES-256-GCM encryption for sensitive availability data at rest.
  6. 06AdaPA assistant on a LangGraph state machine with Google Gemini tool calling and pgvector RAG memory in Neon, reachable via web chat, Twilio (SMS/MMS), and Resend (email).

Key Tradeoffs

Inngest over a hand-rolled queue

Durable, observable background jobs in days, not weeks — a seven-day beta could not afford bespoke queue infrastructure.

Distributed Redis locks for booking

Calendar writes race under concurrency; a lock on the critical section was simpler and safer than optimistic retries for money-on-the-line bookings.

Encrypt availability at rest

Availability is sensitive personal data; AES-256-GCM was the cheap, correct default rather than a later retrofit.

Stack

Next.js 16TypeScriptPostgreSQL/NeonPrismaInngestUpstash RedisStripe/Square/PayPal/STAXLangGraphGeminiTwilioResend

Outcome

50 paying subscribers within 45 days, zero ad spend, zero downtime, zero double-bookings — proof I can own product, architecture, security, and launch end to end.