Over the past several weeks, I've been building and hardening a complete booking automation system for a luxury vacation rental — Intervale Mountain Lodge, a 10-bedroom mountain retreat in New Hampshire. Sharing the full scope because I think the unglamorous parts are the actual story. What it replaced: Manual phone screening, hand-calculated quotes, texted door codes one guest at a time, no real visibility into what dates were actually available. What's live now: 🔹 Real-time pricing engine (Supabase) — server-side calculation of nightly rates, fees, and taxes, returned as a locked, tamper-proof quote 🔹 Airbnb-style admin pricing calendar — the owner can set per-date rates, block dates, and adjust global defaults from a password-protected dashboard, syncing instantly to the guest-facing site 🔹 Two-way Airbnb calendar sync to eliminate double bookings 🔹 Multi-step guest qualification form, feeding a structured inquiry straight into the CRM (GoHighLevel) 🔹 Password-protected guest portal — door codes, WiFi, house rules — served securely per booking, with rate-limited login and unique per-booking passwords 🔹 Full review system — guest submission funnel, admin moderation (approve/reject/archive), and a public reviews page blending direct guest reviews with synced Airbnb reviews 🔹 Security hardening pass — Row-Level Security on every table, admin-authenticated endpoints, credential rotation, and a full frontend secrets audit 🔹 Cross-team integration debugging — resolved multiple production issues surfaced by the automation team's live n8n workflows: a 500 error from an unhandled edge case, a field-naming mismatch between systems, and a data-mapping gap between the website and CRM contact records 🔹 Architecture documentation — when platform-stability concerns came up around external integrations vs. native CRM features, documented exactly which parts of the system are external, why, and what the actual upgrade risk is (spoiler: one integration point, clearly isolated)

Big shift today — not a bug fix, an architecture change. Our partner shipped a full guest review + admin moderation system directly on the website, which meant tearing out a chunk of what we'd already built and rebuilding it around the new design. What changed: The site now has a /admin/reviews panel where guests submit reviews and Steve approves/rejects them, posting straight to Supabase. That whole loop — collect rating, match to booking, route to Steve for approval, publish — now lives on the website side, bypassing GHL/n8n entirely for that part. That means our original SMS-based approach (text guest for a rating → parse reply → match booking → text Steve a one-tap approve/reject) is retired. Workflows 5B, 5C, and 5D are dormant — left in place, but no longer part of the live flow. What I rebuilt: Workflow 5A (the post-checkout trigger) got reworked instead of scrapped. It still fires the day after checkout and still marks the booking so guests don't get pinged twice — but now it sends both SMS and email with a direct link straight to the review page (/review?opportunityId=...), handing the guest off to the partner's new system instead of trying to collect the rating over text. Testing: Ran the whole thing live, start to finish — inquiry → approval → payment → confirmation → 5A firing on schedule → guest gets the SMS link → submits a review on the partner's page → shows up correctly in Steve's Pending Reviews panel with the right rating, comment, and booking reference attached. ✅ Complete and verified end-to-end. Good day to simplify instead of add — fewer moving parts on our side now that the website owns review collection and moderation. Next up: still Calendar Booking Automation (Workflow 3), still waiting on Stripe to go live for a real payment test. Still blocked on: Stripe connection, A2P phone verification, and the custom email sending domain (deliverability fix flagged yesterday) — all outstanding before a full real-data run across the workflows.

Two bugs today, and both turned out to be "the code's not lying, you're just misreading it" situations. Bug #1: SMS approvals silently failing We've got a workflow where an SMS like "approve [guest name]" matches against open inquiries and moves the booking forward. Testing it kept returning "couldn't find a pending inquiry matching ''" — empty name, every time. Dug into the parsing code and found it: the node strips the command word off the front of the message to isolate the name — so it needs the message shaped exactly like "approve John Smith", command first. Any other phrasing and the regex strip does nothing useful, name comes out blank, and it silently routes to the fallback branch instead of throwing an error. No crash, no red flag — just a wrong-looking result that looks exactly like a real matching bug until you actually read the extraction logic line by line. Bug #2: The invoice email that wasn't missing Got a report that a test guest never got their invoice. Went straight to the API response from the invoice-send call, fully expecting to find a failed request or a wrong recipient field. Instead: both the SMS and email legs came back successful. "msg": "Email queued successfully", correct recipient, correct invoice link, all of it. So where'd it go? Spam folder. The email was sent from GHL's shared sending domain rather than a verified custom one, and Gmail flagged it as "similar to messages identified as spam in the past." Good reminder for myself: before assuming an automation is broken, check whether the thing actually did happen and just landed somewhere unexpected. Would've been easy to burn an hour re-debugging a workflow that was working exactly as built. Real takeaway from today though — this isn't just a one-off test annoyance. Every guest-facing GHL email (invoices, confirmations, review requests) is riding on that same shared domain, so it's a deliverability risk across the whole system, not just this workflow. Adding "set up a verified custom sending domain (SPF/DKIM/DMARC)" to the pre-launch checklist.

Finished the admin side of a review-moderation system today, and the last two fixes were a good reminder of what separates a working feature from a genuinely usable one. First: the admin had two separate password-protected pages (a pricing calendar, a review moderation panel) and had to re-authenticate every single time they switched between them. Technically secure, practically annoying enough that a real owner would stop using it within a week. Fixed with a shared session — unlock once, move freely between admin pages, session clears when the tab closes. Second, and more important: approved content had no "undo." Once a review went public, there was no way to pull it back down without touching a database directly. Added a proper Remove action — but scoped so only the authenticated admin session can ever see or call it, with the endpoint itself checking the same server-side password rather than trusting a hidden button. Neither of these was a hard technical problem. Both were the kind of thing you only catch by actually trying to use the feature the way the end user will — not just testing that the API returns 200. Curious how others build that step into their process — do you have a formal "use it like the real user would" pass before calling something done, or does it happen more informally?

Just finished Workflow 5 in a booking-automation system I'm building: automated review collection that doesn't just blast requests and hope for the best. Here's the flow: 1. Day before checkout, guest gets a text asking for a quick rating + comment 2. Their SMS reply gets parsed and matched back to the exact booking automatically 3. Owner gets a summary text with one-tap approve/reject 4. Approved reviews get pushed live to the website automatically — rejected ones just... don't The part I like most: the owner stays the actual gatekeeper for what goes public, but doesn't have to do any data entry, matching, or copy-pasting to make that happen. The automation handles all the boring connective tissue; the human just makes the one judgment call that actually needs judgment. Tested the whole loop end-to-end with simulated data today — guest reply → parsing → owner approval → live on the site via a Supabase push. All green. Currently blocked on business basics, not code: need Stripe actually connected and the SMS number verified before this can run with real guests. Funny how the "boring" account-setup stuff ends up gating way more than the actual automation logic does. Up next: automatic calendar-blocking so a confirmed booking locks the dates without anyone touching a calendar by hand — waiting on clarity from the team on how the existing Airbnb sync is wired before I build against assumptions I can't verify.