Tandem
Full-stack web being built in production-ready, AI-assisted platforms with Next.js, TypeScript, PostgreSQL, and serverless cloud deployments.
Figma Design Viewer
View-only prototype preview. Editing and commenting are disabled.
Problem Statement
Parents in the trades face a critical technical and operational challenge: their work schedules are unpredictable, often starting at 4-5 AM with constant changes throughout the day. Traditional childcare booking systems operate on fixed schedules and weekly planning cycles, creating a fundamental mismatch with trades workers' actual availability patterns. The problem requires a system capable of dynamic schedule ingestion, real-time matching algorithms, and flexible booking logic.
Technical Solution
Tandem solves this through a multi-layered technical architecture: a flexible schedule input system that accepts documents, manual entries, and voice input (processed via AI); a temporal database model that handles shifting time windows; a real-time WebSocket layer for live availability updates; and an AI-powered matching engine that identifies compatible families and nannies despite schedule variability.
System Architecture
Tandem employs a modern full-stack architecture with clear separation of concerns: frontend UI layer, real-time communication layer, backend API layer, and data persistence layer.
Frontend
Next.js with React, TypeScript for type safety, Tailwind CSS for responsive design
- •Client-side schedule form handling
- •Real-time calendar rendering and updates
- •Voice input integration
- •Document upload preview and parsing
Real-time Layer
Socket.io for bidirectional communication
- •Live schedule synchronization across users
- •Instant booking notifications
- •Chat coordination between families
- •Server-sent availability updates
Backend API
Next.js API routes with TypeScript
- •Schedule parsing and temporal processing
- •Matching algorithm execution
- •Authentication & authorization via Clerk
- •Business logic for nanny-family pairing
Data Layer
PostgreSQL with optimized schema
- •Time-series schedule storage
- •User profiles and preferences
- •Booking transactions
- •Audit logs for compliance
Key Technical Decisions
Next.js for Full-Stack Framework
Rationale: Unified TypeScript codebase, API routes co-located with frontend, automatic optimization, and seamless Vercel deployment for serverless scaling.
Tradeoffs: Monolithic approach vs microservices; chosen for faster iteration and simplified deployment.
PostgreSQL over NoSQL
Rationale: Schedule data has complex temporal relationships and requires ACID transactions for booking consistency. Strong schema validation prevents data integrity issues.
Tradeoffs: Less flexible schema vs guaranteed consistency; critical for financial transactions.
Socket.io for Real-time Updates
Rationale: Trades workers need instant notification of availability matches. WebSocket provides near-zero latency compared to polling.
Tradeoffs: Requires connection management vs simpler REST approach; necessary for user experience quality.
Clerk for Authentication
Rationale: Offloads security complexity, provides SAML/OAuth integration, reduces liability for handling sensitive auth data.
Tradeoffs: Third-party dependency vs custom auth; justified by reduced attack surface.
IBM Watson + Grok AI for Matching
Rationale: IBM Watson for document analysis (schedule PDFs, contracts), Grok for preference matching. Multi-model approach provides resilience and specialized capabilities.
Tradeoffs: Dual API dependencies vs single provider; ensures service availability.
Implementation Highlights
Dynamic Schedule Parsing
Transforms multiple input formats (PDF schedules, manual entries, voice recordings) into consistent temporal data structures. Voice is transcribed via Watson, parsed via NLP, and validated against PDF originals.
Challenge: Handling conflicting schedule data from different input sources
Solution: Implemented conflict resolution pipeline: PDF as source of truth, manual entries for weekly patterns, voice for ad-hoc updates. Timestamp-based versioning ensures auditability.
Temporal Matching Algorithm
Core matching engine identifies compatible time windows between families, nannies, and available caregivers. Uses interval intersection logic and preference scoring.
Challenge: Efficiently computing availability overlaps across thousands of variable schedules
Solution: Pre-computed interval trees indexed on time blocks; Grok AI scores matches based on preferences, location, and historical compatibility. Results cached and invalidated on schedule changes.
Real-time Synchronization
Socket.io events propagate schedule changes instantly to connected clients. Server maintains room-based subscriptions for families and potential matches.
Challenge: Handling race conditions when multiple users update simultaneously
Solution: Optimistic updates on client; server applies vector clocks for causality tracking and resolves conflicts via last-write-wins with explicit notifications to affected users.
Group Chat Coordination
WebSocket-based private group chats for families and assigned nannies. Messages persisted to PostgreSQL for history.
Challenge: Ensuring messages are delivered reliably during network disconnections
Solution: Message queue with delivery receipts; client tracks unacknowledged messages and retries with exponential backoff.
Data Model & Schema Design
PostgreSQL schema optimized for temporal queries and booking consistency.
users
Columns: id, email, clerk_id, role (parent|nanny|admin), created_at, updated_at
Indexes: clerk_id (authentication lookups), role (filtering queries)
schedules
Columns: id, user_id, start_time, end_time, recurring (boolean), recurrence_pattern, source (pdf|manual|voice), version
Indexes: user_id, (start_time, end_time) - range queries for overlap detection
bookings
Columns: id, family_id, nanny_id, start_date, end_date, status (pending|confirmed|completed), payment_amount, created_at
Indexes: family_id, nanny_id, status - for transaction integrity and history
matches
Columns: id, family_id, nanny_id, confidence_score, match_reason, created_at, viewed_at
Indexes: family_id (for match display), created_at (for analytics)
Performance Optimizations
- ⚡Indexed temporal queries for schedule overlap detection (critical path)
- ⚡Connection pooling for Database interactions under concurrent booking
- ⚡Redis caching layer for frequently accessed matches and user preferences
- ⚡Client-side debouncing on form inputs to reduce API load during rapid filtering
- ⚡Image optimization via Next.js Image component (AVIF format for modern browsers)
- ⚡Lazy-loaded chat history to keep WebSocket message queue manageable
Security Considerations
Authentication
Clerk OAuth providers (Google, GitHub); enforces MFA for accounts managing payments
Authorization
Role-based access control (RBAC); families cannot view other families' schedules; admins have audit access only
Data Encryption
TLS 1.3 in transit; sensitive fields (SSN, payment methods) encrypted at rest via AWS KMS
Compliance
GDPR-compliant data retention policies; audit logs for all financial transactions; SOC 2 Type II certification target
Deployment Pipeline
Development
Next.js dev server with hot reload, local PostgreSQL, Socket.io debug logging
Staging
Vercel preview deployments on every PR; automated E2E tests via Playwright
Production
Vercel serverless deployment; managed PostgreSQL at Neon; CDN caching via Vercel Edge
Monitoring
Axiom for structured logging; Sentry for error tracking; custom dashboards for real-time metrics
Key Performance Metrics
- 📊Average schedule parsing time: <2 seconds for PDF documents
- 📊Match generation latency: <500ms end-to-end
- 📊Real-time WebSocket message delivery: 99.8% reliability
- 📊Database query p99 latency: <100ms for booking lookups