Case 03Yara Health · Finland (remote)
Therapist booking automation
Open slot → booked session → Google Meet link in the calendar — with no human in the loop.
- Role
- Full-Stack Engineer & CTO
- Timeline
- Aug 2025 – Jan 2026 · 6 mos
- Status
- Delivered
- Stack
- TypeScriptNext.jsNode.jsGoogle Calendar APIPostgreSQLDocker
The problem
Yara Health matches therapists with clients remotely. Before automation, turning an open slot into a confirmed session was manual coordination — slow, error-prone, and embarrassing for a product whose whole promise is convenience.
Scheduling is deceptively hard: therapist availability lives in real calendars, clients book across timezones, and a double-booked therapist or a meeting link that never arrives destroys exactly the trust a health product needs.
Constraints
- 01
A small team and a six-month window — the architecture had to deliver product value immediately, not eventually.
- 02
Therapists' availability had to stay in tools they already use; asking them to maintain a second calendar was a non-starter.
- 03
Health-adjacent context: handle the minimum personal data necessary, and handle it carefully.
What I built
The end-to-end booking flow: clients see true availability, pick a slot, and receive a calendar invitation with a Google Meet link — generated automatically through the Google Calendar API.
The platform's product flows and backend logic around that core: accounts, therapist profiles, and the data model connecting them, in TypeScript end to end.
As CTO, the platform architecture and technical direction for the company — from schema design to deployment.
The hard decision
Google Calendar as the source of truth for availability
The classic design keeps availability in your own database and treats external calendars as a sync target. It gives you full control — and a permanent, unwinnable war against drift: every sync bug becomes a double-booking with a human on both ends.
We inverted the dependency: the therapist's Google Calendar is authoritative, the platform reads availability from it and writes bookings into it, and our database stores references rather than a competing copy of reality. That traded some query flexibility for a categorical guarantee — the platform cannot disagree with the calendar the therapist actually lives in.
Security & reliability
Data minimization: store what the booking needs, not what might someday be interesting.
OAuth scopes cut to the narrowest set that lets the integration work.
Calendar write operations built to be safely retryable — a network blip cannot create two events.
Clear separation between scheduling metadata and anything sensitive about the client relationship.
Results
- manual steps from open slot to Meet link
- 0
- months to a working, automated product
- 6
- countries between me and the team — shipped anyway
- 2
What I'd do differently
I'd budget more time for Google API quota and consent-screen review earlier in the project — external platform timelines are real dependencies, and we absorbed schedule risk that could have been planned away.