Bookvid - Live Video Booking Marketplace

The problem

A marketplace for booked sessions lives or dies on whether the booking is right. Availability has to reflect a host's real calendar, a recurring series has to hold together across weeks, time zones have to be correct rather than approximately correct, and two people must never be sold the same slot.

Off-the-shelf booking widgets handle the easy version of this and fall over on the rest.

What the platform does

Both halves of the marketplace. Attendees discover experts and book single or recurring sessions; hosts get a dashboard for pricing, managing a series, and overseeing their events. Calendars, payments and the live call are joined into one flow rather than three tools a user has to reconcile.

The stack is Next.js for the marketplace and host dashboard, a Python backend, Cronofy for calendar access and availability, Stripe for payments, and a third-party video and recording tool with the session experience built around it.

What I owned

I worked on Bookvid as a frontend developer at Inseed, the agency engaged to build it.

My work was the Next.js side — the marketplace attendees browse and book through, and the dashboard hosts use to price sessions and manage a recurring series.

Key decisions

Not buying the scheduling problem off the shelf. The most consequential choice was to build the scheduler rather than adopt a booking widget. Cronofy supplies calendar access and availability; the logic for single and recurring sessions, keeping time zones honest, and slotting a booking into a host calendar without conflicts is custom.

That is a decision worth defending, because "build your own scheduler" is usually bad advice. It held here because scheduling is not adjacent to this product — it is the product, and the failure modes a widget accepts are the ones a booking marketplace cannot.

Building the session experience rather than deferring to a video SDK. Booking, payment and the call had to feel continuous, so a good deal of the surrounding experience was built in-house instead of accepting whatever the SDK's own flow looked like.

What the team would do differently

Lock the video provider earlier. Much of the session experience was built in-house, and settling that choice sooner would have cut the surrounding plumbing.

Treat the custom scheduler as a product, not a feature. It carried the weight of the marketplace and deserved dedicated hardening and testing from the start rather than the attention a feature gets.

Write the backend and infrastructure decisions down while making them. They were left as gaps in the record, which is cheap at the time and expensive later.