I Let Cursor Be My CTO

Show Notes

Parker walks through the Day-in-the-Life of building Map, an AI-powered all-in-one platform, and shares practical takeaways from shipping, learning to code, and stitching together a Google Calendar integration. Lots of concrete architecture tips, learning strategies, and a peek under the hood of a solo startup build.

Day in the Life and Map concept

• Map is an all-in-one platform centered on your “future self” AI model.
• It combines calendar, notes, tasks, and project management, all tied to your goals and daily actions.
• The experience is designed to feel natural and not like a separate “coaching” tool—more like an extension of you.

Why build your own backend instead of relying on every SaaS service

• Cost awareness: early serverless bills with low adoption can bankrupt momentum.
• Shift from frontend-first to owning the stack: provisioning servers (e.g., VPS, Docker) is approachable and scalable with the right patterns.
• The lesson: don’t chase every flashy service—learn the core tooling and keep surface area manageable for longevity.

Tech choices and rationale

• Stack basics: Next.js + TypeScript; client-heavy front end with a service layer.
• Backend approach: self-hosted/managed VPS (Digital Ocean) and Docker, with a pay-as-you-go mindset.
• Services-to-learn vs. using: use robust, well-documented tools (Supabase for auth/Postgres, etc.) but stay mindful of version drift and surface-area risk.
• Deployment pattern: containers (Docker) + a lightweight deployment tool (referenced as a tool like “CommAll” in the video) to run apps anywhere, cheaply.

Google Calendar adapter: architecture and data flow

• Goal: a unified adapter that covers all Google Calendar resources, with a clean client, token handling, and a robust sync path.
• Resources covered (example): ACL (Access Control List), events, channels (watchers/updates), colors, calendar lists, calendars, freeBusy, settings.
• Flow highlights:
  • First sign-up: determine token presence, prompt for calendar setup, then start syncing.
  • Token management: store/refresh tokens securely; handle auth lifecycle.
  • Remote RPC: use Supabase to run a syncCalendar RPC that pulls large data sets quickly ( serialized in TypeScript on the server, then persisted).
  • Watchers: to stay in sync with changes in Google Calendar (and reflect them in Map immediately).
• Data strategy: pull and store up to 36 months of calendar data on day one for two reasons:
  • Backfill the user’s historical context.
  • Create a dataset to train the future-self model (privacy-by-design, encryption, anonymization).

Code and patterns:

• Adapter pattern: a GoogleCalendarAdapter interfaces with a common CalendarAdapter, so you can swap/extend to other services with minimal disruption.
• Token and provider abstractions: a provider/token manager handles OAuth tokens and retries.
• Resource-specific methods: each resource has its own method for fetch/serialize/observe, organized by resource type.

Sample pattern (illustrative, not exhaustive):

// Adapter interface for calendar services
export interface CalendarAdapter {
  authorize(): Promise<void>;
  refreshToken(): Promise<void>;
  listEvents(params: ListEventsParams): Promise<CalendarEvent[]>;
  createEvent(event: CalendarEventInput): Promise<CalendarEvent>;
  // ... other resource operations (ACL, colors, calendars, freeBusy, settings, etc.)
}

// Example adapter implementation
class GoogleCalendarAdapter implements CalendarAdapter {
  // authorization, token management, and per-resource methods
  async authorize() { /* ... */ }
  async refreshToken() { /* ... */ }
  async listEvents(params: ListEventsParams): Promise<CalendarEvent[]> { /* ... */ }
  async createEvent(event: CalendarEventInput): Promise<CalendarEvent> { /* ... */ }
}

• Server actions and RPCs: serialize data on the server, then sync via RPC calls to persist to the database (Supabase).
• Sync performance: the architecture is designed to scale with more data and additional calendar sources while keeping a single, coherent interface.

Data, privacy, and compliance

• All health and calendar data are treated with strong privacy controls (HP-compliant, encrypted, anonymized).
• The idea is to train a future-self model on a large, but privacy-preserving, data footprint to tailor daily guidance without exposing raw data.

Multi-layer calendar and activity-centric UX

• Bare calendar basics are complemented with:
  • Activity layers: differentiate types of time (work, workouts, family time, etc.) for better decision-making.
  • Separate calendars for activities (e.g., workouts) and data streams (whoop health data, sleep, heart rate).
  • A “video game” feel: strive for an engaging, motivating calendar rather than a sterile log of events.
• Tasks and notes live in the same space, enabling context-rich planning and execution.

AI-assisted learning and productivity workflow

• Use AI as a tutor, not a replacement:
  • Ask clarifying questions, request pros/cons, see alternative approaches.
  • Read the outputs critically—LLMs can hallucinate or misinterpret numbers; verify with your own review.
• Learning techniques the creator uses:
  • v0/Cursor as a targeted, framework-specific AI assistant for code explanations, examples, and concrete guidance.
  • Treat prompts as an ongoing dialogue, refining queries to fit your project context.
  • Use “explain like I’m your friend” prompts to surface rationale and internal decisions.
• Practical prompts and uses:
  • Explain Redux vs. context in your project’s terms and show concrete code examples.
  • Break down complex goals into next actions with specific verbs (e.g., “Create a migration to move settings into a new calendarSettings object”).
  • Compare alternative architectures or approaches (pros/cons) given your current stack and constraints.

Tips for improving your own learning flow:

• Add context through comments: document why a file or function exists to help the LLM reason correctly and avoid redoing context.
• Use network inspection during development to understand API calls, responses, and timing.
• Treat LLMs as mentors at different levels; push for deeper explanations, not just code snippets.

Core development workflow and patterns

• Keep UI logic and data logic separated; for example, separate calendar visibility state from calendar data state.
• Use a reusable, typed API layer for queries and mutations with retry and logging (built around Supabase in Parker’s setup).
• Server Actions for complex operations: move heavy logic to server-side, keep client lean.
• Watchers for real-time sync: ensure changes in Google Calendar propagate to Map in near real-time.
• Comments as a productivity booster: use a standardized approach to annotate files with rationale and usage notes.

Daily productivity accelerators Parker uses

• Raycast floating window to capture a quick “end-of-session memory” entry, reducing time-to-productivity next day.
• End-of-session memory: note the last thing done to quickly pick up where you left off.

Final thoughts and next steps

• This is a real-world, hands-on build in progress, not a polished demo. The focus is on actionable patterns, tradeoffs, and learning strategies.
• If you have questions or want deeper dives into specific parts (adapter patterns, server actions, or AI tutor prompts), drop a comment.
• Like and subscribe if you want ongoing updates on Map, the tech choices, and the evolving AI-powered workflow.

Links

• Morphic (open-source project) — a project referenced for how perplexity-like features can be implemented.
• Getting Things Done by David Allen — productivity framework referenced for next-action design.
• Google Calendar API resources (ACL, events, channels, colors, calendars, freeBusy, settings) — conceptual anchors for the calendar adapter.
• Peter Levels — referenced as a benchmark in indie-startup tooling and growth.
• Cursor (IDE / coding assistant) — tool highlighted for learning and debugging.
• McKay Wrigley — advocate for adding comments as a workflow booster; related prompts and approaches.
• Supabase — backend service used for auth, Postgres, and RPCs in the architecture.
• Whoop data integration (health data) — an example of live data ingestion for the health layer.
• Raycast — productivity surface used to capture daily actions and memory.

Note: If you want, I can tailor the show notes with more direct quotes from the transcript or reformat a specific section to align with Parker’s preferred cadence.