hckrnws
Launch HN: Voygr (YC W26) – A better maps API for agents and AI apps
by ymarkov
Hi HN, we’re Yarik and Vlad from VOYGR (https://voygr.tech/), working on better real-world place intelligence for app developers and agents. Here’s a demo: https://www.youtube.com/watch?v=cNIpcWIE0n4.
Google Maps can tell you a restaurant is "4.2 stars, open till 10." Their API can't tell you the chef left last month, wait times doubled, and locals moved on. Maps APIs today just give you a fixed snapshot. We're building an infinite, queryable place profile that combines accurate place data with fresh web context like news, articles, and events.
Vlad worked on the Google Maps APIs as well as in ridesharing and travel. Yarik led ML/Search infrastructure at Apple, Google, and Meta powering products used by hundreds of millions of users daily. We realized nobody was treating place data freshness as infrastructure, so we're building it.
We started with one of the hardest parts - knowing whether a place is even real. Our Business Validation API (https://github.com/voygr-tech/dev-tools) tells you whether a business is actually operating, closed, rebranded, or invalid. We aggregate multiple data sources, detect conflicting signals, and return a structured verdict. Think of it as continuous integration, but for the physical world.
The problem: ~40% of Google searches and up to 20% of LLM prompts involve local context. 25-30% of places churn every year. The world doesn't emit structured "I closed" events - you have to actively detect it. As agents start searching, booking, and shopping in the real world, this problem gets 10x bigger - and nobody's building the infrastructure for it. We recently benchmarked how well LLMs handle local place queries (https://news.ycombinator.com/item?id=47366423) - the results were bad: even the best gets 1 in 12 local queries wrong
We're processing tens of thousands of places per day for enterprise customers, including leading mapping and tech companies. Today we're opening API access to the developer community. Please find details here: https://github.com/voygr-tech/dev-tools
We'd love honest feedback - whether it's about the problem, our approach, or where you think we're wrong. If you're dealing with stale place data in your own products, we'd especially love to hear what breaks. We're here all day, AMA.
I also have been brewing a similar idea only in my head. But mine is for the local Korean market. Google maps is simply not reliable. Korean people rely on Naver map or Kakao map, who do not even provide APIs. Users are locked up with these local services. They may launch their own mediocre AIs to help the search, who knows in a few years. But then it's going to be too late. I think they should just open up APIs and let developers explore.
What is worse is a huge number of tourists should also use these local services whose translation is not in place. Soon enough, people will ask their AI assistants which restaurants to try out when they plan a visit to Korea. I can see that there is huge opportunity here. Kudos to Voygr team. Fingers crossed.
That is a very interesting insight and thanks for sharing it. We realize that some countries might be having poor maps data, and that example is very helpful - we will take a look
I looked for their APIs not long time ago, which I said non-existent. If you'd like to work with me, I am open to work. If you simply want to talk to me, just drop me an email. I will also checkout your dev tool if I can apply it here.
Bog-standard LLM mapping is terrible and I recently added Google Maps to my personal agent to remediate this.
I'd love to try Voygr for fun. Is there a skill defined that I could just swap in Voygr
Google also doesn't tell you if a place exists - it just returns the list of possible places which it thinks could be relevant. We have instructions defined for agents to onboard https://github.com/voygr-tech/dev-tools
Really cool! We're currently using map and web searches in our agent to gather this info for our tool. Does it support an approximate address? For example, if a plaza can have multiple street numbers, do I need to make a request for each possible address or would it find a certain business with an approximate address?
Thanks! Our initial API works as follows - you provide POI/business name and its address and we are telling you if it exists or not. So if you are looking to check if the plaza is existing, you just need to provide its supposed address. If it is a business within plaza, then an address of that business is required
Let me rephrase my question. How exact must the address input be? Do I need to include unit numbers? What if the street number is off by a few due to the layout of a plaza?
Using Maps or Web Search APIs, I can find approximate locations for certain businesses based on my input. Can your API work in a similar manner?
It is supposed to work if you even don't include unit number or a house number is a bit off. We analyze other signals too, so if the address is a bit off, the API is still supposed to mark a place as existing
I'm not sure I understand : how can you product help for opening times or pictures of my local boulangerie ? What kind of data sources will help you automate the reviewing of its attributes ?
We are not providing opening times yet - we just check if place is permanently closed or not. But it is in the works under our experimental enrichment API (which is not yet open to public)
I started scraping restaurant websites in Zürich and extracted and hand-checked opening hours in the OpenStreetMap format. The goal is to build a corpus for evaluation purposes which maps website texts to correct opening hours strings for all restaurants in Switzerland. Maybe you can use that to benchmark your own hours extracting system... https://github.com/wipfli/opening-hours/
Really interesting!
I also launched recently a project to extract opening hours from OSM websites : https://codeberg.org/raphaelb/poi-complete
I also added a very basic web interface for validating the predictions: https://poicomplete.raphaelb.net
I don't know how well does Haiku handle OSM opening hours syntax, but with Kimi K2.5, I got better results when I asked it to provide opening hour ranges for every day of the week, and then constructed the opening hours manually.
Appreciate sharing this project - democratizing this data is indeed a very important step. Interesting that you settled on Haiku - did you have a chance to check flash-2.5-lite or gpt-5-nano performance?
Not yet. I can ping you once I do some comparison
thanks, looking forward to that!
Well, there goes my favorite secret mountain trout fishing spot. Sheesh
> Their API can't tell you the chef left last month
Your API can do that? Using what data?
That is our vision of where we want to be. There is a lot of information about the places on the public web which you analyze and cross-reference. And we started to solve this problem with validation API which can tell you if a business or point of interest exists at current location.
Interesting, just the thought of building these tools for agents is a good move, keep collecting feedback and iterating, good luck!
Thanks - we will keep building!
I like the agent-first signup via API. Is this meant to be distributed as an agent skill?
Indeed, in the current age we need to build things for agents first. We think that the skills will primarily will be discovered through marketplaces or via web search
I'm a little underwhelmed by the api, it tells me if the business exists and is open, which is a tiny subset of what google places can tell me.
Fair point - one doesn't instantaneously dethrone Google three months after starting. Here are some benefits of our API. Google's api is recall focused as any search - it shows you all possible places even if that one you are looking for doesn't exists. It is your job to find out if any of the returned results match the one you were looking for. Also, we have more convenient terms of use - you don't have to delete data after 30 days and don't have to attribute data when displaying.
Aren't you just scraping Google's data though? Also I looked up a place that doesn't exist and it responded with: "existence_status":"not_exists","open_closed_status":"open"
No, we are not - it is against Google's the terms of service.
open_closed_status is an indicator showing if there are sufficient evidences of the closure. If place doesn't exist, then there are likely no evidence of anything related to it, including closure. It could be confusing, but we will iterate on that.
Ok. I don't believe you but I respect the hustle. My only other note is the repo doesn't have any code in it and your github handle has zero history. At least vibe code a python client and put it in there if you want people to take you seriously.
Fair point on the repo - cli is in the plans and coming. We've been focused on the API
what's your plan to get all this data and maintain it?
There is a a lot of data publicly available on the web, it can be analyzed with the derived signals stored and then re-checked periodically.
Comment was deleted :(
Interesting approach. The annual churn stat seems brutal, I imagine that gets worse in certain categories (restaurants, pop-ups, seasonal businesses).
How do you handle conflicting signals? E.g., a business shows as open on Google, closed on Yelp, and the website returns a 404. Is there a confidence score in the API response or is it binary (exists/doesn't)
We have models which take all of this into account when producing the verdict. For enterprise clients we emit a calibrated confidence score. With public api we decided to start simpler. Also, we are not using Google data. I’m not a lawyer, but doing that for any maps-related company is simply against Google’s terms of use
FWIW it may be legal to break terms of use
Interesting. Can you elaborate more on that? I was wondering the same thing with other providers, if I can scrape data from their platforms. On what grounds do you think it might be okay?
On the grounds that there's no law that says someone can put some instructions on their website and you have to follow those instructions.
You should consult a lawyer just in case there is such an obscure law, but I don't think there is. Browsing a website doesn't create a contract between you and the website operator, even if the operator says it does.
It doesn't fit into our plans of building this
Fair enough. Just remember that in case terms of use bother you in the future. Consult your company's lawyer before doing it.
Completely agree - we have been in constant communication with them
what does “exist” mean in this case.. what is factored to determine a place exist? the building is there? people are speaking about it on social media? they have ad on google that point to the local address etc?
It means that there is sufficient evidence found online that this business or poi is located at that address
Implementing maps into our app so giving this a shot. How does pricing compare to google maps api?
It is on par with Google Maps API, but Google gives you more data. Our terms of service are more flexible - for instance we don't require attribution and deleting our data past 30 days. And we are actively working on adding more info to our APIs
This whole post sounds - LLM generated
This is a great idea, albeit one that will be really hard to pull off well but really valuable for developers if you're able to execute.
Definitely kind of a boil-the-ocean high-schlep startup but I would love to see this succeed.
Thanks, it is going to be fun! :)
Who are your customers? Consumer or business?
Both - we're building APIs ultimately designed for AI agents and LLMs that need trustworthy place data and that includes cases from enterprise to personal people's agents
what kinds of data quality evals do you guys use now? i'm curious to try integrating it
We are using judges with LLMs and web grounding plus manual grading. We recently did a benchmark on the LLM quality across major AI providers - we plan to open source it soon and will probably open source our API quality check benchmark too https://news.ycombinator.com/item?id=47366423
Why not go with V'ger? Seems like a missed opportunity: https://en.wikipedia.org/wiki/List_of_Star_Trek_characters_(...
Indeed, we've been told about that. Hopefully, it won't be a defining moment for us as a company :)
I think you should market specifically to people and orgs that already have registered identity and location tracking of their movements, purchases and personal actions while on duty. Then you can practice your ambitious tech, but also not pull innocent people into more detailed tracking and analytics. Many occupations and orgs have already made this bargain, so stick with them instead of trying to get naive people to have their detailed movements and actions tracked. Also probably large parts of East Asia are doing this.
Appreciate thinking about it, but I think there's some misunderstanding - we don't track people or movements. VOYGR validates places - for instance, we are able to answer a question if this business still open?
Its quite funny that you are building an "infinite place profile", you both worked on products used by 100s of millions of people, and yet your website is down from 45 minutes of HN traffic!
Joking, but its a very good idea. Synchronization between the physical world information and digital has been a very hard problem for decades and im sure an agentic approach can 10x the value.
Thanks! Was it truly down? I have checked and I don't see any disruptions
Gemini now has grounding in Maps data. How will you differentiate?
Good question - we actually did a benchmark recently and even with maps/search grounding it is pretty suboptimal from a end user's perspective https://news.ycombinator.com/item?id=47366423 For instance, we found this: "The pattern extends to navigation: Gemini’s own Maps grounding makes it worse at giving directions"
Second, Google Maps API has pretty strict licensing terms - you have to delete data within 30 days, have to attribute it properly. There are reasons why OpenAI and other companies are not using their APIs
[dead]
[dead]
[dead]
[flagged]
[dead]
[dead]
We work in this space and have found that, very often, the realities on the ground do not match the digital information, especially when it comes to geospatial data, where businesses exist, what businesses actually exist, and their status. At Rwazi, we have millions of users helping collect on-the-ground data.
That is definitely the case/challenge. For example: I've recently been traveling in Brazil in non-mainstream locations (at least for US/EU travelers) - some of the places were on gMaps as open but in reality they were permanently closed or just online delivery businesses with no physical presence. gMaps were messed up and if you manually investigate it is very hard to figure out what is really going on. - Online: Really attentive human being might be able to figure it out after spending hours online (using Instagram that is strong in Brazil, forums, etc ). LLMs can potentially do the same job but cheaper/faster - Offline verification can definitely help, but the downside is that it usually costs $$$ -> you need to be smart/strategic what you verify offline.
[dead]
Comment was deleted :(
[flagged]
[dead]
Crafted by Rajat
Source Code