DEV Community: Bokang Sibolla

I audited the world's biggest hotel platform. Here is what the AI travel agents are being trained to inherit.

Bokang Sibolla — Mon, 01 Jun 2026 00:17:46 +0000

I run Sola, a travel app for people who move differently from the traveller the industry was built for. While building it, I kept hitting the same wall. The data I wanted to query did not exist. Not because nobody collected it, but because the schema underneath the whole industry never had a field for it.

So on 27 May 2026 I sat down and audited Booking.com. The homepage form, the currency selector, a Bangkok search results page. I wrote down what it accepts and what it refuses. Then I looked at the new AI travel agents shipping on top of it.

Here is what I found, and why it matters to anyone building in this space right now.

The form is the spec

Booking.com's homepage search bar accepts exactly four inputs:

A destination, as a single text field
A check-in date and check-out date, as one range
An occupancy counter, defaulting to "2 adults · 0 children · 1 room"
A search button

That is the spec. An online travel agency (OTA) is a CRUD app over this spec, and Expedia, Agoda, and Hotels.com run the same four fields. Airbnb lets you skip the dates. The destination stays a single field everywhere.

Think about what a spec encodes. The default occupancy is a couple. Not a solo traveller, not a parent with one child, not three generations, not seven people eating from one host's kitchen. The form cannot accept a circuit ("Bangkok, then Hanoi, then Jakarta" forces three separate searches). It cannot accept an open date ("October, not sure which week"). It has no field for the part of a trip where you sleep at family but spend money in restaurants.

When you fill that form, you have not searched. You have submitted to a schema. Most of the world's travellers fail the schema before they fail the search.

The data receipts

I am a builder, so I went for counts, not adjectives. Everything below rendered on the platform on 27 May 2026.

Currencies: 52 offered, about 180 in circulation.

Eight currencies sit featured at the top of the dropdown. On the day I ran it the order was EUR, USD, GBP, AED, SGD, AUD, JPY, PHP. The eighth slot is geo-personalised, and the test IP resolved to the Philippines, which bumped PHP up. The other 44 fall alphabetically below: BRL at position 12, EGP at 19, INR at 25, IDR at 26, MXN at 33, ZAR at 45, KRW at 46, THB at 49.

Now the absences. Currencies for these five economies are not in the dropdown at all:

Nigerian naira (220 million people)
Bangladeshi taka (170 million people)
Vietnamese dong (100 million people)
Kenyan shilling (55 million people)
Ghanaian cedi (33 million people)

That is around 580 million people from five countries alone. Add the unverified gaps across the rest of Africa and Southeast Asia and you clear 600 million people who cannot see a hotel price in their own money. They convert in their heads on every search and pay their bank to settle in a currency the platform never asked about.

Filters: 115 items across 22 groups, and the gaps are the story.

A Bangkok search hands you a wall of filters. You can narrow by price per night, property type (hotel, hostel, ryokan, capsule, villa, motel, boat, and more), bedrooms, bathrooms, review score, free cancellation, breakfast, pool, parking, wifi, airport shuttle, star rating, neighbourhood, distance from centre, hotel chain, bed preference, sauna, massage, happy hour, pets allowed, adults only.

You cannot filter for any of this:

Visa requirement
Halal food or hotel certification
Kosher, jain, vegetarian dietary needs
Prayer room or qibla direction
Community-owned or locally-owned property
Women-only floors or women-safe at night
Walking distance to a mosque, temple, synagogue, or church
Public transit access for travellers who do not drive
A family group larger than six

The words "visa," "halal," "kosher," and "prayer" appear zero times anywhere on the audited page. The filter group named "Travel group" exists. Its two options are "Pets allowed" and "Adults only." The category itself tells you what the platform thinks a travel group is.

The default sort is a paid position.

The default sort is labelled "Our top picks." It reads like a recommendation. In mechanism it is an auction. Booking.com charges hotels a base commission of roughly 10 to 25 percent of the room rate, and Genius and Preferred Partner programs add roughly 3 to 5 percent more in exchange for placement. Partner-facing material confirms that visibility tier, commission rate, and conversion data feed the default sort. The top result is the property that pays most and that the platform has the most data on.

Why the schema never gets fixed

This is the part that matters for builders, because it is an architecture problem, not a UX oversight.

An OTA can only offer a filter the underlying data contains. Below Booking sits the Global Distribution System (GDS) layer: Sabre (operational across American Airlines by 1964), Amadeus (founded 1987 by four European airlines), and Travelport. These were built for airlines and travel agents decades before the consumer internet, and they set the data schema for inventory. Visa status is not in the GDS. Halal-friendliness is not in the GDS. Community ownership is not in the GDS.

Then commission economics locks it. To make 10 to 25 percent per booking work, you need volume, and volume needs standardisation. Adding a "community-owned" filter means a two-room guesthouse in Lagos or Jakarta has to enter custom structured data, and it will not do that without payment, and the margin model has no room to pay. The team in Amsterdam can see exactly what is missing. The business model does not let them fix it.

There are only two real exits. Hotels publish richer structured data, which needs a state mandate or platform leverage. Or the platform infers the missing dimensions from unstructured signals: reviews, photos, web mentions, third-party datasets. Booking can build the second one. They have not.

What the agents inherit

On 6 October 2025, OpenAI announced its Apps SDK at DevDay, letting third-party services run inside ChatGPT. Booking.com was a launch partner. The same four fields, now reachable through a chat box.

The agent layer is the next top of the funnel, and here is the trap. The training data is the previous layer's product. The web that large language models read for travel is the Booking, Expedia, Airbnb, TripAdvisor, and Google Travel corpus, in English, with those platforms' defaults baked in. Ship an agent on that dataset and you ship the dataset's defaults. The schema reproduces itself through the training data.

I watched this happen in miniature. Booking added a "Smart filters" panel that takes natural language ("What are you looking for?"). Ask it for a halal-friendly hotel near a mosque and it returns the closest approximation it can express, which is nothing. The AI layer helps you navigate the 115 filters that exist. It cannot surface a filter that does not exist. The model on top is only as good as the schema underneath.

The break is also visible, which is the hopeful part. Agents can infer structured data from unstructured signals in a way an OTA's margin model never could. An agent can read a forum thread, a travel writer's caption, a comment about a women-friendly hostel, and synthesise an answer the filter set could never produce. Whether the next travel layer breaks the schema or repeats it comes down to who builds it, what they train it on, and which traveller they design for.

The builder takeaway

If you are building anything agentic on top of travel data, three things to sit with:

Audit your inputs as a schema, not a feature list. The absences encode who the product was built for. Count what is missing, not what is offered.
Do not let the training corpus pick your defaults for you. Inherited data ships inherited assumptions. The default sort, the currency list, the occupancy counter: someone chose those, and the choice is now in your weights unless you intervene.
The structural opportunity is inference. The whole reason OTAs cannot serve 600 million people is that the data model has no field for them. Agents can build that field from signals the OTA threw away. That is the actual product.

The traveller Booking.com was built for has been served for thirty years. The next default is being designed right now, in the training runs and the system prompts. The four fields were never neutral. Neither is whatever you build on top of them.

Method: findings come from a live walk-through of Booking.com on 27 May 2026, covering the homepage form, currency selector, and a Bangkok results page. Counts and label wording are taken directly from the platform as it rendered that day. Platforms iterate, so specific positions may have shifted. The structural argument does not depend on any single number. I write more on this at the link in my bio, and I run Sola, which is my attempt to build the field the schema is missing.

The information your users need already exists. It's just in 50 different places.

Bokang Sibolla — Thu, 19 Mar 2026 20:45:57 +0000

There's a pattern I keep seeing in the products that actually get traction.

They don't invent new information. They consolidate information that already exists but is scattered, unstructured, and painful to find. Stripe didn't invent payments. They consolidated a fragmented integration nightmare into a clean API. Airbnb didn't invent short-term rentals. They consolidated listings that were scattered across Craigslist, local classifieds, and word of mouth. Notion didn't invent documents, wikis, or project boards. They consolidated three categories of tools into one workspace.

The pattern is the same every time. Valuable information exists. It's just in 50 different places. The product is the consolidation layer.

I want to talk about how we applied this pattern while building a travel product for solo women travelers, because the process taught me something about product development that I think applies way beyond travel.

The discovery phase that changed everything

My cofounder and I met while traveling in Manila. We spent about a year in Poblacion, a neighborhood where travelers pass through on their way to the Philippine islands. During that time we talked to hundreds of women who were traveling alone.

The same frustrations kept surfacing.

One woman had spent three hours the night before in a Facebook group asking whether a specific neighborhood in Bangkok was safe to walk through at night. She got twelve conflicting answers.

Another had a spreadsheet with budget estimates she'd assembled from six different blog posts, three Reddit threads, and a YouTube video. Half the data was from 2019. She was adjusting for inflation manually.

A third told us she always books her first two nights in a new city based on recommendations from other women in a Facebook group that she trusts more than any published source.

The information these women needed to plan their trips already existed. It was in Facebook groups, Reddit threads, personal blogs, Quora answers, WhatsApp messages, and the accumulated knowledge of women who had already been there. But it was scattered, unstructured, ephemeral, and unreliable. A Facebook comment with the right answer disappears into the feed within hours. A Reddit thread from 2022 might be completely outdated. A blog post might reflect one person's experience and nobody else's.

This is the fragmentation problem. And it's not unique to travel.

Why fragmented information is actually a product opportunity

Chris Dixon wrote about this years ago when he described "come for the tool, stay for the network." But I think there's a version of this that's even more fundamental: come for the consolidated information, stay because you can't go back to the fragmented version.

Think about it from the user's perspective. Once you've used a product that gives you structured, reliable, consolidated information in one place, going back to assembling it yourself from 15 sources feels intolerable. You can't un-know that a better way exists.

Elad Gil talks about this in "High Growth Handbook" when he describes how the best marketplace businesses start by aggregating supply that was previously fragmented. The same principle applies to information products. The supply of knowledge exists. It's just fragmented across platforms, formats, and communities. Aggregating it into something structured creates enormous value.

The challenge is that most teams skip the discovery work needed to understand what's actually fragmented. They start with assumptions about what users need, build features based on those assumptions, and end up with a product that solves a problem nobody prioritized.

We almost made this mistake ourselves.

The assumption we nearly built on

The obvious product to build for solo women travelers was a social matching app. Every competitor in the space had built one. NomadHer connects women travelers globally. Tourlina matches travel buddies. Travel Ladies facilitates meetups and hospitality exchange.

The assumption in the market was clear: women traveling alone want to find other women to travel with. Build the matching. Build the chat. Build the events.

But when we actually listened to what women were telling us in those conversations, finding travel companions wasn't the primary pain point. It was a secondary one. The primary pain point was information. Practical, specific, trustworthy information.

Which neighborhood should I stay in? Not which city. Which neighborhood. Is this street safe to walk at night? How much does a private room actually cost in a safe area? What's the transport situation from the airport? Is the night market sketch or fine? Which cafes have good wifi for working?

These questions have answers. Real, specific, factual answers. But those answers were locked up in the lived experience of women who had already been there, shared in ephemeral formats across a dozen platforms, and nearly impossible to find reliably when you needed them.

The product insight was "build the information layer that doesn't exist yet."

Starting with the data model, not the interface

This changed how we approached building.

Most teams start with wireframes. We started with a data model. Because if the core value of your product is consolidated information, the schema is the product. The UI is just a view on top of it.

We spent weeks thinking about how to structure destination information in a way that was useful, queryable, and could grow over time. The data model needed to capture things at the right level of granularity. Not just "Bangkok" but the neighborhoods within Bangkok. Not just "restaurant" but the type of restaurant, the price tier, whether it's in a walkable area, whether solo diners feel comfortable there.

This is a lesson I think more developers should internalize. When you're building an information product, the database schema is the most important architectural decision you'll make. Get it right and every feature becomes easier. Get it wrong and you'll be fighting your own data structure forever.

We use Supabase (Postgres) and spent more time on the schema than on any other part of the early product. Tables for countries, cities, neighborhoods, places, events, community discussions. Foreign keys that create a navigable hierarchy. JSONB fields for structured data that varies by context (budget breakdowns, practical information, safety notes). Full-text search indexes on community content.

The schema reflects how women actually think about trip planning. Not "show me everything about Thailand" but "show me the neighborhoods in Bangkok, then show me the places in those neighborhoods, then show me what other women said about staying there." The data model mirrors the decision journey.

The content layer nobody expected

Here's where something interesting happened that I didn't plan for.

We had built this rich, structured database to power a mobile app. The app was the product. The database was the engine. Standard stuff.

Then we realized we had a distribution problem. All of this structured destination information was trapped inside the app. No search engine could see it. No AI tool could reference it. If someone googled "best neighborhoods in Bangkok for solo women," our data wouldn't appear anywhere in the results. We had the best answer to that question, locked behind an app install.

So we built a static site generator that queries our database at build time and renders each destination as a standalone HTML page. Country pages, city pages, neighborhood guides. Each page is a self-contained reference document with structured data markup that search engines and AI tools can parse.

The database that powered our app now also powered a content site. Same data, different surface. The app serves users who have already found us. The content site brings in users who are searching for answers we already have.

This is something I think more product teams should consider. If your database contains information that people are actively searching for, you're sitting on a content asset. A static site generator (Astro, Next.js, even Hugo) can turn your database into a content moat with remarkably little effort. The data already exists. The queries already exist. You're just connecting them.

Building for machines, not just humans

The other thing that changed our thinking was the rise of AI-generated search results.

When someone asks ChatGPT or Perplexity a question, these tools don't just search the web. They synthesize answers from sources they consider authoritative. Then they cite those sources. Getting cited by an AI tool is the new version of ranking on Google's first page. Except the dynamics are completely different.

Google ranks pages based on backlinks, domain authority, and hundreds of other signals accumulated over years. AI tools rank answers. They look for content that directly, factually, and structurally answers a question. A five-year-old blog from a high-authority domain can lose to a well-structured page from a new domain if that new page answers the question more directly.

Research from Princeton published at KDD 2024 found that three specific content characteristics increase AI citation rates significantly. Content with cited statistics and source attribution. Content with clear, structured answers in the first paragraph. And content with quotable, self-contained factual statements.

This has practical implications for how you write content pages. The first paragraph needs to directly answer the question someone would ask. Then supporting data, structured in a way that an AI tool can extract independently from the rest of the page.

We restructured every page on our content site around this principle. Each page starts with a direct answer to the most likely query. Then structured data sections. Then community context. Then frequently asked questions with schema markup that AI tools can parse.

This is a discipline that feels unnatural for anyone used to writing for humans. Human readers like narrative. AI tools like structure. The trick is finding content formats that serve both. Reference documents work well. Comparison tables work well. FAQ sections work extremely well because they're simultaneously useful for humans and parseable for machines.

What I'd tell developers building information products

If I had to compress everything we learned into actionable advice, it would be this.

Talk to your users before you write a single line of code. Not ten users. As many as you can. Not structured interviews. Conversations. The product insights that matter most are the ones that surprise you. We were surprised that information was a bigger pain point than social connection. That surprise shaped the entire product.

Invest disproportionately in your data model. The schema is the product. If your data is well-structured, features emerge naturally. If it's not, every feature is a fight. Spend the time upfront to model your domain correctly.

Your database is a content asset. If people are searching for information you already have in structured form, build a static rendering layer. The marginal cost of generating web pages from existing data is nearly zero. The distribution value is enormous.

Build for machines and humans simultaneously. Structured data, schema markup, FAQ sections, answer-first paragraphs. They're how you participate in the AI citation layer that's rapidly becoming the primary way people find information.

Consolidation beats creation. You almost never need to create new information. You need to find where valuable information is scattered, understand the structure it should have, and build the consolidation layer. The product is the needle and thread, not the fabric.

We're still early with Sola. Still building, still learning. But the core insight holds up: the most valuable product you can build is often not a new feature or a new capability. It's the structured, reliable, consolidated version of information that your users are already spending hours assembling on their own.

If your users are stitching together answers from 50 different sources, you have a product opportunity. Build the consolidation layer. Structure the data. Make the scattered findable. Everything else follows.

*I'm building Sola, a travel resource for women who explore solo. If you're working on information products or database-driven content sites, I'd love to hear how you're thinking about it.