Opening Reflection
Before there was any intelligence in ToGoStory, there were APIs.
Not AI APIs. The ordinary kind. Maps that returned coordinates. Place searches that returned names and addresses. Weather calls that returned temperature ranges and rain probabilities. Flight lookups that returned departure times and airport codes.
For a long time, this was the work. Learning what data existed, what it cost to access, how to structure it once it arrived, and how to make it useful inside a product someone might actually want to use. There was nothing intelligent about it. It was mostly plumbing.
But that plumbing turned out to matter more than I expected.
By the time I started thinking seriously about AI, the product already did things. Trips had dates. Days had cities stamped on them. Activities had times and locations. Places had coordinates and type metadata. The itinerary had a shape. A traveller looking at their trip could see what they had planned, in what order, across which cities, with weather context sitting underneath each day.
It was functional. Not flashy, but real.
The Foundation
APIs create something that is easy to underestimate: structure.
When you connect to a maps API, you are not just pulling in images. You are establishing a contract about what a location is. A place has a name. It has coordinates. It belongs to a city, which belongs to a country. These relationships become the skeleton of the product.
When you add weather, the same thing happens. A day has a date. That date belongs to a location. That location has a historical and forecast temperature range. Suddenly the product knows something real about conditions at the time of travel.
When you build itineraries, the structure deepens further. A trip spans a range of dates. Each date contains activities. Activities have timings and categories. Places within the itinerary have coordinates that can be measured against each other.
None of this required AI. It required care. Careful thought about what data meant, how it should relate, and what a traveller might actually need to know. By the time the bones of the system were in place, the product had operational integrity. Dates were trusted. Cities were consistent. The flow of a trip made sense from start to finish.
That integrity was not an accident of the APIs. It was the result of choosing to understand them properly before moving on.
The Shift
The AI came later. And what surprised me was how quickly it became useful.
Not because the model was exceptional. But because it had something to work with.
When the helper started reading trip context, it was not reading vague intent. It was reading a specific trip, with specific dates, specific cities in a specific order, specific activities with specific times, and saved flights with departure and arrival details. The structure that had been built through months of API integration was now the foundation for everything the AI could reason across.
This changed what the AI could do. It could understand the flow of the itinerary because the itinerary had a flow. It could connect nearby activities because places had coordinates. It could summarise a trip because the trip had a clear, structured shape. It could reduce cognitive load because it understood what was already planned and what was still open.
It could suggest a pick-up time for an airport transfer, factoring in the flight departure time stored in the database, without asking a single clarifying question.
The AI did not become magical because it became smarter. It became magical because it finally had meaningful context.
What Changed My Thinking
Many of the most interesting AI products I have seen follow the same pattern: start with the model, then try to add context. The thinking goes that the intelligence is the hard part, and the data will follow once the AI is in place.
I understand the appeal. Models are compelling on their own. A well-prompted language model can produce something impressive in minutes. It is easy to mistake that early impression for the real thing.
But I kept noticing a ceiling. Without structured data underneath, the AI cannot be specific. It can be plausible. It can be fluent. But it cannot be accurate about this trip, this traveller, these cities, this timing. The more I built, the clearer it became that the intelligence was only as useful as the information it had access to.
The stronger approach, at least in product terms, may be to reverse the sequence. Build useful systems first. Establish reliable data flows. Make the product work without AI entirely. Then allow the intelligence to sit above those systems as an adaptive, contextual layer.
This is not a slow path. It is a different kind of ambition. One that treats structure as a prerequisite, not an afterthought.
The Insight
AI alone can feel impressive for a few minutes. But AI grounded in real systems becomes genuinely useful. The intelligence is not the product. The product is the system. The AI is what makes that system feel alive.
Broad Reflection
The strongest AI experiences are not the ones that start with the model. They start with operational clarity. A system that knows what it knows, stores it properly, and can make it available to an intelligence layer at the right moment.
That clarity comes from product thinking. From asking not what the AI can do, but what the user needs to do, and then building the systems that make both of those things possible at once.
Travel is a useful lens for this because it is genuinely complex. Trips involve dates, cities, transport, accommodation, timing, weather, and a hundred small decisions that accumulate into an experience. Getting all of that into a coherent structure is work. Real work. But once it is there, even a relatively simple AI layer can become surprisingly valuable.
The lesson I take from this is not that AI requires more training data or more sophisticated models. It is that AI requires structure. Reliable systems. A product that knows what it is doing before it asks the intelligence to help.
Build the foundation first. Then let the intelligence rise from it.