When a new game is announced, the web fills up with answers very quickly—even when the developer has not provided them yet.
I wanted to build something different.
DearPassengers.net is an independent guide to Dear Passengers, an upcoming physics-based co-op airline game from FLEXUS. The site collects the details that have actually been confirmed while giving “not announced” and “not stated” their own place in the information architecture.
It is not the game’s official website, and it is not affiliated with FLEXUS, Valve, or Steam. It is a small experiment in building a useful content product around evidence instead of hype.
The content problem
A newly revealed game creates a predictable set of questions:
- When will it launch?
- How many players does it support?
- Can I play alone or in local co-op?
- Is it coming to consoles?
- Does it support crossplay, controllers, or Steam Deck?
- Is there a demo or playtest?
The official Steam listing answers some of these questions, while announcement footage provides clues about others. Community discussions reveal what people want to know—but they are not a product roadmap.
That led to a simple editorial model:
- Confirmed: explicitly stated by Steam or FLEXUS.
- Observed: visible in official footage, but not promised as a specification.
- Not stated: the current source does not provide an answer.
- Not announced: no official announcement has been found for the feature or platform.
For example, footage may show several crew members, but that does not automatically establish an official maximum player count. A missing console announcement also does not mean a console version has been cancelled.
“We don’t know yet” is still useful information when it is presented clearly.
Turning the model into a site
The project is built with:
- Next.js 14 App Router
- React 18 and TypeScript
- custom, CSS-first responsive styling
- static export for Cloudflare Pages
- a small number of client-side islands for navigation, FAQs, and video selection
Most of the site can be rendered statically. There is no database, account system, or application backend because the product does not need one.
The core build and deployment flow is intentionally small:
pnpm typecheck
pnpm build
pnpm deploy:cf
The production build exports to out/, and Wrangler publishes that output to Cloudflare Pages.
Information architecture before components
Instead of putting every keyword and question on one giant landing page, I split the content by user intent:
- a complete game overview;
- a release-date guide;
- a player-count and multiplayer guide;
- About, Editorial Policy, Contact, and Privacy pages.
The focused pages can answer a narrow question immediately, while contextual links connect them back to the larger guide.
That structure also made the implementation easier to reason about. Each route has a clear primary question, a defined set of unknowns, and its own metadata rather than being another variation of the same generic page.
Trust is part of the UI
I did not want the sourcing rules to exist only in my notes, so the site includes:
- visible verification dates;
- a source ledger that distinguishes first-party material from community discussion;
- an editorial policy;
- a correction channel;
- clear independence and attribution language;
- structured data whose dates and claims match the visible page.
The same thinking applies to SEO. The project includes page-specific titles and descriptions, canonical URLs, Open Graph assets, sitemap and robots files, plus JSON-LD for articles, FAQs, breadcrumbs, videos, the website, and the game.
Schema is not used to invent certainty. If the visible page says a player limit is unknown, the structured data should not quietly imply otherwise.
Designing around the subject
I wanted the site to feel like an airline operations briefing rather than a generic collection of cards.
The visual system uses cockpit-like navy surfaces, warm paper backgrounds, safety-red accents, condensed display type, status boards, manifests, arrivals language, and “cabin feed” video panels. Four short gameplay clips are hosted locally, while the official trailer uses YouTube’s privacy-enhanced embed domain.
The aviation metaphor is mostly presentation, but it also reinforces the content model: every claim should feel like an item on a manifest that can be checked.
What I learned
The most important lesson was that uncertainty can be modeled instead of hidden.
On content-heavy projects, the data model is not always a database schema. Sometimes it is the set of labels and editorial rules that determine what a sentence is allowed to claim.
Static architecture also turned out to be a good constraint. The site stays operationally simple, and client JavaScript is reserved for interactions that materially improve scanning and navigation.
The project is still being refined. I am cleaning up dependencies and documentation, rerunning the full pre-launch checks, and reconciling a few implementation decisions before I consider the build finished.
You can explore the current site at dearpassengers.net.
I would especially appreciate feedback on one question: what is the clearest way you have found to communicate “unknown” without making a product page feel incomplete?
Top comments (0)