Every travel search you have ever run ended in someone else's booking engine. The customer, the itinerary, the card details and — critically — the margin all landed in an OTA's database, not yours. If you want to build a travel aggregator that surfaces hotels and flights and actually keeps the relationship, you need to own the commerce layer yourself. That is precisely the gap VBWD fills. It will not sell you inventory, but it will give you everything wrapped around the inventory: search, reservation, checkout, accounts, payments and content, all self-hosted and source-available.

The opportunity

The people who buy from a travel aggregator are travellers looking for a single place to compare and book flights and hotels. The people who build one are founders and agencies who see that the aggregation itself is not the hard part — plenty of suppliers expose fares and room rates through an API. The hard part is turning a search result into a booked, paid, confirmed reservation attached to a customer you can market to again next year. That is a commerce and booking problem, and it is exactly the part most teams underestimate.

What VBWD gives you out of the box

VBWD is a self-hosted, source-available full-stack SDK: one Python backend core, a Vue/TypeScript web front end, plus native iOS and Android SDKs, all driven from the same backend. The core is deliberately agnostic; capabilities are plugins you toggle on without a restart. For a travel aggregator you would lean on:

• shop — model each bookable fare or room rate as a product, with orders, stock and shipping semantics you can bend to seat/room availability. This is your catalogue and search surface.
• booking — appointments, rooms, spaces and seats. This is where a chosen flight or hotel night becomes an actual reservation with dates and occupants, not just a line item.
• subscription — tarif plans, subscriptions, add-ons and checkout, so you can offer a premium traveller tier (fare alerts, waived service fees, member rates) alongside one-off bookings.
• the payment layer — Stripe, PayPal, PromptPay, Mercado Pago, Conekta, Toss, YooKassa and TrueMoney, plus provider-agnostic and non-custodial crypto/stablecoin settlement so funds land in your wallet, not a middleman's.
• cms / cms_ai — destination guides, landing pages and SEO content that pull organic traffic to your fares instead of paying an OTA for it.
• mcp — the platform is MCP-native, so AI travel agents can query your catalogue and place bookings programmatically. As agent-driven travel planning grows, being callable is a real distribution channel.
• RBAC + multi-tenant, an event-driven core with native signed webhooks, discount and referral — the connective tissue for agencies, corporate accounts, promo codes and supplier confirmation callbacks.

The honest boundary

Be clear-eyed about this: VBWD does not supply flight or hotel inventory. There is no fare database, no bedbank, no GDS baked in. You bring the inventory by integrating third-party supplier APIs yourself — a global distribution system such as Amadeus or Sabre for flights, and hotel/bedbank APIs for rooms. VBWD gives you the seams to plug those into: you write an adapter that fetches live availability and pricing from your supplier, maps it onto shop products and booking slots, and pushes confirmed reservations back to the supplier for ticketing or room commitment.

So the division of labour is simple. Your suppliers own the inventory and the fulfilment. VBWD owns the customer, the booking record, the payment and the margin. You write the glue in between. That glue — an inventory adapter and a settlement flow — is the genuine engineering work, and it is work you would have to do anyway on any platform. The difference is that here you are not also re-implementing accounts, checkout and payment reconciliation.

A rough build outline

The core workflow, concretely:

• 1. Integrate a supplier. Build an adapter plugin that calls your GDS or hotel API for live search results. Normalise fares and room rates into a shape your catalogue understands.
• 2. Expose search through shop. Present normalised results as products so the front end can filter, sort and compare — one search box over flights and hotels.
• 3. Turn a selection into a reservation. When a traveller picks a flight or a room, create a booking record carrying dates, passengers/guests and the supplier reference.
• 4. Take payment at checkout. Run the order through the subscription/checkout flow and settle via whichever payment provider — or non-custodial crypto — the traveller chooses.
• 5. Confirm and reconcile. On successful payment, fire a signed webhook to your supplier adapter to complete ticketing or commit the room, then attach the confirmation to the customer's account.

Add-ons follow the same pattern: a premium tier via subscription, referral codes for growth, cms_ai destination pages to feed organic search, and MCP endpoints so external AI agents can run steps 2 through 4 on a traveller's behalf.

Monetization, and why owning it wins

An aggregator makes money in familiar ways, and VBWD supports all of them directly: apply a markup on supplier rates before they hit the catalogue, book commission the supplier pays you, or run a premium subscription for members who get better rates and perks. Because you control pricing at the point where supplier data becomes a product, the markup is yours to set — no marketplace skimming a cut on top.

This is the argument for owning the stack rather than renting one. On a hosted booking platform you are a tenant: you feed their engine, accept their fee schedule, and hand them your customer list. Self-hosted, source-available VBWD inverts that. The booking data, the payment relationship and the traveller's account all live in your infrastructure. You can tune margins, add a payment provider for a new market, or expose an MCP endpoint for AI agents without asking anyone's permission. That the core is genuinely extensible is not a promise — real verticals already run on it, including a tarot app, a dice-market game and a pharmacy shop, each built purely as plugins on the same agnostic core.

Get started

Clone the public SDK and build the supplier adapter against a running stack: github.com/VBWD-platform/vbwd-sdk-public. If you would rather have a production installation stood up for you — multi-tenant, with your suppliers and payment providers wired in — request an enterprise install at vbwd.cc/contact.

VBWD is source-available under BSL 1.1 — free for commercial use while annual VBWD-attributable sales stay under the value of 6.7 BTC per year.

Build a business with VBWD — the series:Mobile game · Travel aggregator (this one) · Marketplace · Booking SaaS · AI assistant SaaS