The brief
The business resells water experiences in Miami —jet ski, ATV, and yachts— at its own margin. Traffic comes from Instagram, but there was nowhere to send it: no site, no domain, no way to book beyond DMs. Competitors, meanwhile, already showed up on Google with real sites and online bookings.
Two business constraints ended up being engineering decisions: the owner resells with a markup (she collects, then pays the operator), and she's terrified of chargebacks from stolen cards. Any solution had to respect both — not just "look nice".
The decision: custom, not a template
The easy path would have been a generic Wix. We ruled it out for a concrete reason: a template identical to a thousand other businesses builds no trust, and —worse— it leaves the owner unable to edit anything without paying for each change. For a catalog whose prices and photos change often, that ages in weeks.
The alternative was to build a custom front-end and separate content from code. The owner shouldn't touch HTML to add a new tour; she should do it from an interface as simple as a spreadsheet. That points straight at a headless architecture.
The architecture
The whole system is four pieces, all on free or low-cost plans, with no server to maintain.
1. A custom static front-end
A single-screen, mobile-first page (the traffic comes from Instagram), with its own brand and its own domain with SSL. Hosted on a CDN: fast everywhere and nothing to patch.
2. Airtable as a headless CMS
The catalog —name, description, price, deposit, photos, active/inactive— lives in an Airtable base. To the owner it's a spreadsheet with photos she edits from her phone. To the system, it's the source of truth for content. Add a tour, change a price, and the site reflects it with no code and no redeploy.
3. A serverless function in between
The site doesn't talk to Airtable directly: it goes through a serverless function. Why? Because the API token can never live in the browser code, where anyone could read it. The function runs server-side, keeps the token in environment variables, and hands the front-end only what it needs, already cleaned. Security by design, not by luck.
4. Dynamic gallery and WhatsApp bookings
Each product opens a detail view with a swipeable gallery and a full-screen lightbox — the experience of a big brand. The reserve button opens WhatsApp with the order pre-written: the customer confirms in two taps, no forms, no friction.
The content isn't "baked into" the page: it loads live from Airtable on every visit. The owner owns her catalog. We operate the plumbing underneath — and if something goes down, a static fallback keeps the page from ever being empty.
Engineering the payment (the real problem)
This is where a designer stops and an engineer keeps going. The fear of chargebacks isn't solved with CSS: it's solved with the flow of money.
The model we built: the customer pays a card deposit equal to the owner's margin, and the balance in cash on the day of the tour, straight to the operator. Cash can't be charged back to a bank, so fraud exposure shrinks to the small part — and the owner never holds money that isn't hers. It's a business rule implemented as product logic, not an afterthought.
The result
The business went from not existing online to having miabluecharters.com: its own domain, SSL, a catalog with real photos, a professional gallery, WhatsApp to book, and a panel the owner edits herself. The bulk of the build took an afternoon — because the architecture is deliberately simple, not because anything was cut.
What this case shows isn't "we make cheap websites". It's that the same way of thinking we use for SaaS products in production —separate content from code, hide the secrets, let data be the source of truth— applies just as well to a jet-ski business. The difference between a template and this isn't visible on day one; it's visible at month six, when the owner is still editing her site herself and the neighbor's template froze solid.