September 2026 · Matan Rabi
Rebuilding flightpowers.com
This site is new. The APIs behind it aren't: they've been live on RapidAPI, serving real traffic, while their own website did almost nothing for them. This post is the honest version of why I rebuilt it and what the new site actually does.
Why the old site failed
Two numbers tell most of the story. Across two domains (the consumer site and the developer site) I had 13 indexable URLs. Companies whose playbooks I studied while planning this rebuild ship hundreds to thousands of pages; I was trying to be found with thirteen.
The deeper problem was what those pages did: they described the product. Paragraphs about live data, about price insights, about round-trip search, and no way to see any of it without leaving for a marketplace listing and signing up. For an API, description is the weakest possible pitch. The response shape is the product. If a visitor can't see JSON, they haven't seen anything.
What the new site does instead
The hero runs real searches. The demo on the homepage sends actual requests to the live API (the same one customers call) behind per-visitor limits and a daily budget cap. When the day's budget runs out, the demo says so and switches to a labelled captured run. It never fakes a spinner into a canned answer.
Every canned example carries its capture date. Anything pre-recorded on this site (fixture responses, example runs, sample outputs) is a real response from a live request, stamped with the date it was captured. If a badge says “captured run · 2026-08-26”, that's a real API response from that day. If there's no badge, it ran live.
Pricing renders from verified listing data. The plans, quotas, rate limits, and overage prices on the pricing page are parsed from the live RapidAPI listings on a stated date and rendered from one config file. There is no number on that page I typed from memory, and a check script fails the build if the listings drift from what the site claims.
llms.txt comes from the same config. The machine-readable summary of the site is generated from the same data that renders the pages, so an AI assistant reading it gets the same facts a human gets, and both get corrected in the same commit.
The rules this site commits to
- No invented metrics. No uptime percentages, no latency claims, no customer counts, no testimonials it doesn't have. Every number traces to the live listings or to the code.
- Labelled captures. Canned output is always marked as a captured run, with a date. Live output is the only unlabelled output.
- Scoped claims. Statements about competitors say what their documentation shows, dated: never “they can't.” Statements about this API say what the code does. Where something has a known limitation, the page says it before you find it.
These aren't virtues I'm claiming; they're constraints I'm publishing so you can hold the site to them. If you catch a page breaking one, tell me and I'll fix the page.
What's next
Intentions, not promises: I want to add per-route pages generated from the API's own data (the one kind of programmatic page only a data API can honestly build), and grow the comparison pages as I collect properly dated sourcing on more competitors. If those ship, they'll show up in the changelog with a date; if they don't, this paragraph stays here as a record of what I thought would happen.