The Moment
As the product evolved, I found that the harder decisions were not about building features. They were about choosing what not to build - or more precisely, what not to depend on. There was a point where I started looking at external APIs more seriously. On the surface, this seemed like the obvious next step. Why build everything when there are already powerful services available? But once I went deeper, the reality was more nuanced.
The Tension
The first area was location. Using Google Maps and Google Places felt like the natural choice. The data is rich, the experience is familiar, and it solves many problems immediately. But evaluating it more closely revealed trade-offs. The second area was flight data. At first, I assumed there would be a clear best option. Instead, I found a spectrum of trade-offs. The third area was weather. This felt straightforward at first, but simply adding weather data did not automatically improve the product. Across all three, the challenge was not technical capability. It was deciding what was truly needed, what introduced unnecessary dependency, and what would quietly shape the product in ways I might not want.
What I Did and Changed
I approached each area as an evaluation rather than an integration exercise. For Google APIs, I used them selectively where they improved search and place accuracy, but avoided over-dependence where they would define my product structure. For flights, I evaluated rich aviation APIs, travel platform APIs, and lighter options, and realised there was no perfect choice — only trade-offs between capability, complexity, and cost. For weather, I shifted from thinking of it as a feature to treating it as contextual support embedded in the right place. The key change was moving from asking “what can I integrate?” to asking “what actually improves the experience?”
Google API Evaluation
| API / Option | Strength | Trade-off | Summary |
|---|---|---|---|
| Google Places API | Accurate search and autocomplete | Cost and usage constraints | Best used for input, not as core data structure |
| Google Maps JavaScript API | Rich visual experience | Adds complexity and dependency | Useful selectively, not essential everywhere |
| Google Static Maps API | Lightweight map previews | Limited interactivity | Good balance for simple use cases |
| Google Geocoding API | Reliable location conversion | Additional dependency | Best used as a supporting layer |
Flight API Evaluation
| API / Option | Strength | Trade-off | Summary |
|---|---|---|---|
| Rich Aviation APIs | Detailed data, full coverage | Expensive, complex | Too much for what the product actually needs |
| Travel Platform APIs | End-to-end ecosystem | Setup overhead, constraints | Powerful, but introduces friction |
| Lightweight APIs | Easy to start | Limited reliability or depth | Good for testing, not always for scaling |
Weather API / Weather Approach Evaluation
| API / Option | Strength | Trade-off | Summary |
|---|---|---|---|
| Full Forecast Data | Comprehensive information | Too much for users to process | More data does not mean more value |
| Simplified Weather APIs (for example Open-Meteo) | Lightweight, sufficient accuracy | Less detailed | Enough for decision-making context |
| Standalone Weather Feature | Easy to implement | Disconnect from user flow | Information without context adds effort |
The Insight
The best solution is not always the most powerful one. It is often the one that fits the experience you are trying to create.
Broad Reflection
External platforms are not neutral. When you use them, you also adopt some of their assumptions, constraints, and structure. The real discipline lies in deciding where to leverage them and where to retain control. Often, the hardest decisions are not about what you can build. They are about what you choose not to depend on.