Skip to content
SDX24
All work

Case study

Tandem

Childcare scheduling for families working shift work

A mobile web app that helps parents in the skilled trades coordinate childcare around changing shifts. This covers my full-stack ownership across the 16-week build: privacy-aware guest auth, typed real-time architecture, and the data models behind shared scheduling.

Role
Lead Full-Stack Developer
Timeline
Sep – Dec 2025 (16 weeks)
Team
3 developers, 5 designers

6–7 → 3–4

Steps in the core scheduling path

16 weeks

Concept to deployed product

8

People on the team

The problem

Tandem was built for parents in the skilled trades, who deal with early starts, overtime, and shift changes that land with little notice. Competitive analysis showed scheduling tools and childcare platforms exist separately, but nothing supported shared childcare coordination between families in one place.

Persona research confirmed the recurring pain points in shift-based households: sudden schedule changes, fragmented communication, and very little time to evaluate childcare options when plans break.

  • Users needed to plan childcare fast, around work schedules that move.
  • No single tool combined scheduling, childcare, and shared responsibility.
Tandem user persona showing behaviour, goals, frustrations, scenarios, and key tasks
Primary user persona. The persona used to define goals, behaviour patterns, and childcare pain points for shift-based families.
Tandem mobile dashboard showing a childcare schedule overview
Dashboard on mobile. Daily schedule context and childcare coordination in the shipped app.

What I owned

I owned guest access, the real-time collaboration layer, and the profile-linked sharing data models behind multi-user coordination.

Guest auth needed a full lifecycle (create, consume, clear) with cookies tuned for cross-origin iframe embedding: HttpOnly, Secure, SameSite=None. The Socket.IO layer uses centralized typed event contracts and room-scoped handlers rather than global broadcast, paired with persist-first messaging: save over HTTP before the WebSocket fanout, so a refresh or a dropped packet never costs state.

  • Cross-origin guest auth with hardened cookies and a complete session lifecycle.
  • Typed Socket.IO contracts enforced across every handler and hook.
  • Room-scoped channels, not global broadcast; persist-first messaging for durability.
Code for the Tandem guest auth route and its cookie configuration
Guest auth cookie lifecycle. The guest auth route: anonymous user creation plus the hardened cookie settings that make iframe embedding safe.
Code for typed Socket.IO room handlers covering share and direct message rooms
Typed room handlers. Socket handlers implementing typed event wiring and room-based join/leave for share channels and direct messages.
Database schema for the shared-care table
Shared-care schema. The coordination schema: timing, price, capacity, and JSONB members and messages for an active share.

The outcome

Consolidating scheduling and sharing into one flow cut the common scheduling path from roughly 6–7 interactions to 3–4 focused actions, which matters most exactly when a shift changes at short notice.

Shared availability and group status became readable at a glance, removing the need to switch between a separate calendar and chat for the core coordination loop.

  • Core scheduling reduced from ~6–7 steps to ~3–4 actions.
  • Availability and participation status unified into a single view.
  • No dependency on external calendar or chat tools for core coordination.
Tandem scheduling screen
Scheduling. The delivered scheduling view in the live app.
Tandem shared care screen
Shared care. Availability and participation status brought into one place.
Tandem dashboard screen
Dashboard. The final dashboard combining daily schedule context and coordination.

Stack

  • Next.js
  • React
  • TypeScript
  • Tailwind CSS
  • Drizzle ORM
  • Neon Postgres
  • Clerk Auth
  • Socket.IO
  • FullCalendar
  • IBM watsonx
  • Groq SDK

Team