Krishna Bhupathi

Fig. 1

Slotwise

Booking and deposits for solo tutors.

A 90-second walkthrough with narration and captions. Sound plays only when you press play.

The problem

Solo tutors lose time to messages about when to meet, and money to students who don’t turn up. Slotwise gives a tutor one link: students pick a time shown in their own zone, pay a deposit and get a calendar invite.

For tutors who sell lessons by the hour and have no one to manage bookings for them.

The product

The Slotwise booking page: a week timetable with open times in orange, closed days hatched, and the picked time with its $15 deposit on the right.
The booking page. Open times in the subject’s colour, shown in the student’s time zone.
The Slotwise home page: the headline “Your week, as a timetable students can book”, an example week in subject colours, and a Try the demo button.
The home page. Try the demo signs you in to a sample tutor account.

Hard problems

  • Two students, one time

    If two students book the same time at once, both requests can pass the app’s check. So the database decides: a Postgres exclusion constraint rejects any two live bookings whose times overlap, buffer included. The second student sees “someone booked that time a moment ago”. A test fires two requests at once to prove it.

  • Payments that arrive twice, or late

    Stripe can send the same webhook more than once. Each event id is stored in the same transaction as its effect, so a repeat does nothing. A slot is held for 10 minutes, but a Checkout session lasts 30. A late payment confirms only if the time is still free; otherwise the deposit is refunded automatically.

  • Time zones and clock changes

    Hours are stored as wall-clock times in the tutor’s zone, and bookings as UTC instants. The slot engine uses Temporal: an hour skipped when clocks go forward isn’t offered, and an hour that happens twice is offered once. Tests pin London, New York, Kolkata and Kathmandu (UTC+5:45).

Measured

981
Lighthouse mobile performance, booking page
1001
Lighthouse accessibility, booking page
2.3 s1
Largest paint on a throttled phone, booking page
156 + 182
Unit and database tests, plus browser test runs

How it’s built

  • Next.js 16 (App Router, Server Actions)
  • TypeScript
  • Postgres on Neon, Drizzle ORM
  • Auth.js v5 (magic link and demo login)
  • Stripe Checkout (test mode)
  • Resend for email
  • Vitest with PGlite, Playwright
  • Vercel, GitHub Actions for hourly jobs
  1. Student → AppPicks a time and answers the intake form.
  2. AppRe-runs the slot engine and validates the answers.
  3. App → PostgresInserts a 10-minute hold. The exclusion constraint rejects any overlapping booking.
  4. App → StripeCreates a Checkout session with an idempotency key, and redirects the student.
  5. Student → StripePays the deposit.
  6. Stripe → AppSends the checkout.session.completed webhook.
  7. App → PostgresIn one transaction: records the event id and confirms the booking.
  8. App → ResendAfter the commit: confirmation email with a calendar invite.
  9. GitHub Actions → AppHourly: sends reminders and expires lapsed holds. Nightly: resets the demo.

More decisions and their trade-offs are in the README.

Replies within a working day.

Need something like this?

Sources

  1. Slotwise booking page, Lighthouse mobile: performance 98, accessibility 100, LCP 2.3 s. Median of 3 runs, Lighthouse 12.8.2, measured 14 Oct 2026 from India against production. Source: slotwise-booking/docs/measurements.
  2. Slotwise tests as of 15 Oct 2026: 156 Vitest tests (unit, and database tests on PGlite) and 18 Playwright runs (9 tests on desktop Chrome and a Pixel 7), green in CI. Source: slotwise-booking README.