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.
Top comments (0)