title: “Build Blueprint: Wego-Class Flight Meta-Search + Hybrid Checkout” category: Competitive Intelligence status: Complete created: 2026-02-25 input_source: “Wego intelligence research” related:

• “Wego Intelligence Report”
• “Wego/Skyscanner Mechanics”
• “Supply Strategy — Aggregated Reference”
• “Revenue Acceleration Addendum”

← Section Index · Master Index

Build Blueprint: Wego-Class Flight Meta-Search + Hybrid Checkout (Strategy + Architecture + Economics)

Date: 2026-02-25
Input source: Wego intelligence research (attached document)

This blueprint converts the provided Wego intelligence into a practical “what to build” plan: positioning, system architecture, unit economics, phased strategy, moat scoring, capital needs, and a realistic executive decision.

1️⃣ Positioning Analysis

What exactly is Wego?

Based on the evidence, Wego is a meta-search marketplace for flights with a hybrid OTA checkout layer (“Book on Wego”):

• Meta-search behavior: users see itineraries and then choose among multiple providers (OTAs / airlines) with individual prices.【363:0†Wego intelligence research.docx†L13-L18】
• Affiliate redirect behavior: when “Book on Wego” isn’t available, users are redirected to partner sites with affiliate/UTM parameters.【363:0†Wego intelligence research.docx†L35-L40】
• Hybrid behavior (BoW): “Book on Wego” is an on-platform checkout flow available for some routes/airlines, with localized payment options in GCC markets.【363:1†Wego intelligence research.docx†L19-L19】【367:0†Wego intelligence research.docx†L17-L23】

Meta-search vs hybrid OTA?

• Mostly meta-search: broad OTA presence + redirects dominate user journeys.【363:0†Wego intelligence research.docx†L31-L40】
• Hybrid OTA for select inventory: BoW exists and is promoted; in the provider list it can appear first and may be tagged “Sponsored.”【363:1†Wego intelligence research.docx†L19-L25】

Where is Wego defensible?

Evidence-backed defensibility pillars:

1. Regional moat (MENA/GCC)

• Traffic concentration in Saudi + strong GCC adoption signals regional dominance.【363:16†Wego intelligence research.docx†L11-L16】【371:11†Wego intelligence research.docx†L27-L31】

2. Supply breadth / partner depth

• Evidence shows many OTAs; Wego claims a large partner network (170+ partners in GCC).【363:0†Wego intelligence research.docx†L31-L33】

3. Monetization surfaces embedded in product

• Sponsored banners, in-feed ads, and sponsored provider placement in fare modal are visible in UX evidence.【363:0†Wego intelligence research.docx†L13-L22】【363:1†Wego intelligence research.docx†L27-L31】

4. Modern, scalable backend signals

• Evidence points to CDC pipeline (Postgres → Debezium/Kafka Connect → Redpanda), Kong gateway, AWS infra patterns, microservices hiring signals.【363:7†Wego intelligence research.docx†L5-L13】

Where is Wego weak?

Evidence-grounded weaknesses:

• Price mismatch / customer support friction appear in complaint themes and external forum content.【363:7†Wego intelligence research.docx†L1-L3】
• Product inconsistency: UI shows “Notify me if price drops,” but research states it is not functional and FAQ says price alerts are not offered.【371:0†Wego intelligence research.docx†L12-L14】

2️⃣ Full System Architecture Blueprint

Architecture objectives

• Time-to-first-results fast + progressive completion (skeleton loader → partial results → more results).【363:1†Wego intelligence research.docx†L15-L15】
• Supplier fan-out cost control (timeouts, caching, throttling).
• Marketplace-quality ranking (relevance + price + reliability + yield).
• Closed-loop attribution (click IDs, conversion events, reconciliation).
• Fraud/IVT protection (bot traffic, click spam, partner abuse).
• Data platform (warehouse + price history + forecasting).

Mermaid: End-to-End Architecture

flowchart TB
  subgraph Client
    WEB[Web App]
    APP[Mobile App]
  end

  subgraph Edge
    CDN[CDN / Edge Cache]
    WAF[WAF + Bot Mgmt]
  end

  subgraph API
    GW[API Gateway]
    AUTH[Auth + Session]
  end

  subgraph SearchCore
    SS[Search Session Service]
    ORCH[Search Orchestrator / Polling Controller]
    CACHE[Result Cache (Redis)]
    NORM[Offer Normalizer]
    DEDUPE[Deduplication Engine]
    RANK[Ranking Engine]
  end

  subgraph Supply
    ADAPTERS[Supplier Adapter Layer]
    OTA[OTA APIs]
    AIR[Airl. / NDC APIs]
    GDS[GDS / Aggregators]
  end

  subgraph Monetization
    ADS[Sponsored Placement Service]
    ATTR[Attribution Engine]
    FRAUD[Fraud / IVT Detection]
  end

  subgraph Data
    BUS[Event Bus / Streaming]
    DWH[Warehouse / Lakehouse]
    FEAT[Feature Store]
    FCST[Forecast Engine]
  end

  subgraph OptionalCheckout
    CHECKOUT[Checkout Service]
    PAY[Payment Gateway]
    ORDER[Order Mgmt]
    REFUND[Refund Engine]
    SUPPORT[Support Tooling]
  end

  WEB-->CDN-->WAF-->GW
  APP-->CDN
  GW-->AUTH-->SS-->ORCH

  ORCH<-->CACHE
  ORCH-->ADAPTERS
  ADAPTERS-->OTA & AIR & GDS
  OTA & AIR & GDS-->ADAPTERS-->ORCH

  ORCH-->NORM-->DEDUPE-->RANK-->SS-->GW

  RANK-->ADS
  SS-->ATTR-->FRAUD

  SS-->BUS-->DWH-->FEAT-->FCST
  RANK-->BUS
  ATTR-->BUS

  SS-->CHECKOUT
  CHECKOUT-->PAY-->ORDER
  ORDER-->AIR
  ORDER-->REFUND
  CHECKOUT-->SUPPORT

Latency flow + progressive loading

Use a two-deadline model (soft timeout + hard cutoff), aligned with the evidence that results load progressively and caching is used to speed up similar searches.【363:1†Wego intelligence research.docx†L11-L12】

Suggested p95 budget:

• 0–150ms: CDN/WAF/Gateway/Auth
• 150–250ms: session create + cache probe
• 250–1800ms (soft): parallel supplier calls, stream partial results
• 1800–2300ms: accept late results only if they improve coverage materially

• 2300ms: drop late results to protect UX SLA

sequenceDiagram
  participant U as User
  participant UI as Web/App UI
  participant SS as Search Session Service
  participant OR as Orchestrator
  participant S as Suppliers

  U->>UI: Search
  UI->>SS: POST /search (create session)
  SS->>OR: build supplier plan + budgets
  OR->>S: parallel requests (n suppliers)

  Note over OR: Soft timeout ~1.8s
  S-->>OR: partial results (fast suppliers)
  OR-->>SS: normalized + deduped chunk
  SS-->>UI: chunk 1 (time-to-first-results)

  Note over OR: Hard cutoff ~2.3s
  S-->>OR: late results
  OR-->>OR: accept/reject (coverage/value)
  OR-->>SS: chunk 2 (if accepted)
  SS-->>UI: progressive update

API call optimization logic (cost control)

Core principle: supplier calls/search must be treated as a hard budget (economics are extremely sensitive).

1. Pre-search cache probe

• Cache key: (origin, dest, date bucket, pax, cabin, POS/currency, device)
• If hit: return immediately + start background “refresh” call only for a subset of suppliers.

2. Supplier plan selection

• Pick suppliers based on:
  • route coverage
  • historical latency
  • historical price competitiveness
  • reliability / mismatch rate
  • expected monetization yield (CPC/CPA)
• Implement “supplier score” and keep it updated from conversion + quality signals.

3. Parallel fan-out with throttling

• Concurrency caps per supplier
• Circuit breaker per supplier
• Adaptive throttling when p95 latency rises

4. Dedupe & normalize aggressively

• Canonicalize itinerary (segments, carriers, times, cabin, fare class)
• Deduplicate offers across suppliers (same itinerary) using price delta thresholds.

5. Reprice only at high intent

• On “select provider”, confirm price/availability only for the chosen supplier.
• Log mismatch and downgrade supplier quality score.

Key services (what they do)

• Search Session Service

  • Creates searchSessionId
  • Returns progressive chunks
  • Stores session state and user filters

• Polling/Aggregation Orchestrator

  • Executes supplier plan
  • Enforces timeouts, concurrency, throttling
  • Writes results to cache + emits events

• Supplier Adapter Layer

  • Standardizes disparate supplier APIs
  • Handles retries, mapping, currency conversion
  • Stores supplier-specific error taxonomy

• Ranking Engine

  • Produces different sort modes (Recommended / Cheapest / Fastest)
  • Uses scoring features: price, duration, stops, departure time convenience, supplier reliability, predicted CTR, predicted conversion, margin/yield

• Attribution Engine

  • Generates click IDs
  • Adds UTM/affiliate params to deeplinks
  • Receives conversion events (postback / pixel / s2s)
  • Reconciles bookings to clicks

• Fraud Detection

  • Identifies invalid traffic (bots, click spam)
  • Enforces rate limits and partner anomaly detection

• Warehouse + Forecast Engine

  • Stores searches, impressions, clicks, bookings, prices, and errors
  • Builds price-history & “good deal” signals

• Checkout (optional, hybrid layer)

  • BoW-like on-platform booking for select inventory
  • Requires payment, refund, dispute handling, support tooling

3️⃣ Unit Economics Model (per 1,000 searches)

Variables

• CTR: searches → provider click
• Conversion rate: clicks → bookings
• CPC yield: revenue per click
• CPA yield: revenue per booking (AOV × commission%)
• API cost: calls/search × cost/call × searches
• Infra cost: compute+cache+observability per 1,000 searches
• Contribution: revenue − variable costs

Assumptions (illustrative)

Calculations (per 1,000 searches)

Break-even search volume

Base contribution per search = $27.48 / 1000 = $0.02748.

Break-even (searches/month) ≈ FixedBurn / 0.02748

• $150k/mo → ~5.46M searches/mo
• $250k/mo → ~9.10M searches/mo
• $300k/mo → ~10.92M searches/mo

Base Scenario Revenue vs Cost Breakdown

pie title Base Scenario Economics (Per 1k Searches)
    "API Cost" : 25.00
    "Infra Cost" : 0.80
    "Contribution Margin" : 27.48

4️⃣ Revenue Expansion Strategy (3 phases) + RICE

Phase 1 — Profitable core (MVP)

Objective: reach positive contribution margin quickly.

Build:

• supplier adapters + orchestrator + caching
• ranking v1
• attribution + conversion tracking
• fraud/IVT guardrails
• programmatic route SEO pages

Phase 2 — Revenue acceleration

Objective: raise revenue/search without increasing supplier costs.

Build:

• sponsored placements engine (top banner + in-feed ads)
• partner quality scoring (mismatch suppression)
• experimentation framework (A/B for ranking & ad formats)
• fare calendar / fare guide expansion

Phase 3 — Strategic moat

Objective: compounding advantage and optional checkout.

Build:

• price history + forecast engine (“buy/wait”)
• loyalty + account graph + personalization
• selective on-platform checkout (BoW-like) for high-quality inventory
• B2B insights / data products

RICE scoring (sample)

RICE = (Reach × Impact × Confidence) / Effort

5️⃣ Moat Analysis (score 1–10)

6️⃣ Capital Requirement Estimate

Team size

Phase 1 (MVP, 5–6 months)

• PM (1), Design (1)
• Backend (6–8): search, orchestrator, adapters, ranking, attribution
• Frontend (2–3): web + app shell
• Data (1–2): events + BI
• SRE/Platform (1), QA (1) Total: ~13–18 FTE

Phase 2 (+4–6 months)

• +2 Backend, +2 Data, +1 SRE, +1 QA Incremental: ~6–8 FTE

Phase 3 (checkout, 9–15 months)

• +3–5 Backend (payments/orders/refunds), +2 risk/fraud, plus support operations Incremental: ~10–15 FTE (+ ops staffing)

Infra burn (order-of-magnitude)

Phase 1 (meta-search only): low–moderate
Phase 2 (experimentation + ads + more data): moderate
Phase 3 (checkout + finance ops): high, due to payments, disputes, refunds, reconciliation, support

Time to MVP & breakeven

• MVP (Phase 1): 5–6 months
• Breakeven: typically requires multi-million searches/month (see economics).
  In base scenario, ~$150k fixed burn breaks even at ~5.46M searches/month.

7️⃣ Executive Decision

[!IMPORTANT]

Is entering this market rational?

Only rational under a differentiated wedge. Meta-search economics are volume-dependent and margin-sensitive; without distribution or supply advantage, acquisition costs will dominate.

Realistic entry angles

1. Region-first wedge (MENA/GCC) with an unfair distribution advantage

• e.g., telco, bank, super-app, airline loyalty ecosystem distribution.

2. B2B2C / white-label meta-search engine

• sell the engine + supply + attribution to partners who already own consumer traffic.

3. Checkout only after profitable core

• on-platform checkout increases operational complexity and financial exposure (refunds, disputes, support).

Appendix: Evidence list (from the attached intelligence doc)

• Progressive loading + caching statements【363:1†Wego intelligence research.docx†L11-L12】【363:1†Wego intelligence research.docx†L15-L15】
• Affiliate redirect mechanics【363:0†Wego intelligence research.docx†L35-L40】
• BoW payment localization【367:0†Wego intelligence research.docx†L17-L23】
• Sponsored ad placements and “Sponsored” provider bias【363:0†Wego intelligence research.docx†L13-L22】【363:1†Wego intelligence research.docx†L19-L25】
• Tech stack signals (CDC, Kong, AWS)【363:7†Wego intelligence research.docx†L5-L13】

Quick Flashcards