How to Build a Cameo-Style Celebrity Video Booking Platform
What a Cameo-Style Platform Actually Requires
A personalized celebrity video platform sounds simple on the surface — fan requests a video, star records it, fan receives it — but the real system has to handle asynchronous fulfillment (the star might take days), payment that's held until delivery, and a mobile experience that mirrors the web app exactly since most bookings happen on phones. That's what I built for Yelastar, a platform for booking personalized videos from public figures.
Designing for Asynchronous Fulfillment
Unlike a normal e-commerce checkout where the "product" is delivered instantly, a video request has a real-world delay between payment and delivery — the star has to actually record it. The order model has to reflect that as a genuine state machine (requested → accepted → in progress → delivered), not a simple paid/unpaid flag, with the admin dashboard giving staff visibility into where every request sits so nothing silently stalls. Email notifications fire to both the admin and the client at each state change (via Nodemailer through Hostinger SMTP), which matters more here than on a typical store — customers are waiting on a person, not a warehouse, and that uncertainty needs to be actively managed with communication rather than left to a static order-status page.
Local Payment Gateway Integration
For a platform targeting a market where Stripe/PayPal aren't the default rails, integrating a local gateway (Djomey, in this case) means working with different webhook conventions, different failure modes, and often thinner documentation than the big global providers. The lesson that generalizes: build the payment layer behind your own internal interface from day one, so the specific gateway is an implementation detail your checkout flow doesn't need to know about — it's what makes swapping or adding a second payment provider later a contained change instead of a rewrite.
One Experience, Two Native Apps
The web app (Next.js 15, App Router, Framer Motion for the star browsing experience) and the Flutter mobile app needed to feel identical in what users can do, while being built natively for each platform rather than wrapping one in the other. State management differs by necessity — Zustand on web, flutter_bloc/Cubit on mobile — but both read and write through the same Supabase backend with RLS policies as the actual authorization layer, so "what a user can see and do" is defined once, in the database, rather than duplicated in two separate frontend codebases where it can drift out of sync.
Media Storage at Scale
Every delivered video is real file storage, not a database row — Supabase Storage handles star media and delivered videos with access rules matching the order state, so a fan can't access a video before it's actually marked delivered, and a star's uploaded raw content isn't publicly reachable by URL guessing.
Conclusion
The hard part of a booking marketplace like this isn't the browse-and-pay flow — it's modeling the real-world delay between payment and delivery as an explicit state machine, and keeping authorization rules in the database rather than duplicated across web and mobile. See the full Yelastar case study for the complete tech stack.
