Tiki Tommy Live
Real-Time Decision Engine
for South Padre Island

The South Padre Island tourism landscape is fragmented across platforms with competing agendas. SPADRE.com has raw utility and SEO density but no brand experience. VisitSouthPadreIsland.com has clean storytelling but no real-time decision layer. TripAdvisor and Expedia handle reviews and booking. Nobody handles the moment that actually matters: a visitor already on the island at 2pm on a Saturday who needs to decide where to go in the next hour.

Tiki Tommy Live was built for that person. Not for pre-trip planning. For the group standing in the hotel parking lot with a full day ahead and no plan. The site's product identity is precise: "Competitors help users plan the trip. We help them live it." Every design, content, and technical decision flows from that positioning.

The result is a 10-page static site — no framework, no build step, no CMS, no server-side logic — that handles live camera streams, a verified venue directory, an interactive map, a localStorage save system, a beach conditions tool, a partner inquiry form, and a monetization layer. It deploys from a folder upload to Netlify, opens anywhere, and passes the same technical standards as a professional medical practice website.

A competitive analysis of the South Padre Island digital space identified a consistent blind spot: every existing platform serves pre-trip intent. Hotels, itineraries, reviews, bookings — all of it assumes a user planning days or weeks ahead. Tiki Tommy Live targets a different behavioral moment entirely. The user is on the island. They have 1–3 hours. They want one screen to answer one question: what should I do right now?

This identity drives every content decision. The homepage H1 isn't "Welcome to South Padre Island." It's "Pick the next move." The six scenario cards don't say "Browse categories." They say "I need food," "I have kids," "I have no car," "I need a rain plan." Those are decision-state triggers. The explore URL parameter system — `?filter=Food`, `?q=family`, `?q=rain`, `?filter=Transit` — means every scenario card, mini-plan link, and condition-board tap navigates to a pre-filtered result. The visitor never sees an empty state or an unfiltered directory. They see the right answer to the question they're in the middle of asking.

The full design system — tokens, components, three responsive breakpoints, focus-visible rules, prefers-reduced-motion — is one minified CSS file. All interactive features are handled by two JavaScript files: `locations.js` (the 20-venue data object) and `main.js` (a 203-line IIFE handling every interactive feature on the site). No React, no build step, no npm, no external dependencies of any kind.

The most important content decision in the project was the data standard. Every venue card carries a "Verified listing" badge with a source label — Official site, SPI Chamber, Visit SPI, Cameron County — indicating exactly where the information was confirmed. Two venues from the original prototype data set were excluded entirely: Pier 19, reported permanently closed after the 2022 fire, and a Taco Cabana Express that couldn't be verified on the island. That decision is documented in `BUSINESS_DATA_AUDIT.md` so anyone maintaining the site knows why those names are missing.

Each of the 20 entries in `locations.js` carries: name, short name, emoji, category, type description, vibe label, best-for summary, image, lat/lng, map pin coordinates, address, phone, website, source, verification status, price note, hours note, crowd note, description, Tiki move tip, tags array, action prompt, Google Maps URLs, and a pre-built search text string for client-side fuzzy matching. This isn't a list of business names. It's a structured data object designed to power every surface on the site — search, filter, map panels, saved cards, and clipboard exports — from one verified source.

Every interactive feature — navigation state, save system, search, filtering, map pins, saved page rendering, clipboard copy, URL parameter hydration — is handled by a single 203-line IIFE. No jQuery. No React. No state management library. No external dependencies.

Every competitor either ignores beach safety utility entirely or links visitors off-site to NOAA, the city transit page, or the official tourism board. A user following those links leaves the site, opens a government page, gets confused, and either comes back or doesn't. The original build of Tiki Tommy Live had the same problem — six utility tool cards linking to `visitsouthpadreisland.com`, `ndbc.noaa.gov`, `myspi.org`, and `southpadre.com`. The solution was to build every utility feature in-house and eliminate every link that left the domain.

The conditions page is public, indexable, and in the sitemap. It's in the desktop nav as a link between Saved and Advertise on every page. It's in every page footer. It's the destination for every homepage and live-page utility link that previously pointed off-site. The condition-board slots on the homepage — previously decorative label displays — are now interactive links to `conditions.html#flags`, `conditions.html#transit`, and `tel:9562434361`. The live site at `ttlnew.netlify.app` confirms all of this working in production.

A visitor can check the beach flag meaning, read the marine forecast, pick an access point, figure out the free bus, or call sea turtle rescue without leaving the Tiki Tommy experience. Every time a user leaves a site to look something up, there's a real probability they don't come back.

Every placement is native to the design — not retrofitted. The business case is visible to stakeholders from the first review without the product feeling like an ad farm to visitors.

A `sponsor-inventory.json` scaffold in `assets/data/` documents all nine placements. A future backend replaces this static file with managed sponsor records, campaign dates, click and impression tracking, slot availability, and creative uploads.

Tiki Tommy Live demonstrates three things in combination that are each harder than they look individually.

First: a product identity held consistently across 10 pages and 203 lines of JavaScript. The "real-time decision engine" positioning isn't a headline — it's the reason every scenario card uses first-person situation language, the reason search results are pre-filtered from the homepage, the reason the conditions page exists instead of linking visitors off-site.

Second: a data standard that earns trust rather than assuming it. Twenty venues verified against official sources. Two excluded because they couldn't be confirmed. Ratings, wait times, and crowd levels marked as pending rather than invented. A `BUSINESS_DATA_AUDIT.md` that documents every exclusion decision so future maintainers understand the standard they're maintaining.

Third: technical execution that survives scrutiny from any audience — UX reviewer, front-end developer, security auditor, product manager evaluating the business model. The site is accessible. The CSP is real and enforceable. The monetization layer is structured. The save system is XSS-safe. The beach conditions tool doesn't link out. None of these things are visible to a casual visitor. All of them are visible to the people who matter.