Roadmap

What gets built in what order. The sequence is opinionated: infrastructure layers first, then coverage, then the consumer-visible surface. Reversing this order is the most common way projects in this space fail.

The roadmap is a five-year horizon. Specific quarter targets become firm 6 months out and best-effort beyond. The public version at flighthelp.net/roadmap is updated quarterly.

Phase 0: Foundation (months 0–3)

Goal: establish the entity, the team, the funding, the legal structure. Nothing shippable.

  • Incorporate the EU foundation. Pick jurisdiction (most likely NL or DE).
  • Draft and adopt bylaws. Founding board seated.
  • Secure initial funding. Target: one mid-five-figure grant or a small seed pool from aligned donors. Bridge target: 12 months of bare-minimum operating costs.
  • Trademark filings. EU, UK, US, BR, AU initially.
  • Domain registrations. flighthelp.net, flighthelp.org, api.flighthelp.net, contribute.flighthelp.net, docs.flighthelp.net, plus relevant ccTLDs.
  • Team: founder/ED full-time. First engineer hired by month 3.
  • Tools: GitHub org created. Linear (or similar) for project management. Slack or Matrix for internal comms. Status page set up empty.

Outputs of Phase 0: a legal entity, a board, ~12 months of runway, and a team of two.

Phase 1: Infrastructure foundation (months 4–9)

Goal: ship the schemas and the EC 261 rules engine. No data yet. No website yet.

Months 4–6: Schemas v0.1

  • Design the core entity schemas: Airline, Airport, BaggageRule, ContactMethod, Fee, FareClass, Scenario, Regulation.
  • Publish JSON Schema files in flighthelp/schema.
  • Generate TypeScript and Python bindings. Publish to npm and PyPI as 0.1.0 alpha releases.
  • Write full field-by-field documentation.
  • Publish versioning policy.

Months 6–9: Rules engine v0.1 (EC 261 only)

  • Implement EC 261 module: triggers, compensation, exceptions, time limits.
  • Write 100+ test fixtures covering canonical cases, edge cases, and notable court rulings.
  • Build the playground (CLI + web).
  • Publish to npm, PyPI, Composer as @flighthelp/rules-engine 0.1.0.
  • Write full documentation including legal references.
  • Get review from at least three aviation lawyers (volunteer or paid).

Outputs of Phase 1: shippable schemas and EC 261 engine. No consumers yet. No data yet.

Phase 2: Top-20 EU coverage and API (months 10–15)

Goal: ship enough data and the API to be useful.

Months 10–12: Top-20 EU airline data

  • Manually populate full data for the top 20 EU carriers by passenger volume: Lufthansa, Ryanair, easyJet, Air France, KLM, Iberia, TAP, ITA, LOT, Aegean, SAS, Finnair, Wizz Air, Pegasus, Volotea, Vueling, Norwegian, British Airways, Aer Lingus, Brussels Airlines.
  • Per airline: contact methods (phone, X, email, web form), top fees, baggage rules per main fare class, basic scenarios.
  • Set up the moderation queue (even though all early edits go through the founding team).
  • Build the first 10 scrapers for these airlines. Cron them daily.

Months 12–15: Public API v1

  • Implement the REST endpoints described in API.md for the entities populated.
  • Implement GraphQL alongside.
  • Stand up the API on Cloudflare + Fly.io + Neon Postgres + Meilisearch.
  • Implement rate limits, API-key registration, the three free tiers, basic auth.
  • Build docs at docs.flighthelp.net.
  • Implement the /v1/compensation/evaluate endpoint backed by the engine.
  • Publish the bulk dataset snapshot for the first time.

Outputs of Phase 2: a working API serving 20 carriers, with the engine accessible via HTTP and as a library.

Phase 3: Reference site and first design partners (months 16–24)

Goal: prove the infrastructure works in production. Get the first paying customer or design partner.

Months 16–20: Consumer site v1

  • Build the consumer site at flighthelp.net. Next.js, with the page types described in WEBSITE.md but limited to the 20 carriers covered.
  • Implement the contributor PWA at contribute.flighthelp.net. Limited beta: invitation-only.
  • 12 launch languages.
  • Sub-1s TTI target validated on real devices.
  • Public launch on Hacker News, AI newsletters, EU travel-tech press.

Months 20–24: First design partners

  • Identify 3 design partners (one AI lab, one OTA or comparison site, one journalism/research project).
  • Custom-support these integrations through their first 90 days.
  • Publish case studies after each goes to production.
  • Begin charging for commercial-tier API access. First commercial revenue (modest).
  • Expand engine to UK 261 (mostly inherited from EC 261).

Outputs of Phase 3: consumer site live, three integrations live, first commercial revenue, recognized by EU passenger-rights community.

Phase 4: Coverage expansion (months 25–36)

Goal: become genuinely comprehensive on EU + UK + early Brazil, with the contributor community carrying the load.

Months 25–30

  • Expand airline coverage to all 100+ EU/UK/EEA scheduled carriers.
  • Add Brazil ANAC 400 to the rules engine.
  • Recruit 30 trusted contributors actively. Promote first batch of moderators.
  • Build out the contributor PWA fully. Open registration without invite-only restriction.
  • Launch the Reddit-style community forum.
  • Establish translation pipeline. Add 8 more languages (total: 20).

Months 30–36

  • Add Brazilian carrier coverage (top 10): GOL, LATAM, Azul, Voepass, ITA, plus international carriers serving Brazil.
  • Add Montreal Convention to the engine (relevant globally for baggage and international cases).
  • 5+ paying commercial customers across the tiers.
  • First seven-figure foundation grant secured.
  • Hire community manager (paid).

Outputs of Phase 4: 150+ carriers covered, ~3 regimes in the engine, ~1,000 active contributors, ~10 paying commercial customers.

Phase 5: North America and infrastructure maturity (months 37–48)

Goal: serious North American coverage and the operational maturity to handle 10x growth.

Months 37–42

  • Add US DOT tarmac-delay, bumping, and refund rules to the engine.
  • Add Canada APPR to the engine.
  • Populate data for top 30 North American carriers (existing scrapers for the EU-affiliated ones, new for AA, Delta, United, JetBlue, Southwest, Alaska, Spirit, Frontier, Sun Country, Allegiant, Hawaiian, Air Canada, WestJet, etc.).
  • US 501(c)(3) sister entity incorporated.
  • First US grants secured.
  • Hire one engineer specifically for the US work.

Months 42–48

  • North American carrier coverage to 50+.
  • Add Mexico and key Latin American carriers.
  • 20+ paying commercial customers.
  • API moves from /v1 to /v2; /v1 deprecated with 18-month sunset.
  • Reference site updated for v2.
  • Begin annual budget process at €1M+.

Outputs of Phase 5: roughly 250 airlines covered globally, 5+ regimes in the engine, ~5,000 active contributors, ~25 paying commercial customers, ~€2M annual budget.

Phase 6: Asia-Pacific (months 49–60)

Goal: meaningful Asia-Pacific coverage. The hardest geographic expansion because of language, regulatory diversity, and lower current data density.

  • Add India DGCA to the engine.
  • Add Japan civil aeronautics passenger rights.
  • Add China passenger rights (multi-regime, less-systematized).
  • Add Australian Consumer Law passenger protections.
  • Populate top 50 Asia-Pacific carriers (existing scrapers will partially cover them through international codeshare data; new direct scrapers for major Asian carriers).
  • Add language coverage: Mandarin, Cantonese, Korean, Vietnamese, Thai, Indonesian, Tagalog. Brings total to ~30 languages.
  • Establish in-region presence: at least one paid contributor coordinator based in Asia-Pacific.

Outputs of Phase 6: roughly 400 airlines covered, 9+ regimes in the engine, truly global infrastructure.

Years 6–10: Maturity and second-order effects

Beyond month 60, the roadmap is less linear. The project's focus shifts from coverage expansion to:

  • Depth. Filling in long-tail airlines, smaller regulations, edge-case scenarios. Less glamorous than expansion; arguably more important.
  • Tooling. Better contributor tools, better moderator tools, better integration tools.
  • Engine sophistication. Handling multi-regime conflicts more elegantly. Case-law tracking. Regime version bumps as laws are amended.
  • Schema adoption. Pushing for schemas to be referenced by IATA, ICAO, or regional regulators.
  • Federation. Possibly federating the dataset across multiple regional instances (the AGPL license enables this; the operational tools need investment).
  • Sustained governance. Founder rotation. Second-generation core team. Long-term financial reserves.

The work in years 6–10 is what determines whether the project becomes load-bearing infrastructure or remains a useful-but-marginal tool. Most of the failure modes for civic-tech projects happen in this window; most of the structural successes are also locked in here.

What is not on the roadmap

Explicitly excluded:

  • Flight search and booking. The project does not aggregate or sell flight inventory.
  • Live flight status. The data refresh cadence is hours-to-days, not real-time.
  • A claims-filing service. Templates and instructions are provided; the project does not file claims.
  • Hotel, car rental, or activity bookings. Out of scope.
  • AI inference on user behalf. The project does not run LLMs.
  • Mobile native apps. The PWA is sufficient. Mobile native apps are a maintenance burden that doesn't serve the mission.
  • White-label dashboards. The project does not run dashboards for partners.
  • Affiliate revenue. Excluded by Principle 5.
  • Advertising. Excluded by Principle 5.

These exclusions are explicit because well-meaning suggestions to add them appear constantly. The discipline of saying no preserves focus.

How the roadmap changes

The roadmap is updated quarterly. Changes are driven by:

  • Community needs. What contributors and downstream consumers are asking for.
  • Funding constraints. What can be afforded given current and projected revenue.
  • Legal developments. New regulations, court rulings that affect the engine.
  • Technology changes. Sometimes new infrastructure capabilities enable things that weren't worth building before.

The board approves major roadmap shifts. The engineering lead handles within-quarter prioritization. The community influences through public comment, GitHub issues, and the quarterly community calls.

The roadmap is not a commitment in a marketing sense. It is the current best plan, updated as evidence accumulates.