Go to Market

How adoption happens for an open-infrastructure project whose customers are builders, not travelers. The center of gravity is B2B and DevRel, supported by foundation fundraising. The consumer site exists as proof-of-work, not as the acquisition channel.

This document is strategic. It assumes the build sequence in ROADMAP.md has produced a working schema, a usable EC 261 engine, populated data for the top-20 EU carriers, and a functioning API by end of year 1.

The customer is a builder, not a traveler

The first and most important reframing. A traditional consumer site grows by reaching travelers; flighthelp grows by reaching the people who build the products travelers use.

Builders are reachable in different ways than travelers. They:

  • Read technical blogs and Hacker News, not travel content
  • Search for solutions to integration problems, not destinations
  • Make purchase decisions over weeks or months, not minutes
  • Need documentation, examples, and reference implementations to evaluate
  • Are convinced by other builders, not by marketing

Every go-to-market motion described below targets this audience.

Six target builder segments

In priority order based on combination of fit, urgency, and revenue potential.

Segment 1: AI labs and assistants

The newest and most strategically important. Every major AI lab is currently shipping products that answer travel questions, and every one of them is hallucinating about airlines, baggage allowances, contact methods, and passenger rights. They are actively looking for grounded, citable factual data they can integrate via retrieval augmentation.

Why they buy now:

  • Hallucinations on travel questions are a known quality issue with high user visibility
  • Travel is one of the most-asked categories in consumer AI assistants
  • Their users explicitly ask for source-citable answers
  • The labs cannot maintain this data themselves; it's not their competence
  • The schemas-as-standard play is most compelling at this segment

How to reach them:

  • Direct outreach to product teams at OpenAI, Anthropic, Google, Perplexity, Mistral, the Chinese labs
  • Technical write-ups demonstrating hallucination reductions with flighthelp grounding
  • Sample integrations published as case studies
  • Conference talks at AI conferences (NeurIPS, ICLR-adjacent industry tracks, dev-focused gatherings)
  • Strategic partnerships announced jointly

What they pay for:

  • Volume API access (likely Gold or Platinum tier)
  • Webhooks for cache invalidation
  • Bulk dataset access for retrieval augmentation indexing
  • Custom integrations (likely Platinum)

Realistic timeline: First design partner integration by year 1.5. Two major lab integrations by year 3.

Segment 2: Online travel agencies and meta-search

The natural fit. OTAs and meta-search engines already display airline information; the data they show is frequently wrong or stale. They have engineering teams who can integrate. They have product teams who care about reducing customer-service load.

Why they buy:

  • Customer-service costs from wrong policy information are substantial
  • Showing accurate baggage allowances at point of sale reduces post-booking surprises
  • Adding a rights-information layer differentiates them
  • Their existing data sources are expensive and incomplete

How to reach them:

  • Direct outreach to PMs at Booking Holdings, Expedia Group, Kayak, Hopper, Skyscanner, Trip.com, Despegar
  • Speak at industry events: Phocuswright, Skift Global Forum, Travelport Live
  • Trade press coverage in Phocuswire, Skift, Travel Weekly
  • Co-marketed case studies after design partner integrations

What they pay for:

  • Bronze to Silver API tiers initially; Gold as they scale usage
  • Custom data exports for their internal data lakes
  • Webhook subscriptions for policy change alerts

Realistic timeline: First design partner by year 2. Five major OTA integrations by year 4.

Segment 3: Corporate travel platforms

The strongest fit on a per-customer basis, even if smaller in absolute count.

Why they buy:

  • Duty-of-care obligations require accurate, current information about traveler rights
  • Corporate travelers have higher expectations than leisure
  • Disruption response is a core feature of corporate travel
  • The buyers (procurement at large enterprises) are willing to pay for SLAs and support

How to reach them:

  • Direct outreach to product teams at TripActions/Navan, Amex GBT, BCD, CWT, SAP Concur, TravelPerk, Egencia
  • Sponsor relevant tracks at GBTA Convention
  • White papers on duty-of-care infrastructure
  • Speaking opportunities at corporate-travel industry events

What they pay for:

  • Silver to Gold tiers
  • SLAs they can put in their own enterprise contracts
  • Custom support contracts (potentially Platinum)

Realistic timeline: First design partner by year 2.5. Three major corporate-travel integrations by year 4.

Segment 4: Travel insurance and disruption insurance

The cleanest "automation of claims eligibility" play.

Why they buy:

  • Disruption-insurance product economics depend on automated claim eligibility
  • Manual review costs are the largest variable cost in disruption-insurance economics
  • The rules engine's legal citations make underwriting defensible
  • A versioned engine lets them pin to specific interpretations for policy terms

How to reach them:

  • Direct outreach to product teams at Allianz Travel, AXA, World Nomads, Squaremouth, the new wave of disruption-only insurers (Freebird, AirHelp Plus disruption coverage, BlueRibbonBags)
  • Insurance industry conferences (InsureTech Connect, ITC Vegas, Insurance Innovators)
  • White papers on automated claim eligibility

What they pay for:

  • Bronze to Silver tiers, growing
  • Custom enterprise contracts for SLA, support, and dedicated webhook delivery
  • Engine version pinning agreements

Realistic timeline: First insurance partner by year 2.5. Three to five by year 5.

Segment 5: Existing claims companies

The most counterintuitive segment — but a real one once the project has credibility.

Why they buy (eventually):

  • Their internal compensation logic is expensive to maintain
  • It's frequently incorrect in ways that lose them claims
  • An open audited engine is more defensible in court than their private one
  • The schema layer makes their data ingestion cheaper
  • Strategic positioning: showing they use the neutral public engine improves their consumer trust

Why they don't buy initially:

  • Project's existence is partially adversarial to their margins
  • Internal pride in their own engineering
  • Concern that adoption legitimizes a free competitor for their data

How to reach them:

  • Slow burn. Don't lead the segment.
  • After 12–24 months, when AirHelp, Flightright, ClaimCompass, AirAdvisor see other commercial consumers integrating, the calculus shifts.
  • Quiet conversations with their engineering teams (often more receptive than their business teams)
  • Adoption by an industry-adjacent player (a corporate travel platform with claims-handling) opens the door

What they pay for:

  • Likely starting Silver, going Gold
  • Custom engine version pinning
  • Possibly co-developed engine extensions for specific edge cases

Realistic timeline: First claims-company integration by year 3.5. Two to three by year 6.

Segment 6: Journalism, research, government

The smallest in revenue, but the most important for credibility and grant-fundability.

Why they integrate (mostly use the free tier):

  • Citable factual source for investigations
  • Historical snapshots for time-series analysis
  • Source for academic papers on consumer protection
  • Reference for regulatory policy work

How to reach them:

  • Cultivate relationships with travel journalists at major outlets (NYT travel desk, WSJ, FT, The Economist, AFP, Reuters travel)
  • Provide tip sheets and data extracts for investigations
  • Sponsor or co-author academic papers on passenger rights
  • Outreach to regulator staff (DG MOVE, US DOT, ANAC, DGCA)
  • Conference talks at academic and policy venues

Revenue: Mostly free or non-profit tier. Indirect value: credibility, grant alignment, citation visibility.

DevRel strategy

The center of builder acquisition.

Documentation as marketing

The docs at docs.flighthelp.net are the most important marketing asset. They need to be:

  • Complete (every endpoint, every schema, every engine function)
  • Fast to read (information-dense, no fluff)
  • Honest (limitations stated; not everything is presented as perfect)
  • Searchable (full-text search across all docs)
  • Versioned (docs for older API versions remain accessible)

Specific docs that matter:

  • Quick start (5 minutes): Get your first response in 5 minutes flat
  • Integration recipes: "How to ground your AI assistant's travel answers," "How to add disruption rights to your OTA," "How to automate claim eligibility for travel insurance"
  • Code samples: In every supported language, runnable, tested
  • Migration guides: From AirHelp's free API, from competitor sources

Open-source presence

Active on GitHub. Issues responded to within 24 hours during the workweek. PRs reviewed within 72 hours. A monthly "community update" issue summarizing recent changes and inviting contribution.

Conference and meetup presence

Year 1: speak at 4–6 conferences across travel-tech, AI, and open-source tracks. Year 2+: increase to 8–12 talks per year, with the executive director, engineering lead, and contributing community members all speaking.

Target events:

  • Travel-tech: Phocuswright Conference, Skift Global Forum, Aviation Festival, Travelport Live
  • AI / dev: AI Engineer Summit, FOSDEM, OpenInfra Summit, regional AI meetups
  • Open data / civic tech: Mozilla Festival, csv,conf, EU Open Source Policy Summit
  • Aviation industry: WTM London, ITB Berlin

Content marketing (limited)

The project does not run a content farm. It publishes:

  • 1–2 long-form blog posts per month, all substantive
  • A monthly newsletter summarizing changes
  • Annual "state of passenger rights" report (highly cited, traffic-driving)
  • Periodic deep-dive investigations (e.g., "How EU carriers handle their EC 261 obligations: a year in the data")

No SEO content farm. No "10 things you need to know about flying." No listicles. The site's SEO comes from the reference data, not from content marketing.

Builder community

A Discord or community forum where builders can ask integration questions, share solutions, and influence the roadmap. Active moderation by paid staff. Quarterly community calls open to anyone.

The community functions as a force-multiplier for support: many integration questions get answered by other builders before staff sees them.

Foundation fundraising

Parallel motion to commercial revenue. See ECONOMICS.md for the detail. The high-level GTM for grants:

  • A small team focused on grant pipeline (the executive director plus a fractional grant writer)
  • Continuous applications, not panicked bursts
  • Cultivate program officers at target foundations through 1:1 meetings and demonstration of progress
  • Co-fund cycles: identify funders who often co-fund with each other and approach them together
  • Sequence wisely: start with smaller faster grants to build a track record, then go larger

Cold-start strategy

The hardest moment is years 1–2 when the dataset is partial, no commercial customers are integrated, and the project is unknown to most builders.

The seed approach

Pick one regime (EC 261) and one geographic focus (Europe). Achieve excellence there. Use that excellence to:

  • Be cited in EU passenger-rights journalism
  • Be referenced in EU passenger-rights policy work
  • Be the obvious reference for any EU-focused integration

EU focus is strategic because:

  • EU has the most-developed passenger-rights law
  • EU has the most-mature claims industry to convert
  • EU has the most foundation funding for civic-tech
  • EU institutional respect for open data is real (EU PSI Directive, INSPIRE Directive)
  • The Brussels Effect makes EU positioning globally useful

After EU mastery (probably year 2–3), expand to UK (already done as a byproduct of UK 261), then Brazil (ANAC 400), then North America, then Asia.

Design partner integrations

Identify three integrations in year 1 that demonstrate the infrastructure:

  • One AI lab (likely smaller-than-OpenAI for first proof; e.g. a regional EU lab or a developer-facing AI startup)
  • One OTA or comparison site (likely mid-sized European OTA willing to publicly endorse)
  • One journalism or research user (e.g., a consumer-rights research project at a European university)

These integrations are concrete proof that the API works in production. Their stories become case studies. Their endorsements become trust signals.

The design partners get early access, white-glove support, and influence over the roadmap. They pay normal commercial rates once they go to production; the relationship begins as a partnership, not as a paid sales contract.

Word-of-mouth in the EU passenger-rights community

The community of people who care about EU passenger rights — consumer-rights NGOs, claims-company employees who are frustrated with their employer, aviation lawyers, regulator staff — is small and connected. Doing high-quality work here gets noticed within months. The project should not under-invest in this community.

Specific tactics:

  • Sponsor or participate in EU passenger-rights conferences
  • Build relationships with national enforcement bodies (the DG MOVE-designated National Enforcement Bodies under EC 261)
  • Become the obvious source for EU passenger-rights data when journalists or researchers ask
  • Quietly support the consumer-protection legal community

Anti-patterns to avoid

Don't pitch travelers. Travelers don't buy enterprise data. Reaching travelers does not produce revenue.

Don't run paid traffic to the consumer site. Even if it could boost contributor numbers, paid acquisition of consumer-site traffic does not build the infrastructure adoption that matters.

Don't optimize for vanity metrics. Site traffic, social-media follower count, page views — these are not the metrics. The metrics that matter are: design partner integrations, API usage by named customers, commercial revenue, foundation grants secured, citations in journalism and academic work.

Don't undersell the infrastructure. This is not a "free open-source thing." It is critical infrastructure. Charge appropriately for commercial use. Don't apologize for the pricing.

Don't compromise on principles for revenue. A claims company will eventually offer to pay for editorial preference. An OTA will offer to pay for ranking. The answer is no, even if it's the largest contract on the table. The project's value depends on the non-compromise.

Don't promise what isn't built. Schemas and engine first. Coverage second. Don't pitch product capabilities that aren't yet in production. The credibility loss from a missed promise is years to recover; the revenue gained from over-promising is short-term.

Measurement

Numbers the project tracks (and publishes quarterly):

  • Number of registered API keys (free + paid)
  • Monthly active API consumers
  • Total monthly API calls
  • Number of paying commercial customers
  • Monthly commercial revenue (broken down by tier)
  • Grant pipeline value and conversion
  • GitHub stars across the org
  • Number of contributors across all repos (data + code combined)
  • Number of citations in journalism and academic work (manually tracked)
  • Schema adoption (downloads, npm/PyPI/Composer install counts)
  • Reference site traffic (a secondary metric)

Targets at year 3:

  • 5,000+ registered API keys
  • 50+ paying commercial customers
  • $1M+ commercial revenue
  • $500K+ grant revenue
  • 50K+ GitHub stars
  • 100+ academic and journalism citations

These targets are aggressive but consistent with how comparable open-infrastructure projects have grown (OpenStreetMap, Open Food Facts, Crossref, schema.org).