Hearth & Hair Booking Platform
End-to-end service business web platform with automated booking, real-time calendar integration, and transactional email workflows. Shipped with real users.
- Role
- Full-Stack Developer (Independent)
- Timeline
- Jan 2026 – Mar 2026
- Team
- 2 people
- Client
- Hearth & Hair
The problem
A growing service business was losing bookings to phone tag and double-bookings. It needed a self-serve platform where clients book online against live availability and get confirmed automatically.
Constraints
- Concurrent bookings must never produce a double-booking
- Confirmations and reminders must never go out twice, even when a job retries
- Real customers from launch — built by a two-person team in about three months
Architecture
Step 1, Interface
Booking app
Next.js self-serve booking
Step 2, Compute
Availability service
Server-side, single source of truth
Step 3, Data
PostgreSQL
Bookings and schedules
Step 4, External
Calendar sync
Real-time, prevents double-booking
Step 5, Ingest
Email queue
Idempotent confirmations and reminders
Engineering decisions
Availability from a single source of truth
- Context
- Two clients booking the same slot at the same moment is exactly when double-bookings happen.
- Decision
- Computed availability on the server from one source of truth rather than trusting what each browser last saw.
- Trade-off
- Every availability check goes through the server — the price of removing the race condition.
Queued, idempotent email workflows
- Context
- Transactional email jobs can retry after a timeout, and a duplicate confirmation erodes trust.
- Decision
- Queued confirmation and reminder emails and made every send idempotent.
- Trade-off
- More plumbing than sending mail inline, in exchange for exactly-once behaviour from the customer's point of view.
An AI-assisted development workflow
- Context
- A two-person team needed to move quickly without sacrificing quality.
- Decision
- Built the platform with an AI-assisted development workflow.
Outcomes
Real Users
Uptime
Build Approach
- Live on Vercel and serving real customers
- Measurably reduced the manual scheduling overhead the business used to carry
- Uptime monitored in production
Reflections
Lessons learned
Putting it in front of real users surfaced edge cases no spec ever would have — timezone handling, cancellation flows, and reminder timing all needed real iteration once actual bookings started flowing. That feedback loop, more than any upfront design, is what turned a working build into a dependable product.
Proof — verify it yourself
Tech stack
- Next.js
- React
- TypeScript
- Node.js
- PostgreSQL
- Vercel
Related writing
- Best Practice
Exactly once, from the customer's point of view
Double bookings and duplicate confirmation emails are the same bug in two costumes. Patterns from building a booking platform for a real service business.
3 min read
- #reliability
- #postgresql
- #nextjs
- #idempotency
Work with me
Facing a similar challenge?
I build systems like this end to end — from the first architecture sketch to production. Tell me about yours.