I recently had the pleasure of connecting with another founder through Travel Massive, stemming from my previous post on defining product-market-fit. Our conversation delved into the exhilarating yet challenging journey of being first-time founders building startups in the travel industry.
One topic that particularly resonated with us was the exploration of Maps APIs.
As we all know, the visual aspect and functionality of maps play a crucial role in travel tools. However, for early-stage startups navigating the MVP or first iteration phase, deciding on the right Maps API can be daunting. Balancing the desire for functionality with budget constraints and the fear of surpassing trial thresholds or entering into costlier plans can be a real dilemma.
I'm sure many of you in the community have faced similar challenges. That's why I'm reaching out to gather insights and perspectives from fellow founders.
What Maps APIs did you consider in the early stages of your startup? What were the pros and cons of each? And what mindset or criteria led you to your final decision?
I'd love to hear about your experiences and any tips or advice you can share.
On a personal note, I thoroughly enjoyed my conversation with @Amine, Founder of Mitrip. Despite our products being competitors, he was incredibly generous in sharing his story and insights. Check them out!
Agree this is a key challenge, I am personally using Google Maps API which has a global coverage, is easy to implement, and overall works pretty well in categorizing the points of interest (ex attraction types, food types, accommodation types, etc), but depending on how you plan to use their API, it can become highly expensive very quickly.
I had a look at OpenStreetMap at the early stages of my product development but I was struggling to correctly categorize the points of interest, which is a key component of my product / value prop. On the other hand, being a free API is definitely something worth considering, if it can meet your specific needs.
I am also exploring another API, HERE technologies (which claims to be better than Google as a location platform). While I haven't tested it out yet and can't really share about its capabilities, I think it's definitely worth looking into it to see if it could meet your needs.
I don't know that what I considered in the early stages of my startup really is relevant any more. Google Maps didn't even exist then :) Our first mapping solution was a custom built Flash map. It did not show trip routes like our current maps do.
I can however share some of the choices made in mapping since then.
Some years ago, Google Maps was a free mapping engine and all was peachy. Then one day they decided to start charging for access and from one day to the next I was looking at a $700/month bill that I could not justify spending on that. The result was a rewrite to use open source mapping technologies.
MapboxGL was the the choice with Maptiler supplying the tiles. Then Mapbox also decided to start charging for loads of their JS making it overnight far more expensive. An open source fork of Mapbox was created - Maplibre - which is what I transitioned to. I'm quite happy with this. I would encourage you to get behind Maplibre rather than one of these commercial systems.
For tiles, I've now ended up mostly switching from Maptiler to Stadia Maps. I had some terrible support from Maptiler and found Stadia to provide better service at a cheaper price so they are now my primary supplier of map tiles.
I hope that helps give some background.
Getting POI data is a whole other game which I've never really managed to work out. I've got my own home-built POI search engine using info from Wikidata but it's very far from perfect and rather out of date now. I'd be dubious about using commercial POI data due to licensing restrictions. I'll follow the discussion to see if anyone has come across anything decent.
I followed a similar way than @daamsie for choosing the map technology behind Famxplor. I decided for Maplibre and Stadia Maps too. This is a great combination and Stadia is relatively cheap compared to others.
For the POI data, I geolocate family travel blog posts with AI and place them on the map. I created an API to expose them.
I wanted to give an update and share something new (to me) I've come across recently. In exploring different Maps APIs, I stumbled upon Apple MapKit JS, which seems surprisingly underrated and rarely mentioned. It was built specifically for web apps and recently had an update to include more POI data (Place IDs) [].
What's particularly appealing, especially for early-stage startups, is the cost-effectiveness compared to Google Maps API. MapKit JS is part of the Apple Developer Program, which costs $100/year. This includes a generous free daily limit of 250,000 map views and 25,000 service calls—quite a relief compared to the concerns of Google's rate limits.
Has anyone here tried it before? How does it compare to other Maps APIs you've used? It's in our backlog, as we have other higher priority tasks at the moment. However, gathering insights and real-world experiences from this community would be incredibly valuable before we dive in.
Hope this brings some new insights to the community and looking forward to hearing your thoughts!
1. What's the ecosystem like around it - eg. for drawing on the map, clustering icons, etc. 2. Licensing - If you want to sell users the option of a printable map, will you be allowed to? Would you be allowed to store and mash up that POI data in other ways? 3. Styling options - as best I can tell, they only have a limited number of map styles.
I'd need to dig in much more to know whether these are real problems or not, but at this stage I still think open source is the way to go.
What Maps APIs did you consider in the early stages of your startup?
was posted by Martin Kwok
in
Discussion,Map,Startup,Travel Tech.
Featured on Apr 16, 2024 (7 months ago).
What Maps APIs did you consider in the early stages of your startup? is rated 5/5 ★
by 1 member.
+ 370 others joined this month
Comments
Hello Travel Massive community,
I recently had the pleasure of connecting with another founder through Travel Massive, stemming from my previous post on defining product-market-fit. Our conversation delved into the exhilarating yet challenging journey of being first-time founders building startups in the travel industry.
One topic that particularly resonated with us was the exploration of Maps APIs.
As we all know, the visual aspect and functionality of maps play a crucial role in travel tools. However, for early-stage startups navigating the MVP or first iteration phase, deciding on the right Maps API can be daunting. Balancing the desire for functionality with budget constraints and the fear of surpassing trial thresholds or entering into costlier plans can be a real dilemma.
I'm sure many of you in the community have faced similar challenges. That's why I'm reaching out to gather insights and perspectives from fellow founders.
What Maps APIs did you consider in the early stages of your startup? What were the pros and cons of each? And what mindset or criteria led you to your final decision?
I'd love to hear about your experiences and any tips or advice you can share.
On a personal note, I thoroughly enjoyed my conversation with @Amine, Founder of Mitrip. Despite our products being competitors, he was incredibly generous in sharing his story and insights. Check them out!
If anyone else would like to chat, I'm more than happy to connect.
Looking forward to some enlightening discussions!
Thanks for the shoutout @Martin!
Agree this is a key challenge, I am personally using Google Maps API which has a global coverage, is easy to implement, and overall works pretty well in categorizing the points of interest (ex attraction types, food types, accommodation types, etc), but depending on how you plan to use their API, it can become highly expensive very quickly.
I had a look at OpenStreetMap at the early stages of my product development but I was struggling to correctly categorize the points of interest, which is a key component of my product / value prop. On the other hand, being a free API is definitely something worth considering, if it can meet your specific needs.
I am also exploring another API, HERE technologies (which claims to be better than Google as a location platform). While I haven't tested it out yet and can't really share about its capabilities, I think it's definitely worth looking into it to see if it could meet your needs.
I don't know that what I considered in the early stages of my startup really is relevant any more. Google Maps didn't even exist then :) Our first mapping solution was a custom built Flash map. It did not show trip routes like our current maps do.
I can however share some of the choices made in mapping since then.
Some years ago, Google Maps was a free mapping engine and all was peachy. Then one day they decided to start charging for access and from one day to the next I was looking at a $700/month bill that I could not justify spending on that. The result was a rewrite to use open source mapping technologies.
MapboxGL was the the choice with Maptiler supplying the tiles. Then Mapbox also decided to start charging for loads of their JS making it overnight far more expensive. An open source fork of Mapbox was created - Maplibre - which is what I transitioned to. I'm quite happy with this. I would encourage you to get behind Maplibre rather than one of these commercial systems.
For tiles, I've now ended up mostly switching from Maptiler to Stadia Maps. I had some terrible support from Maptiler and found Stadia to provide better service at a cheaper price so they are now my primary supplier of map tiles.
I hope that helps give some background.
Getting POI data is a whole other game which I've never really managed to work out. I've got my own home-built POI search engine using info from Wikidata but it's very far from perfect and rather out of date now. I'd be dubious about using commercial POI data due to licensing restrictions. I'll follow the discussion to see if anyone has come across anything decent.
I followed a similar way than @daamsie for choosing the map technology behind Famxplor.
I decided for Maplibre and Stadia Maps too. This is a great combination and Stadia is relatively cheap compared to others.
For the POI data, I geolocate family travel blog posts with AI and place them on the map. I created an API to expose them.
Hey Travel Massive community,
I wanted to give an update and share something new (to me) I've come across recently. In exploring different Maps APIs, I stumbled upon Apple MapKit JS, which seems surprisingly underrated and rarely mentioned. It was built specifically for web apps and recently had an update to include more POI data (Place IDs) [
What's particularly appealing, especially for early-stage startups, is the cost-effectiveness compared to Google Maps API. MapKit JS is part of the Apple Developer Program, which costs $100/year. This includes a generous free daily limit of 250,000 map views and 25,000 service calls—quite a relief compared to the concerns of Google's rate limits.
Apple MapKit JS Overview [developer.apple.com/maps/web/#:~:text=MapKit%20JS%20provides%20a%20free,per%20Apple%20Developer%20Program%20membership.]
Has anyone here tried it before? How does it compare to other Maps APIs you've used? It's in our backlog, as we have other higher priority tasks at the moment. However, gathering insights and real-world experiences from this community would be incredibly valuable before we dive in.
Hope this brings some new insights to the community and looking forward to hearing your thoughts!
Interesting.
Some things too look out for
1. What's the ecosystem like around it - eg. for drawing on the map, clustering icons, etc.
2. Licensing - If you want to sell users the option of a printable map, will you be allowed to? Would you be allowed to store and mash up that POI data in other ways?
3. Styling options - as best I can tell, they only have a limited number of map styles.
I'd need to dig in much more to know whether these are real problems or not, but at this stage I still think open source is the way to go.