WhatNow Scheduling Platform

The product constraint

Appointment businesses often assemble scheduling, payment, calendar, and email tools themselves. That creates duplicated setup and brittle handoffs. The goal was a coherent customer journey backed by an admin model flexible enough for recurring hours, one-off overrides, blackout periods, service durations, and daily limits.

Model the domain before the screens

I separated owner settings, services, availability rules, overrides, schedule blocks, appointments, and pending checkouts. That kept booking logic out of UI components and made each policy independently evolvable.

• Slot generation combines recurring availability, monthly overrides, blocks, service duration, and booking limits.
• UTC persistence and localized rendering keep the booking contract stable across visitor time zones.
• Database indexes support overlap queries where correctness and response time matter.
• Owner-scoped data establishes a path from a client implementation to a multi-tenant product.

Choose the stack around the consistency boundary

PostgreSQL was a deliberate fit for bookings, payments, and overlapping time ranges because the domain needs relational constraints, transactions, and indexed conflict queries. Prisma supplied a typed schema and migration workflow without replacing database-level reasoning. Next.js kept the customer interface and server-owned booking operations in one deployable product, while route handlers provided the trusted boundary for availability, checkout, and finalization.

• A document store would simplify flexible records but make relational booking invariants harder to express.
• Direct client-to-database writes would reduce server code but weaken authorization and payment trust boundaries.
• Clover matched the client's payment operation; the integration remains isolated behind server-side verification.
• Resend provided a focused transactional email path without coupling confirmation delivery to the UI request.

Treat payment as a state machine

A redirect is not proof of payment. The system creates a pending checkout with booking metadata, validates payment server-side on return or webhook, and only then finalizes the appointment. The boundary prevents a client from manufacturing a confirmed booking.

• Server-owned booking references connect checkout state to the intended appointment.
• Webhook signature support and provider verification create a trustworthy finalization path.
• A dedicated finalization layer centralizes idempotency-sensitive side effects.
• Confirmation email and calendar creation happen after the booking is valid.

Engineer for the failures scheduling invites

Scheduling combines concurrency, time zones, and external side effects. The design assumes callbacks can be repeated, two customers can pursue the same slot, and calendar or email providers can fail after payment succeeds. Server verification, centralized finalization, overlap checks, UTC persistence, and idempotency-sensitive boundaries keep those risks from being hidden inside UI state.

Design for production and demonstration

The production path uses PostgreSQL, authenticated admin tools, and external providers. A controlled in-memory fallback makes the product explorable when infrastructure is unavailable without pretending that demo state is durable.

Senior engineering signal

The important work was not assembling APIs. It was defining trust boundaries, sequencing side effects, isolating scheduling policy, anticipating tenancy, and giving the product a safe way to evolve after its first client deployment.

What I learned

Recurring availability looks simple until exceptions, service duration, daily limits, time zones, payments, and rescheduling start interacting. Keeping those rules separate made the scheduling logic easier to reason about and change. I also learned to treat every redirect or webhook as a message, not proof that the booking actually finished.