Unpack Bahamas
I run a Facebook group for vacation rentals in the Bahamas. Around 12,000 members. Owners post their properties, travellers ask questions, and bookings get arranged in the comments.
Being in it every day, I kept seeing the same failures. Listings with no working link. Photos that had clearly come from somewhere else. Contact details that led nowhere. Someone would ask "is this place real?" and nobody — including me — could answer with certainty.
I assumed this was specific to my community. The data says otherwise.
Source: US Federal Trade Commission; BBB Scam Tracker
The documented pattern is precisely what I had been watching play out in my own comments section.
Every step is plausible on its own — the traveller can't tell step 01 from step 03. So the problem was never my community; it was a structural failure in how people book stays in the Bahamas, one I'd been watching daily with 12,000 people who already trusted me. That's where Unpack Bahamas came from.
Booking a place to stay in the Bahamas means assembling trust out of fragments: a Facebook post with no link, a review site ranked by commercial priority, a forum thread from 2019, a listing you cannot verify. There is no single place where a traveller can learn where to stay, when to go, and whether what they are looking at is real. The information exists. The confidence does not.
Build the most trusted independent resource for travelling to the Bahamas. One country, covered properly. Every recommendation chosen by a human, every practical question answered in one place, and a clear path from curiosity to a booking the traveller feels safe making.
The Bahamas is booming. 12.5 million visitors in 2025 — an all-time record, up 11.4% year on year, more than 70% above pre-pandemic levels. Almost none of that is my user.
Stopover visitors are the only people who book a place to stay. It is the one segment that did not grow.
That gap is the opportunity. The boom is a cruise boom, so most content targets day-trippers, not the person renting a house on Eleuthera for nine days who needs to know which beach is worth the drive. That's who Unpack Bahamas is for: the 1.8 million stopover visitors, not the 12.5 million cruisers — especially the ones booking privately, where trust matters most.
Choosing the smaller number was the first real product decision. It cost most of the audience — and bought the ability to be genuinely useful to what was left.
I audited four categories of competitor, looking for what each one structurally cannot do.
One country, in depth →
The depth already existed inside the Facebook groups. The verification did not. Unpack Bahamas is the same knowledge moved up the trust axis.
Enormous authority and reach. Now partnered with an AI travel platform for itinerary planning.
Promotional by mandate. It cannot tell you an island is a poor fit, or that a month is bad value. A source that can only say positive things is a weak source for a real decision.
Real editorial credibility and brand trust.
The Bahamas is one destination among hundreds. Breadth over depth, updated infrequently, never at the level of an individual property.
Massive inventory and review volume.
Ranked commercially and weighted toward resorts. No editorial point of view, and almost no help with private rentals.
The most honest information available anywhere.
The least trustworthy format. Unstructured, unverifiable, and where roughly half of rental scams begin.
The gap: nobody was combining single-country depth, human curation, and verification. Every competitor was too broad, too promotional, or too unstructured. That gap is small enough that no large publisher will bother to fill it — which is exactly why a solo operator can.
Every competitor treats verification as hygiene. For this audience it is the entire job to be done. Once I accepted that, decisions that had felt like taste — how much to curate, how much to disclose, what to refuse to publish — became strategy.
I cannot out-resource a global travel publisher. I can know one country better than they have time to. Constraint as positioning.
Serving the small, flat segment rather than the large, growing one is counter-intuitive and correct: the large segment is already saturated with content and does not have my problem.
Publisher traffic from Google fell around a third year on year; where an AI Overview appears, organic click-through dropped 61%. Meanwhile travel's citation share inside AI Overviews grew from 5.7% to 17.7%. I was launching a content site into a collapsing distribution model. That single fact reshaped how I structured everything.
No budget, no photographer, no engineer, no team. Every significant decision downstream came from working within those limits rather than around them.
Three decisions shaped the product more than any other. In each case the obvious move was available, and cheaper.
Unpack Bahamas is a small business, not a portfolio exercise — it earns through affiliate partnerships: TravelPayouts for flights and travel services, GetYourGuide for experiences. Booking.com comes next as traffic grows, which would let licensed photography of bookable stays replace the AI imagery rather than work around its absence.
The GetYourGuide widget live on an island page, surfacing tours a reader can book through GetYourGuide with one click.
Which sets the rule for what goes on the page: what to recommend is decided first, on its own merits, and the affiliate link only gets attached after.
I structured the site around the sequence of questions a traveller actually asks, in order. Most Bahamas content answers these in isolation, on separate sites. Putting them on one ordered path is the product.
Each level had to work two ways: readable as a page by a person, and extractable as an answer by a machine. That dual requirement drove the format of every template on the site.
I did not open Figma once on this project — not a statement, a consequence. Working alone with no handoff to anyone, a mockup would have had no audience, and every hour spent making a picture of the product was an hour not spent on the product. So I designed in the browser instead, in code, with real content, from the first day.
Real responsive behaviour, real content instead of placeholder text, and a shorter loop: idea → build → review instead of idea → mockup → build → review. I could test a direction in minutes, not commit to one on a static image.
Cheap divergence. Figma lets me kill three directions in twenty minutes; in code, each one costs real time, so I explored fewer. I also lost the artefact — no polished Figma file, which is why this case study leans on diagrams and shipped screens instead.
The honest summary: building in code made me faster to ship and slower to explore. For a solo 0→1 with a hard constraint on time, that was the right trade. On a team, with a handoff, it would not have been.
What that browser-first process above actually produced — swipe through for the pages and details that don't come across in writing.
A five-question onboarding quiz that tailors recommendations to how someone actually wants to travel.
An interactive estimator for what a rental runs, by island, season and party size.
A spin-the-year widget showing the trade-off between crowds, price and storm risk, month by month.
Curated rental picks and local activities, generated per island.
An individual stay listing, with the reasoning and the affiliate booking link attached.
The honest version of hurricane season — when the risk actually sits, not just that it exists.
What each storm category actually means, and the contract terms worth insisting on before paying a deposit.
AI-generated interfaces default to competence without identity — safe type, even spacing, the same card as everyone else's site. Prompting harder didn't fix it: every new session started from zero and produced the same generic output. The problem was never the prompt. It was the missing constraint.
Rejecting generic output and re-explaining what I wanted, session after session. It rarely held past the conversation it happened in.
A brand-guidelines file in the repo: colour tokens, type scale, spacing and component rules. The AI reads it on every build, whether I remember to mention it or not.
Claude Code for the majority of the build, moving to Cursor toward the end. Netlify for build and hosting. Higgsfield for imagery. Google Analytics, Search Console and Umami for measurement. Alongside it I took Anthropic's official courses on working with Claude, which mostly taught me to specify context and constraints up front instead of correcting output afterwards.
The country, the audience and the question sequence, settled before a line was written.
Brand guidelines written first, then templates generated inside them.
Structured generation for guides and journal posts, plus the atmospheric image layer.
Deploy, then wire up Search Console, Analytics and Umami before chasing traffic.
Roughly two months end to end. Inside every phase, the same loop repeated:
Product decisions, information architecture, what to publish and what to refuse to publish, and the final read of anything factual. AI wrote a great deal of what is on the site. It decided none of it.
Repeated content types. Rather than improvising each blog post and listing from scratch, I encoded the structure, the research requirements and the tone once, so every piece comes out consistent and research-backed by default — the same principle as the design system, applied to writing.
I had never really used GitHub before this project — no branching, committing or deploying anything myself. Learning it turned out to be less about the tool and more about a habit: check in often, read every diff, and treat a branch as a safe place to be wrong before anything touches what's live. It's the same discipline good product development runs on, and now I work in it directly instead of describing it to someone who does.
I worked through several of Anthropic's courses along the way — the practical ones on building with Claude, and the broader ones on how the models and the code underneath actually work. It changed the unit of work: less asking and correcting, more setting the constraints up front. The brand guidelines file came directly out of that.
Output that is competent and anonymous — the same layout, the same card, the same gradient as every other AI-built site. Reprompting rarely fixed it, because the problem was never the prompt.
Stopped negotiating per prompt and encoded the constraints once, as the brand guidelines file. AI is a very fast executor of a decision and a very poor substitute for making one.
Generated layouts routinely looked correct on desktop and broke on a phone. AI produces work that looks finished at the size you happen to be looking at it.
Made testing both viewports non-negotiable in the loop. This mattered more than I realised: 76% of my visitors arrive on a phone, so the surface AI kept quietly breaking is the one almost all of my users experience.
On a travel site, a confidently invented ferry schedule or price is not a bug. It is a liability that costs someone money on a trip.
An absolute rule: anything factual is verified against an official source before it ships. Never the model's word, no matter how plausible.
I launched a content site at the moment content sites stopped working.
Sources: BrightEdge; industry publisher-traffic analyses, 2025–26
Read together, those numbers say something specific: traffic is leaving, and citation is arriving. So I stopped optimising to be ranked and started optimising to be referenced.
Query → ranked list of links → the reader clicks → they arrive on your site.
Measured in position and clicks. The page is written to win a ranking, then persuade a human.
Query → a synthesised answer → your page cited as a source → sometimes a visit.
Measured in citation frequency. The page is written to be read cleanly by a machine and quoted accurately.
The page opens with the answer instead of building to it. That paragraph is the part that gets quoted.
Clear heading hierarchy so a model can parse the page without guessing what belongs to what.
Explicit markup rather than implied meaning. Sites with comprehensive schema appear in 47% more Perplexity responses.
Specific settlements, beaches, operators and properties — not "the island" and "the area."
The one thing a model cannot synthesise from other sources — and my reason to be cited rather than summarised around. First-hand knowledge from 12,000 people is exactly what AI engines quote and cannot generate.
At the site level, an /llms.txt at the root — robots.txt for a model instead of a crawler, regenerated automatically as pages ship. No major AI crawler has confirmed it reads llms.txt yet, so it's a near-zero-cost bet, not a proven win. Running the site is where this shows up most: I feed Search Console, Analytics and Umami straight to the model to decide what to publish, rewrite or cut — a loop that used to take a specialist a week, now weekly.
Month-one numbers from a site with no backlinks, no brand and no history. I also posted no links to it — not to the 12,000-member group, not anywhere — so this is a clean test of one question: can it be found on its own, by search and by AI? A baseline, not an outcome.
Position 42 is not where traffic lives yet, and the 0.45% click-through rate follows from that position rather than from the content. Session duration is the number I care about most: the people who do arrive actually read.
Search Console and my own analytics tell opposite stories, and the gap between them is the most useful thing I have learned so far.
Mobile click-through runs at 0.96% against desktop's 0.27% — roughly 3.6×.
Two caveats worth stating plainly. Month one produced roughly eleven search clicks in total, so 3.6× is a direction, not a stable rate — a couple of clicks either way would move it a lot. And the sources still are not identical: Search Console counts Google organic only, while my analytics counts every arrival, including direct visits and referrals from AI tools. Two weak signals pointing the same way is what made it worth acting on; neither would have been enough alone.
Mobile responsiveness was the single thing AI most reliably got wrong during the build — and my own data says mobile is not a secondary surface here, it is the product.
The tool was wrong in a way I could not see. Only the data would have told me.
When building costs hours instead of weeks, the constraint stops being "can I make this" and becomes "should this exist, for whom, and is it true." The job moved up a level.
Its purpose stopped being alignment between people and became constraint on a generator. That is a genuinely different thing to design.
No budget chose the imagery approach. No engineer chose the build method. No team chose the scope. The best decisions came from limits, not options.
Generated imagery on a trust product forced me to draw a line. Setting it was worth more to the product than any speed I gained.
Branches, commits and deploys turn fast generation from a risk into a method. Being able to undo is the precondition for being able to move.
Not from a badge or a promise, but from the image I did not generate, the link I did not place, the listing I did not publish. None are visible to a reader. All of them are the product.
