title: “Wego Meta-Search Blueprint v2 — Competitive Reference Reinterpreted for Product Model v3” category: Competitive Intelligence status: “active” created: 2026-03-09 supersedes:

“…/v1.0/wego-metasearch-blueprint.md”
“…/v1.0/wego-build-blueprint.md” input_source:
“Wego intelligence research”
“Product Model v3.0”
“Flight Booking Platform — PRD v3.0” related:
“./wego-build-blueprint.md”
“…/…/06-product-requirements/v3.0/Product_Model_v3_Flight_Platform.md”
“…/…/06-product-requirements/v3.0/Flight_Booking_Platform_PRD_v3.md” doc_id: “FLYMAX-02-Blueprint-WEGO-METASEARCH-BLUEPRINT” project_name: “FlyMax V2.0” doc_type: “Blueprint” scope: “valid” lifecycle_state: “active” author: name: “George Joseph” role: “Technical Lead / Solution Architect” modified_by:
name: “George Joseph” role: “Technical Lead / Solution Architect” date: “2026-03-09” approved_by:
name: “” role: “” date: “” next_review_date: “2026-03-09” version: “1.0.0” updated: “2026-03-09”

← Section Index · Master Index

[!NOTE] Competitive Architecture Research — Meta-Search Patterns

This document is a competitive reference, not the governing product architecture.

Applicability to Product Model / PRD v3.0

✅ Search aggregation patterns remain relevant

✅ Supplier fan-out, caching, throttling, polling, and deduplication remain relevant

✅ Ranking, transparency, merchandising, and trust patterns remain relevant

✅ Regional UX and localization lessons remain relevant

⚠️ Redirect-led monetization is not our governing business model

⚠️ “Optional checkout later” is not our governing product stance

⚠️ CPC / affiliate click-out economics are not the primary planning lens

⚠️ B2C-only marketplace framing is incomplete for our Admin / Agent / User model

Use this for: extracting proven search-marketplace mechanics from Wego and adapting them to a Verteil-powered, direct-booking, flight retail and servicing platform.

Do not use this for: defining our product identity, deciding current-vs-later scope, or reintroducing redirect-first assumptions.

Wego Meta-Search Blueprint v2

1. Why this v2 exists

The original Wego blueprint was valuable research, but it was written around a meta-search + hybrid checkout interpretation. That framing is no longer sufficient for current planning because the governing baseline has shifted to:

direct booking
on-platform payment
booking lifecycle continuity
agent credit workflows
support ownership
finance-grade reconciliation
Admin / Agent / User operating layers

This v2 preserves the useful competitive learnings while explicitly separating:

Wego truths about how a large flight marketplace works
What our platform should borrow
What our platform must not inherit

2. Canonical interpretation boundary

2.1 What Wego represents

Wego should be treated as a strong reference for:

search aggregation behavior
supplier fan-out economics
progressive result loading
provider comparison UX
ranking and merchandising surfaces
click attribution mechanics
trust and transparency lessons
regional marketplace localization

2.2 What Wego is not for us

Wego should not be treated as the authoritative model for:

our business model
our checkout stance
our support ownership
our KPI hierarchy
our role model
our finance and settlement architecture

Our governing product is not “Wego clone with optional checkout.”
Our governing product is a Verteil-powered direct-booking platform that can still learn from Wego’s search and merchandising patterns.

3. What remains highly relevant from Wego

3.1 Search-session orchestration

Wego’s strongest reusable pattern is the search session model:

create a search session
fan out requests in parallel
accept partial supplier returns
progressively stream results
stop late/low-value returns with deadline-based control

Why it matters to us:
Even in direct booking, the search tier still benefits from:

fast time-to-first-results
supplier cost control
resilient partial availability handling
deterministic result freshness rules

3.2 Supplier scoring and call-budget control

Wego-inspired supplier-plan selection remains valuable. The platform should choose which sources to call based on:

route relevance
supplier health
latency
reliability
mismatch history
competitiveness
contract / market availability

Important v2 correction:
In our model, supplier selection should not optimize mainly for CPC/CPA yield. It should optimize for:

booking success probability
trust and price stability
servicing continuity
operational supportability
commercial eligibility

3.3 Caching, throttling, and deadline management

These patterns remain directly useful:

pre-search cache probe
adaptive throttling
circuit breakers
concurrency caps
hard/soft deadlines
fallback and degraded-mode behavior

These are architecture-grade lessons independent of redirect vs direct booking.

3.4 Results UX and transparency

Wego’s visible strengths in results UX remain relevant:

multi-provider comparison logic
quick sorting modes
price-first scanning
baggage / fare-rule visibility
“best” style ranking
sponsored or boosted placement surfaces
clear visual hierarchy

For our platform, these must be combined with booking continuity, not external-flow leakage.

3.5 Regionalization and localization

Wego demonstrates the importance of regional fit:

localized payments
route-specific merchandising
regional supply bias
regional trust signals
mobile-first UX expectations

That remains relevant to our direct-booking model, especially when payment methods, corporate fares, or servicing behavior differ by market.

3.6 Trust lessons from Wego weaknesses

The original research also surfaced useful caution points:

price mismatch pain
support friction
inconsistent alerting expectations
potential provider-order bias concerns

These are especially important in our model because once we own checkout, we also own the failure surface.

4. What is misaligned and removed from governing use

The following assumptions from the old blueprint are not governing in v2:

4.1 Redirect-first funnel

Old assumption:

search → compare → redirect → attribute revenue

v2 correction:

search → compare → validate / reprice → capture traveler details → collect payment or reserve credit → book → confirm / ticket → manage booking → support / reconcile

4.2 Checkout as optional late-phase add-on

Old assumption:

selective on-platform checkout is a later wedge

v2 correction:

on-platform checkout is part of the governing model now
activation depth may still be rollout-gated, but checkout itself is not a later-by-default capability

4.3 Click-out economics as the primary unit model

Old assumption:

CPC + CPA contribution margin is the primary business lens

v2 correction: Our economic lens should prioritize:

search-to-booking conversion
payment success rate
booking / ticket issuance success rate
offer mismatch rate
support cost-to-resolution
refund / change handling efficiency
reconciliation accuracy
agent credit exposure and utilization
margin after payment / servicing / support realities

4.4 Meta-search-only operating model

Old assumption:

B2C search marketplace with ads and hybrid checkout

v2 correction: The governing role model is:

Consumer / Traveler
Agent / Travel Seller
Agent Sub-User
Admin / Ops
Finance / Reconciliation
Support / Operations
Commercial / Partnerships
Security / Compliance

4.5 “Ads + sponsored placement” as central monetization identity

Old assumption:

ads and click yield are primary monetization levers

v2 correction: Promotions and boosted placements may still exist, but the commercial center of gravity is:

booking-driven revenue
governed markup / discount logic
service fees
credit-led B2B economics
controlled merchandising

5. Mapping table — Wego pattern to our v3 interpretation

Wego-derived pattern	Keep / Adapt / Avoid	v2 interpretation for our platform
Search session + polling	Keep	Core search orchestration pattern
Parallel supplier fan-out	Keep	Still needed for search breadth and performance
Progressive results streaming	Keep	Still needed for conversion and UX
Cache probe before supplier calls	Keep	Still needed for latency and cost control
Supplier ranking by latency / competitiveness	Adapt	Add booking-success, servicing, and trust weighting
Provider comparison modal/list	Adapt	Still useful, but final action is platform-owned booking path
Price re-check at high intent	Keep	Even more important before direct booking
Click attribution engine	Adapt	Still useful for marketing and campaign tracking, but no longer the primary revenue core
Sponsored placements	Adapt	Allowed only with strict labeling and trust governance
Hybrid checkout as optional wedge	Avoid	Direct booking is already part of the governing model
CPC / CPA unit economics model	Avoid as primary	Replace with transaction, payment, servicing, and reconciliation metrics
Meta-search-only product classification	Avoid	Product is now a direct-booking flight commerce platform

6. What this means for actual design decisions

6.1 Search domain

Borrow heavily from Wego:

sessionized search
progressive loading
route-aware supplier planning
cache-first orchestration
deduplication and normalization

6.2 Offer validation domain

Upgrade beyond Wego:

explicit pre-book validation
currency / payment-aware repricing
user-facing changed-offer handling
reliability and trust scoring tied to booking outcomes

6.3 Checkout domain

Do not treat checkout as a bolt-on:

traveler capture
payment authorization / capture state
booking state linkage
failure and retry flows
booking confirmation visibility

6.4 Post-booking domain

This is where our model diverges the most from Wego-style meta-search:

retrieve
modify
cancel
refund visibility
reschedule / change support
ticket and order lifecycle continuity
support case linkage

6.5 Operations domain

Must be first-class from day one of direct booking:

finance reconciliation
credit lifecycle controls
support ticketing
admin approvals
audit logs
provider health monitoring
security-sensitive action tracing

7. Guardrails for future readers

When using Wego research, apply these guardrails:

Do not import redirect-era vocabulary into governing documents
Do not rank features mainly by click-out economics
Do not push support, payment, or servicing into “later” if PRD v3 says they are current
Do not let sponsored merchandising degrade trust or price transparency
Do not use Wego’s B2C-heavy framing to under-model agent and ops capabilities
Do not assume Wego’s “optional checkout” posture matches our model

8. Recommended use of this v2 document

Use this document as a competitive mechanics reference for:

search architecture
supplier planning
results ranking
transparency patterns
SEO and merchandising ideas
marketplace trust lessons

Use the governing PRD and Product Model for:

scope decisions
role model
checkout/payment stance
support ownership
KPI hierarchy
release readiness
finance and operations design

9. Final takeaway

Wego remains a valuable benchmark for how to run the search and merchandising layer of a large flight marketplace.

But for current planning, we should translate that research into a different product identity:

not a redirect-led meta-search engine with optional checkout later
but a Verteil-powered, direct-booking, flight retail and servicing platform that borrows Wego’s search strengths while avoiding Wego-style model drift.

Document ID: FLYMAX-02-Blueprint-WEGO-METASEARCH-BLUEPRINT
Canonical Version: 1.0.0
Lifecycle: Active
Scope: Valid
Source of Truth: docs/
Related Change Ticket:
Last Reviewed On: 2026-03-09
Next Review Due: 2026-03-09

Approval Sign-off

Role	Name	Status
Product Owner		Pending
Technical Lead / Solution Architect	George Joseph	Pending
Engineering Lead		Pending
Commercial / Operations		Pending

Document Lineage

Supersedes:
Superseded By:

Change Log

1.0.0 (2026-03-09) - Header/footer standardized to FlyMax documentation playbook.

Wego Meta-Search Blueprint v2

1. Why this v2 exists

2. Canonical interpretation boundary

2.1 What Wego represents

2.2 What Wego is not for us

3. What remains highly relevant from Wego

3.1 Search-session orchestration

3.2 Supplier scoring and call-budget control

3.3 Caching, throttling, and deadline management

3.4 Results UX and transparency

3.5 Regionalization and localization

3.6 Trust lessons from Wego weaknesses

4. What is misaligned and removed from governing use

4.1 Redirect-first funnel

4.2 Checkout as optional late-phase add-on

4.3 Click-out economics as the primary unit model

4.4 Meta-search-only operating model

4.5 “Ads + sponsored placement” as central monetization identity

5. Mapping table — Wego pattern to our v3 interpretation

6. What this means for actual design decisions

6.1 Search domain

6.2 Offer validation domain

6.3 Checkout domain

6.4 Post-booking domain

6.5 Operations domain

7. Guardrails for future readers

8. Recommended use of this v2 document

9. Final takeaway

Governance Footer

Approval Sign-off

Document Lineage

Change Log