FB
TheDocsFoundryDocumentation

title: “Wego Competitive Architecture Research — Adaptation Blueprint v2” category: Competitive Intelligence status: “active” version: 2.0 created: 2026-03-09 related:

  • “Summary v2”
  • “PRD v3.0”
  • “Product Model v3.0” doc_id: “FLYMAX-02-Blueprint-WEGO-BUILD-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” updated: “2026-03-09”

Wego Competitive Architecture Research — Adaptation Blueprint v2

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

This blueprint analyzes architectural, UX, and operating patterns from Wego’s meta-search platform.

Applicability to v3.0

  • ✅ Search aggregation patterns remain relevant
  • ✅ Supplier fan-out, caching, polling, normalization, deduplication, and ranking patterns apply
  • ✅ Performance, resilience, observability, and supplier-quality ideas are reusable
  • ⚠️ Wego’s dominant model is meta-search / redirect-led; that is not our governing model
  • ⚠️ Our platform must support owned checkout, payment, booking lifecycle continuity, support, credit, reconciliation, and role-based operations

Use this for

  • supplier integration design
  • search/session orchestration
  • performance and caching strategy
  • results UX and transparency patterns
  • competitive benchmarking

Do not use this for

  • redefining the product as redirect-led
  • treating checkout as optional
  • substituting affiliate economics for transaction economics
  • deferring support / finance / servicing obligations

Scope precedence: If any statement here conflicts with PRD v3.0 or Product Model v3.0, the v3 documents take precedence.

Date: 2026-03-09
Input sources: Wego intelligence research, PRD v3.0, Product Model v3.0

1. Why this v2 exists

The original blueprint was useful as competitive intelligence, but it mixed two different things:

  1. What Wego does
  2. What our platform should build

That became misaligned once the product baseline changed from redirect-first meta-search to a Verteil-powered direct-booking platform.

This v2 corrects that by separating:

  • external competitor patterns worth reusing
  • non-transferable competitor assumptions
  • our adapted target architecture under the v3 product model

2. Ground truth: what Wego represents

2.1 What Wego is

Wego is best treated as a meta-search marketplace with hybrid checkout capability:

  • heavy emphasis on search aggregation
  • redirect-led provider choice across airlines and OTAs
  • selective on-platform checkout for some supply
  • strong attention to performance, caching, and monetization surfaces

2.2 Why Wego still matters for us

Even though our product model differs, Wego remains relevant because it demonstrates:

  • how to structure multi-supplier search
  • how to optimize for low-latency result delivery
  • how to normalize and rank heterogeneous offers
  • how to present transparent, trust-building result cards
  • how to think about supplier quality and marketplace instrumentation

2.3 What Wego does not decide for us

Wego does not decide:

  • our primary booking model
  • our payment ownership model
  • our support model
  • our finance and reconciliation obligations
  • our B2B/B2B2C role model

Those are governed by v3.

3. Reusable patterns vs non-transferable assumptions

3.1 Reusable patterns

These can be reused or adapted directly:

Search architecture

  • session-based search orchestration
  • parallel supplier fan-out
  • polling / progressive result retrieval
  • bounded latency budgets
  • cache-first or cache-assisted retrieval
  • normalization and deduplication
  • supplier quality scoring

UX patterns

  • fast time-to-first-results
  • filter-rich results list
  • fare breakdown and baggage visibility
  • best / cheapest / fastest sort modes
  • flexible-date discovery
  • clear handling of price drift

Platform patterns

  • gateway / adapter layering
  • observability by supplier
  • fraud / abuse protection
  • event capture for analytics
  • quality-aware ranking inputs

3.2 Non-transferable assumptions

These must not be adopted as-is:

Business model assumptions

  • CPC / affiliate-first revenue model
  • redirect as the dominant booking completion flow
  • ads / sponsored placement as the primary monetization layer
  • per-search economics as the sole economic backbone

Product scope assumptions

  • checkout being selective or optional
  • support being secondary
  • finance and reconciliation not being core product obligations
  • agent credit / governance being absent or minor

3.3 Required v3 replacements

Replace the above with:

  • direct booking as the default model
  • payment orchestration as a core domain
  • booking retrieval, servicing, and support continuity
  • agent credit, markup, and discount governance
  • finance-grade traceability and reconciliation
  • Admin / Agent / Consumer role segmentation

4. Adapted design principles for our platform

4.1 Preserve the search-grade strengths

From Wego-class systems, preserve:

  1. fast search response
  2. supplier-aware orchestration
  3. normalization discipline
  4. strong results UX
  5. instrumentation everywhere

4.2 Add the direct-booking obligations

Because our platform owns the transaction, add:

  1. repricing / validation before checkout
  2. traveler data capture
  3. payment authorization / capture handling
  4. booking creation and confirmation
  5. booking retrieval and post-booking management
  6. support and finance linkage
  7. credit and approval workflows for B2B use

4.3 Anti-misalignment rule

Any architecture recommendation is incomplete unless it explicitly answers:

  • how payment state is stored
  • how booking state is stored
  • how support can reconstruct the flow
  • how finance can reconcile the event chain
  • how role-based permissions apply

5. Adapted target architecture for v3

5.1 Architecture objectives

Our architecture should optimize for:

  • low-latency search
  • safe transition from search to checkout
  • reliable booking creation
  • lifecycle continuity after payment
  • role-based operational control
  • supportability and traceability
  • supplier extensibility later without requiring it now

5.2 End-to-end architecture

flowchart TB
  subgraph Client
    WEB[Web App]
    AGENT[Agent Portal]
    ADMIN[Admin / Ops Portal]
  end

  subgraph Edge
    CDN[CDN / Edge Cache]
    WAF[WAF + Bot Protection]
    GW[API Gateway]
  end

  subgraph Identity
    AUTH[Auth / Session / RBAC]
  end

  subgraph SearchCore
    SS[Search Session Service]
    ORCH[Supplier Orchestrator]
    CACHE[Search / Offer Cache]
    NORM[Offer Normalization]
    DEDUPE[Itinerary Deduplication]
    RANK[Ranking + Merchandising]
    REPRICE[Reprice / Validation Service]
  end

  subgraph Supply
    ADAPTERS[Supplier Adapter Layer]
    VERTEIL[Verteil APIs]
    FUTURE[Future Providers - Later]
  end

  subgraph Commerce
    CHECKOUT[Checkout Orchestrator]
    TRAVELER[Traveler Data Service]
    PAY[Payment Gateway Integration]
    CREDIT[Agent Credit / Limit Service]
    BOOK[Booking / Order Service]
    TICKET[Ticket / Status Tracking]
    SERVICE[Change / Cancel / Refund Service]
  end

  subgraph Ops
    SUPPORT[Support Case Management]
    RECON[Finance / Reconciliation]
    AUDIT[Audit Log]
    NOTIFY[Notification Service]
    CONFIG[Commercial / Provider Config]
  end

  subgraph Data
    EVENTS[Event Bus / Event Log]
    DWH[Analytics / Reporting Store]
    MON[Monitoring / Alerting]
  end

  WEB-->CDN-->WAF-->GW
  AGENT-->CDN
  ADMIN-->CDN
  GW-->AUTH

  AUTH-->SS
  SS-->ORCH
  ORCH<-->CACHE
  ORCH-->ADAPTERS
  ADAPTERS-->VERTEIL
  ADAPTERS-->FUTURE
  VERTEIL-->ADAPTERS
  FUTURE-->ADAPTERS
  ORCH-->NORM-->DEDUPE-->RANK-->REPRICE

  REPRICE-->CHECKOUT
  CHECKOUT-->TRAVELER
  CHECKOUT-->PAY
  CHECKOUT-->CREDIT
  CHECKOUT-->BOOK
  BOOK-->VERTEIL
  BOOK-->TICKET
  BOOK-->SERVICE

  CHECKOUT-->SUPPORT
  BOOK-->SUPPORT
  PAY-->RECON
  CREDIT-->RECON
  BOOK-->RECON

  AUTH-->AUDIT
  CHECKOUT-->AUDIT
  BOOK-->AUDIT
  SUPPORT-->AUDIT
  CONFIG-->AUDIT

  SS-->EVENTS
  CHECKOUT-->EVENTS
  BOOK-->EVENTS
  PAY-->EVENTS
  SUPPORT-->EVENTS
  RECON-->EVENTS

  EVENTS-->DWH
  EVENTS-->MON
  NOTIFY-->WEB
  NOTIFY-->AGENT

5.3 Interpretation

This architecture keeps Wego-class search mechanics, but the post-search stack is now explicitly extended to cover:

  • checkout
  • payment
  • booking state
  • servicing
  • support
  • reconciliation
  • RBAC-aware operations

That is the essential v3 difference.

6. Search and result architecture patterns to retain

6.1 Search sessions

Retain search-session semantics because they help with:

  • progressive retrieval
  • cache coordination
  • result polling / resumption
  • analytics and troubleshooting

6.2 Supplier fan-out

Retain a controlled fan-out model:

  • choose suppliers based on route / market relevance
  • apply per-supplier concurrency caps
  • maintain route or market-specific allowlists
  • score suppliers by latency, completeness, and failure rate

For our v3 scope, this starts Verteil-first and becomes multi-provider later only when explicitly enabled.

6.3 Caching model

Retain safe caching principles:

  • cache search/session artifacts, not finalized orders
  • attach TTLs by search dimension
  • use cache to reduce duplicate supply calls
  • separate cacheable search responses from non-cacheable payment and booking actions

6.4 Normalization and deduplication

Retain a canonical offer model:

  • itinerary
  • segments
  • traveler price details
  • baggage / fare conditions
  • supplier metadata
  • repriceability / expiry metadata where available

This is foundational for both result display and downstream booking validation.

6.5 Ranking and merchandising

Retain multi-factor ranking, but adapt the business logic. Recommended ranking inputs:

  • total price
  • duration / stops / layover quality
  • baggage and fare conditions
  • historical supplier reliability
  • mismatch / reprice frequency
  • refundability / changeability
  • strategic merchandising rules approved by product / commercial

Do not optimize only for CPC yield; optimize for conversion quality and supportability as well.

7. Direct-booking flow architecture added by v3

7.1 Flow overview

The new governing flow is:

sequenceDiagram
  participant U as User / Agent
  participant UI as Platform UI
  participant S as Search Session Service
  participant R as Reprice Service
  participant C as Checkout Orchestrator
  participant P as Payment Gateway / Credit Service
  participant B as Booking Service
  participant V as Verteil
  participant N as Notification / Support

  U->>UI: Search flights
  UI->>S: Create search session / poll results
  S-->>UI: Ranked results

  U->>UI: Select offer
  UI->>R: Validate / reprice selected offer
  R-->>UI: Confirmed price / conditions

  U->>UI: Enter traveler details
  UI->>C: Start checkout

  alt Consumer payment
    C->>P: Authorize / capture payment
    P-->>C: Payment result
  else Agent credit
    C->>P: Reserve / consume credit
    P-->>C: Credit result
  end

  C->>B: Create booking request
  B->>V: Book / order create
  V-->>B: Booking response / references
  B-->>C: Booking confirmed or failed

  C-->>UI: Confirmation / failure state
  B->>N: Notify + create supportable event chain

7.2 Why this matters

This is the core area where the original Wego-style blueprint was incomplete for our use case.

A search-grade system is necessary but insufficient. We also need:

  • authoritative order state
  • payment or credit state linkage
  • support-visible event history
  • retry / exception management
  • failure-state handling across payment and booking boundaries

7.3 Design requirements introduced by this shift

For every booking attempt, the system must preserve:

  • selected offer snapshot or booking input record
  • validation / reprice result
  • traveler payload version
  • payment or credit event references
  • booking request / response references
  • notification and support links
  • audit trail across actors and systems

8. Support, finance, and governance architecture

8.1 Support as a first-class domain

Support is now required, not optional. The architecture must support:

  • ticket creation linked to booking / payment / credit context
  • threaded case handling
  • internal notes and escalations
  • status / SLA tracking
  • attachment support where needed
  • case history reconstruction from system events

8.2 Finance and reconciliation

The system must support:

  • payment intent / authorization / capture / failure / refund visibility
  • credit reservation / consumption / release / adjustment
  • booking-to-payment linkage
  • booking-to-credit linkage
  • reconciliation exports and exception reporting
  • settlement and refund auditability

8.3 Governance and approval

Architecture must be compatible with:

  • provider enable / disable control
  • commercial rule management
  • markup and discount governance
  • approval-gated capabilities
  • RBAC and SSO / MFA policies
  • audit logging of sensitive actions

9. Observability and resilience

9.1 What remains reusable from Wego-class systems

Retain:

  • supplier latency dashboards
  • cache hit / miss visibility
  • search time-to-first-results and time-to-stable-results
  • partial-failure tolerance
  • orchestration deadlining

9.2 What v3 adds

Also monitor:

  • reprice mismatch rate
  • payment authorization failure rate
  • booking creation failure rate
  • booking confirmation latency
  • cancellation / refund / change exception rates
  • support case rate per booking cohort
  • reconciliation exception rate
  • credit exception rate for agents

9.3 Resilience rule

Do not allow search resilience to hide booking fragility.

A system that delivers fast results but loses traceability at checkout is not acceptable for our model.

10. Economics reinterpretation

10.1 How to use the original economics safely

The original blueprint contained per-1,000-search economics centered around:

  • CTR
  • CPC yield
  • CPA yield
  • supplier API cost
  • contribution margin per search

That remains valid as competitive context for understanding how Wego-class meta-search businesses think.

10.2 Why those economics are not enough for v3

Our business model adds costs and revenue drivers not captured there:

  • markup / service fee realization
  • payment processing fees
  • booking failure / rollback cost
  • refund / servicing operational cost
  • support case handling cost
  • finance and reconciliation cost
  • agent credit risk / working capital considerations

10.3 Adapted v3 economics model

Use a wider transaction model:

Primary revenue drivers

  • markup
  • service fee
  • approved commercial margin
  • governed promotions / sponsored merchandising where enabled

Primary variable cost drivers

  • supplier/API usage
  • payment processing
  • support handling
  • servicing operations
  • refund / dispute handling
  • infrastructure and observability

Primary health KPIs

  • search-to-booking conversion
  • booking success rate
  • payment success rate
  • average contribution per booking
  • support cases per 100 bookings
  • refund / change exception rate
  • reconciliation accuracy

10.4 Practical rule

Use search economics to optimize the top of funnel.
Use transaction economics to govern the business.

11. Competitive moat interpretation

11.1 What still transfers

Wego-style analysis is still useful for identifying possible moats in our space:

  • data moat from search and booking behavior
  • supplier-quality moat from reliability scoring
  • UX moat from strong search and transparency patterns
  • regional or market moat from localization and payment methods
  • operational moat from fast issue resolution and lifecycle continuity

11.2 What changes under v3

For our platform, moat cannot be judged only by traffic scale or ad inventory.

Relevant moat signals now include:

  • booking completion quality
  • servicing continuity
  • support experience
  • finance-grade traceability
  • B2B operational controls
  • market-specific payment and credit fit

11.3 Practical interpretation

We should still study Wego for defensibility patterns, but our moat thesis must be built around:

  • trusted owned checkout
  • strong agent workflows
  • support and servicing reliability
  • controlled commercial governance

12. Capital and staffing interpretation

12.1 Why the old capital view changes

The original blueprint’s staffing view was shaped by a meta-search-heavy stack.
Our v3 model adds additional delivery areas:

  • payment integration
  • booking lifecycle services
  • support case tooling
  • finance / reconciliation logic
  • approval and audit features
  • agent credit and governance workflows

12.2 Implication for planning

Compared with a pure redirect meta-search product, direct-booking v3 typically needs more investment in:

  • backend transaction flows
  • QA around booking/payment edge cases
  • support and ops tooling
  • finance / reconciliation readiness
  • security and audit controls

12.3 Practical rule

Do not reuse headcount or burn assumptions from a redirect-only benchmark without explicitly adding:

  • payment / booking scope
  • servicing scope
  • support scope
  • finance scope
  • B2B control scope

13. Strategic entry interpretation

13.1 What remains valid from the original strategy lens

It is still rational to ask:

  • what wedge makes us competitive?
  • what operational discipline gives us an edge?
  • where do we have unfair advantage by market, distribution, or workflow fit?

13.2 What changes for our platform

A direct-booking platform should not be justified only on classic meta-search economics.

The strategic case must also account for:

  • stronger conversion through owned checkout
  • support continuity after booking
  • B2B/B2B2C monetization and agent enablement
  • commercial control over pricing, credit, and promotions
  • deeper long-term defensibility through lifecycle ownership

13.3 Executive interpretation

Wego remains a valid benchmark for search excellence, but our strategic decision should be based on whether we can operate:

  • a reliable direct-booking experience
  • a supportable and reconcilable transaction stack
  • a governed B2B/B2B2C platform

14. Adapted phased roadmap

Phase 1 — Search + direct-booking foundation

Build:

  • Verteil-first supplier integration
  • search session orchestration
  • caching, normalization, deduplication, ranking
  • repricing / validation
  • checkout orchestration
  • payment and credit baseline
  • booking creation and confirmation
  • booking retrieval / status visibility
  • support ticketing baseline
  • audit and reconciliation baseline

Phase 2 — Operational hardening and commercial controls

Build:

  • richer role segmentation and organization controls
  • governed markups / discounts / promotions
  • enhanced support workflows
  • deeper refund / change / servicing support
  • finance dashboards and exception tooling
  • supplier quality scoring in ranking
  • richer SEO / merchandising surfaces where relevant

Phase 3 — Expansion, not baseline

Build later unless explicitly pulled forward:

  • multiple providers beyond initial Verteil-led supply
  • AI capabilities
  • advanced experimentation layers
  • more aggressive ads / boosted placements
  • advanced forecasting and personalization

This keeps later items aligned with the current v3 guardrails.

15. Decision checklist: how to prevent future misalignment

Before adopting any competitive pattern from Wego or another meta-search platform, ask:

  1. Does it improve search quality or operational resilience?
  2. Does it conflict with owned checkout or booking continuity?
  3. Does it weaken supportability or reconciliation?
  4. Does it assume redirect-led monetization?
  5. Does it bypass RBAC / governance / approval controls?
  6. Is it table-stakes for trust and usability, or only relevant to ad-led economics?
  7. Is it compatible with Verteil-first sequencing and “multiple providers later”?
  8. Can finance, support, and ops reconstruct the flow if it fails?

If any answer indicates conflict with v3, the pattern must be adapted or rejected.

16. Crosswalk: Wego pattern → v3 adaptation

Wego / meta-search pattern Keep / Reject / Adapt v3 interpretation
Multi-supplier aggregation Adapt Keep as search backbone, start Verteil-first
Progressive result streaming Keep Strongly applicable
Search session + polling Keep Strongly applicable
Cache-assisted search Keep Strongly applicable
Offer normalization / dedupe Keep Core domain logic
Best / cheapest / fastest ranking Keep Strongly applicable
Supplier quality suppression Keep Strongly applicable
Redirect-led booking Reject as governing model Replace with direct booking
Selective “hybrid checkout” Adapt Treat as evidence that owned checkout matters; for us it is baseline
Affiliate attribution core Adapt Secondary or integration-specific only
Sponsored ad surfaces Adapt Secondary, governed, non-primary monetization
CPC/CPA-first economics Reject as governing model Use transaction economics as primary
Marketplace-only support expectations Reject Support is first-class in v3

17. Final interpretation

The right way to use Wego is:

  • copy the search discipline
  • copy the performance discipline
  • copy the orchestration discipline
  • do not copy the product model blindly

For our platform, Wego is a strong competitive architecture reference for search and supplier handling.
It is not the governing blueprint for business model, checkout ownership, support, finance, or lifecycle obligations.

That role belongs to:

  • Flight_Booking_Platform_PRD_v3.md
  • Product_Model_v3_Flight_Platform.md
  • Document ID: FLYMAX-02-Blueprint-WEGO-BUILD-BLUEPRINT
  • Canonical Version: 2.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 Date Status
Product Owner Pending
Technical Lead / Solution Architect George Joseph Pending
Engineering Lead Pending
Commercial / Operations Pending

Document Lineage

  • Supersedes:
  • Superseded By:

Change Log

  • 2.0 (2026-03-09) - Header/footer standardized to FlyMax documentation playbook.
Last modified: Mar 9, 2026 by George Joseph (6523ae9)