Smoobu website builder suffers from bad UX, I used their API instead

How to build a direct STR booking site with Claude, Smoobu & Stripe — Waldo Vanderhaeghen Skip to content ☰

How to build a direct STR booking site with Claude, Smoobu & Stripe

Reference implementation: seumi.vanderlore.de smoobu stripe next.js i18n claude 11 June 2026 How to build a short-term rental direct booking site with Claude, Smoobu & Stripe — in 10+ languages Airbnb's guest-side service fee adds 14–16% on top of your nightly rate. On a €700 weekly booking, that's €100 disappearing before a guest even confirms. A direct booking site cuts platforms out of that transaction — and with Claude as your build partner, it's a realistic weekend project, not a multi-month engineering commitment. My own Altbau flat near Boxhagener Platz in Friedrichshain runs on exactly this setup — guests book at a lower price than on Airbnb, same apartment, same hosts. This guide covers the full stack: booking engine, payment flow, multilingual SEO, analytics, an automated Claude agent loop that catches and fixes issues overnight, security hardening, and German legal compliance. Every section includes working code. The system, drawn as a loop The key insight is that this isn't a website you build and forget. It's an iterative system — every layer feeds the next, and each iteration makes the whole thing more reliable. Build Claude AI Audit SEO, Security & legal skills Deploy GitHub → Vercel Bookings Smoobu · Stripe Measure PostHog · GA4 · Telegram ↻ feedback loop Pipeline step Loops back — next iteration A guest books → GA4 and PostHog fire → a nightly smoke check runs → if something breaks, Telegram alerts → a ticket appears in the backlog → Claude picks it up → a fix deploys → the loop runs again. The core booking flow ships in a weekend. The monitoring, agent loop, and legal layers compound over the weeks that follow — that's by design. 1 Foundation: GitHub + Vercel Set up the deployment pipeline before anything else. Every subsequent layer ships through it. Create the repo and project Terminal npx create-next-app@latest your-booking-site --typescript --tailwind --app cd your-booking-site git init && git remote add origin git@github.com:yourorg/your-booking-site.git git push -u origin main Connect Vercel Go to vercel.com → New Project → Import from GitHub Select the repo — Next.js is autodetected, no config needed Every push to main now auto-deploys to production No CI files, no build scripts, no server to manage. Vercel handles it. Environment variables Set these in Vercel Dashboard → Settings → Environment Variables before writing API code. Mirror locally in .env.local (gitignored — never commit secrets). SMOOBU_API_KEY=... SMOOBU_APARTMENT_ID=... STRIPE_SECRET_KEY=sk_live_... NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_live_... STRIPE_WEBHOOK_SECRET=whsec_... NEXT_PUBLIC_GA_MEASUREMENT_ID=G-XXXXXXXXXX NEXT_PUBLIC_POSTHOG_KEY=phc_... TELEGRAM_BOT_TOKEN=... TELEGRAM_CHAT_ID=... CRON_SECRET=... # random string, verify in cron handler Scaffold with Claude Once the repo exists, brief Claude on the full system in a single session: Prompt to start with

"Build a Next.js 16 App Router direct booking site for a short-term rental. It needs: Smoobu availability and pricing API, Stripe PaymentIntent payment flow with webhook, multilingual routing for 12 locales, and a Telegram alerting module. Start with the folder structure and the Smoobu client."

Claude will scaffold the architecture, flag the non-obvious traps (webhook ordering, the timezone bug), and propose the folder structure before you write a line of business logic. 2 Smoobu: availability, pricing, reservations Smoobu is the channel manager that aggregates bookings from Airbnb, Booking.com, and your direct site. Get your API key at Settings → External Integrations → API . Checking availability and pricing lib/smoobu.ts const BASE = "https://login.smoobu.com/api"; const headers = { "Api-Key": process.env.SMOOBU_API_KEY!, "Content-Type": "application/json", };

export async function getAvailability(apartmentId: string, start: string, end: string) { const url = `${BASE}/rates?apartments[]=${apartmentId}&start_date=${start}&end_date=${end}`; const res = await fetch(url, { headers, next: { revalidate: 300 } }); const json = await res.json(); return json.data[apartmentId] as Record0 | 1; min_length_of_stay: number; }>; } available: 0 means blocked. Build a Set of blocked date keys and disable those dates in the calendar. The response is cached for 5 minutes (revalidate: 300) — enough freshness without hammering the API.

The calendar pulls live availability from Smoobu's rates API. Greyed-out dates are blocked — either by existing bookings or minimum-stay rules. The timezone pitfall — read before writing any date code Smoobu returns dates as strings: "2026-07-01". If these pass through JavaScript's new Date() and .toISOString(), you get one day early — JS parses date-only strings as UTC midnight, but your guests and calendar are in local time (Berlin is UTC+2). Never do this new...

Smoobu website builder suffers from bad UX, I used their API instead

Related Articles

Claude Fable 5

US Government directive to suspend access to Fable 5 and Mythos 5

Is AI ruining our skills? Early results are in – and they're not good

The Anatomy of an AI-Native Org

Apertus – Open Foundation Model for Sovereign AI