flightpowers.com — the FlightPowers marketing site

The apex marketing site for the FlightPowers travel-data APIs (live Google Flights + Booking.com pricing). Built to the blueprint in the ops workspace's state/gtm/SITE_SPEC.md (2026-08-26). Currently deployed on the Vercel project flightpowers-developers (serving developers.flightpowers.com and the project's *.vercel.app URL); it becomes flightpowers.com via the apex-swap runbook below.

Stack

Layer	Choice
Framework	Next.js 15 (App Router), TypeScript, React 19
Rendering	Static-first — every marketing page is prerendered HTML (force-static); only /api/* is dynamic
Styling	Tailwind CSS v4, CSS-first tokens in src/app/globals.css. Dark-only by design. No component library
Fonts	Inter (body), Space Grotesk (display), JetBrains Mono — via next/font, self-hosted at build
Content	TSX pages + MDX (guides, changelog)
Sitemap	src/app/sitemap.ts walks the route tree; dynamic segments enumerated from their datasets
Hosting	Vercel, deployed by CLI (npx vercel@latest --prod). No git auto-deploy

Architecture

src/lib/
  site.ts        SINGLE source of truth: counts, links (verified 2026-08-26), UTM builder
  pricing.ts     plan tables read from the live listings (READ_ON stamp); perThousand math
  diff.ts        the six verified differentiators — the only feature claims allowed weight
  fixtures.ts    + fixtures/*.json — REAL captured API responses (dated); all canned UI
                 renders from these and is labelled "captured run"
  matrix.ts      the {agent}×{task} dataset behind /integrations/<agent>/<task> (~42 pages)
  snippets.ts    cURL/Python/Node builders for the ApiUpsellCard (key always $RAPIDAPI_KEY)
  demo/
    budget.ts    spend controls (see below)
    upstream.ts  the ONLY module that reads FP_DEMO_KEY ('server-only')
    shapes.ts    the fixed set of query shapes a visitor can trigger
    intent.ts    hero chat: free text → one of the fixed shapes (rule-based, no LLM)
src/app/api/
  demo/          THE one spend route (agent chat + tools share it → shared counters)
  verify-key/    relays a visitor's own key to GET /v1/verify; never logs it
  e/             first-party event beacon → structured lines in the function log

Demo spend controls (the key is a spend surface)

Order of checks in /api/demo: same-origin → response cache (repeats are free) → per-IP daily cap → global daily budget. Costs are priced per shape before anything is spent (a sampled month-scan = ~10 upstream calls and is charged as such). Live results are cached by (shape, params); cached hits are labelled and free.

Honest limitation: counters are in-memory per serverless instance. All spend goes through the single /api/demo function precisely so its instances share fate, but N warm instances still mean up to N× the nominal caps. The numbers are conservative and the demo key's own plan quota is the final backstop. If the demo ever needs exact accounting, move the counters to a durable store (Vercel KV/Redis) — the budget.ts interface is already shaped for it.

• DEMO_PER_IP_DAILY (default 12) — backend calls per visitor per day
• DAILY_BACKEND_CALL_BUDGET (default 400) — global daily ceiling per instance
• Exceeding either → HTTP 429 with honest copy and the RapidAPI CTA. Verified by test.

Environment variables (names only — values live in Vercel envs, never in the repo)

Name	Purpose
FP_DEMO_KEY	RapidAPI key the demo/tools spend server-side. NEVER in the repo, client bundles, logs, or error messages. Only src/lib/demo/upstream.ts reads it
DAILY_BACKEND_CALL_BUDGET	global daily demo budget (mrabi's dial)
DEMO_PER_IP_DAILY	per-visitor daily cap
NEXT_PUBLIC_SITE_URL	canonical origin override (defaults to https://flightpowers.com)

Honesty rules enforced in code

• Every number renders from lib/ config; npm run check-pricing re-parses the live RapidAPI listings, filters visibility === "PUBLIC", fails on drift, and fails FATALLY if a non-public plan name ever appears in the committed table.
• Every canned demo renders from a dated captured fixture and carries a "captured run" badge; the live demo labels live/cached/capped states explicitly.
• No uptime/latency/customer-count claims anywhere. No testimonials (we have none we can attribute). llms.txt is generated from the same config as the pages.

Updating llms.txt (src/app/llms.txt/route.ts)

The pricing, counts, and link tables render from src/lib/, so they can never drift. The Guides and Comparisons sections are a hand-maintained list of - [title](url): description lines, not a scan of src/app/guides/(article)/* or src/app/compare/* — a new guide or comparison page does not appear here on its own. When you ship one:

1. Add one line to the matching section in route.ts, same one-line-description style as its neighbours.
2. Bump LLMS_LAST_UPDATED in src/lib/llms.ts to today's date.
3. curl -s <deployed-url>/llms.txt after deploy and check the new page is listed.

llms-full.txt needs no update for a new guide — it renders only the OpenAPI reference, not the guides/compare index.

Commands

npm run dev            # local dev
npm run build          # must pass clean before any deploy
npm run check-pricing  # live-listing drift check (run before deploying)
npm run predeploy      # check-pricing + build
npx vercel@latest --prod   # deploy (from the repo root; project is linked)

This is the beginning of the README. Read the rest at the original. Read the full README ↗