DEPLOYMENTS / BOOKINGHUB
SAAS PLATFORMBookingHub
A full property-booking platform: public storefronts for every provider, availability calendars, revenue reports — and a three-function email layer that confirms guests instantly, alerts hosts on new bookings, and delivers a pg_cron-scheduled daily digest to every provider at 08:00 UTC. All authorisation is enforced at the database via RLS.
CLIENT
Hospitality platform
YEAR
2026
SYSTEMS
WEB · AI
STATUS
DEPLOYED
3
automated email workflows
20
application routes
08:00
UTC daily digest, cron-scheduled in-database
[ THE BRIEF ]
The challenge we walked into.
Independent property owners were losing bookings to big platforms that took a cut of every reservation and owned the customer. They needed their own storefront, their own booking flow, their own data, and enough automation baked in that the whole business ran without an operations team. Bonus points: no external cron server to babysit.
[ TOPOLOGY ]
How the system is wired.
// SYSTEM TOPOLOGY
[ WHAT WE SHIPPED ]
Feature by feature.
Every provider has their own slugged site.
Slugged storefronts (/providers/[slug]) with property listings, filters and a multi-step booking form. A public directory of providers surfaces new hosts; individual storefronts give returning guests a direct URL. The provider owns the customer relationship — not a marketplace.
- ▸Slug-based storefronts
- ▸Public providers directory
- ▸Property detail + booking flow
- ▸Multi-step form UX
[ APPROACH ]
How it came together.
01 — POSTGRES DOES THE HEAVY LIFTING
The database is the boundary.
Row-level security separates providers so each only sees their own properties and bookings, while public read policies keep storefronts fast. Triggers auto-create user profiles on signup, keep timestamps honest and enforce every business rule the app expects. The schema is idempotent — safe to re-run — so onboarding a fresh Supabase project is minutes, not hours.
02 — SCHEDULING IN-DATABASE
The 08:00 digest lives inside the database.
pg_cron schedules the summary email; pg_net makes the HTTP call to the Edge Function. No external scheduler, no cron server to babysit, no GitHub Actions eating minutes. When you drop the database you drop the schedules too — everything is self-contained. If we ever move to Fly.io or Railway, the schedules come with the schema.
03 — IDEMPOTENCY EVERYWHERE
Every migration is safe to re-run.
All SQL is CREATE IF NOT EXISTS, ALTER TABLE ADD COLUMN IF NOT EXISTS, DROP POLICY IF EXISTS. A new developer points the app at a fresh Supabase project and is up in minutes. The setup documentation stays honest because the SQL doesn't lie — running it twice is a no-op, not a corruption.
04 — EMAIL AS A FIRST-CLASS LAYER
Three functions, one clean contract each.
Each email workflow is its own Edge Function with a typed payload contract documented in the README. Retries, dedup and failure handling live inside each function — the app just fires and forgets. If Resend goes down, the function logs it and returns 500; the app handles the fallout gracefully rather than blocking the booking.
[ DELIVERY ]
What the build looked like.
01 ▊
[ TECH STACK ]
What’s under the hood.
HOVER FOR ROLE
[ IMPACT ]
What changed.
Independent providers stopped feeding a marketplace and started running their own storefront. Bookings arrive instantly, hosts get briefed every morning without lifting a finger, and everything is theirs — the customers, the data, the emails. Marketplace commissions became a memory. Because the whole system is idempotent Postgres + Edge Functions, a new deployment for a new provider network is a schema push and a secrets set away.