Playing the long game with Ed Freyfogle - founder of the OpenCage Geocoding API
OpenCage can't create demand for geocoding — you either need it or you don't, and if you do, you already have a solution, even a bad one. Ed Freyfogle's entire growth strategy is built around being visibly present in the community long before the day someone's existing solution finally breaks or the Google bill arrives.
Ed Freyfogle is the co-founder of OpenCage, a geocoding API built on open data sources like OpenStreetMap, and host of the GeoMob podcast and event series.
We get into why OpenCage prices with flat, predictable packages instead of the usage-based 'contact sales' model most cloud providers use, why geocoding customers think of the service like electricity rather than something they log into daily, and why he's made peace with a marketing strategy — community sponsorship and steady presence — whose payoff is nearly impossible to measure directly.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
How did OpenCage actually come about?
I've been in the industry for about 25 years, starting at Yahoo, then founding a real estate search engine. Building that business required geocoding — turning an address into geographic coordinates, or the reverse — and we built up real in-house expertise and technology around it. When we sold that company in 2015, the buyer wasn't interested in the geocoding piece, which was still fairly early stage. My colleague and I took that piece over, branded it OpenCage, and have been running it as our own geocoding API ever since — about seven years now.
What makes OpenCage different from other geocoding services?
We do one thing: geocoding, both forward (address to coordinates) and reverse (coordinates to address), for the whole world, and we build it entirely on open data — OpenStreetMap being the largest source, plus many country-specific datasets — rather than proprietary data. We aggregate all of that into a clean, simple API, serving everyone from tiny startups and one-off projects up to companies making tens of millions of requests a day, often for things like vehicle tracking.
What's a concrete example of who actually needs a service like this?
The main use case is anyone with a large, continually growing database of addresses — a real estate site, a company database, anything geospatial software needs to work with, since almost all of it operates on longitude and latitude. Step one of nearly any geospatial process is converting addresses into coordinates so you can map, search, or analyze them. The reverse case is just as common: you have coordinates from a tracking device or mobile app and want human-readable information back — which country, state, or city someone is in, similar to how a tweet shows it was sent from a specific neighborhood. The world turns out to be an extremely complicated place in how humans have organized geography, full of edge cases, and we try to absorb all of that complexity behind one simple interface.
Your pricing is unusually transparent compared to the big cloud providers. Why?
At my old real estate company, we were a heavy, early Google Maps user, a genuine case study for them — and then Google introduced fairly severe pricing that we couldn't afford, which felt like a real bait-and-switch, especially since the pricing itself was unclear. Even today, most large providers' pricing quickly turns into 'contact sales' once you have any real volume, which means you're never getting a transparent price, just whatever you can negotiate — and you can't plan around that. We deliberately went the opposite direction: flat-fee packages, small, medium, large, each with limits based on your daily average usage over a month rather than a hard cap, so an occasional spike doesn't trigger a surprise bill. We designed it the way we, as developers ourselves, would have wanted to be priced.
Who do you consider your real competition?
Really two types. On one end, the proprietary giants — Google, Amazon, a company called Here. On the other end, because we rely on open data and open-source architecture, a lot of people simply try to build it themselves — which is genuinely possible, just not simple to maintain. Some of our best customers are people who originally built their own solution, then the one engineer who understood it left the company, and they realized they no longer knew how to keep it running. It's almost always more cost-effective for us to run it for you than for you to maintain it yourself, but developers like to tinker, so a lot of people have to learn that lesson the hard way first.
Geocoding sounds like something a determined developer really could build in-house. How do you help people see why that's harder than it looks?
Unlike most software, this isn't just code — it's code plus continually changing data. OpenStreetMap alone gets 5-6 million edits a day, so it's nowhere near a static dataset; you can snapshot it, but you'll be out of date almost immediately. That ongoing DevOps burden of keeping the data current is a real, underestimated cost. On top of that, geography is full of edge cases most people don't anticipate — every country organizes addresses differently, culturally people search for locations in very different ways (ask someone in the UK where they live and they'll often just recite a postcode, which means nothing to most of the rest of the world), and road and even regional names change constantly. It's genuinely non-trivial depending on your specific use case.
OpenCage has been entirely bootstrapped. What did that early period actually look like?
We spun it out of my old company with maybe one or two customers, having launched it the prior year almost as an experiment — just a web page saying here's our service, does anyone want to use it. After I sold the real estate company, I wanted a new project to keep learning from, so my colleague and I agreed to run OpenCage as a side project for six months and see how it went. We slowly added features, eventually took it out of beta, added pricing, and customers showed up gradually. Our biggest advantage was that we could afford to go slowly — and honestly, given the nature of the product, we probably couldn't have accelerated much even if we'd wanted to.
Why is speeding up growth specifically hard for a product like geocoding?
Our service is entirely non-discretionary — you either need geocoding or you don't. Someone can land on our site, think we look smart and credible, and still not buy anything, because they simply have no need for it right now. And anyone who does need it already has some existing solution, whether homegrown or a competitor's. So we have to be there, top of mind, on the specific day someone becomes unhappy enough with their existing solution to look for something new — which happens far less often and far more slowly than you'd hope, since even a mediocre existing system tends to get tolerated for a long time before anyone prioritizes replacing it.
You've talked about playing the long game as the only real shortcut here. What does that look like concretely?
Our pricing model is one example — rather than exposing customers to a sudden spike in cost if their usage triples unexpectedly, the way usage-based cloud pricing can, we aim to be a steady, predictable, long-term partner. I think about how our customers actually relate to us: mostly as a utility. We're a small, largely invisible backend piece of their data pipeline — people think about us the way they think about electricity. You want the light to turn on when you flip the switch, and a reasonable bill at the end of the month. You don't want to log into an 'electricity dashboard' every day. That's exactly how most of our customers think about geocoding, and being a stable, low-friction, non-intrusive presence is what that relationship actually requires.
If the product itself is invisible, how do you actually market it?
We focus on being genuinely active and supportive within the communities we depend on — we're corporate members of the OpenStreetMap Foundation, we sponsor OpenStreetMap projects, and we interview people from that community on our blog. More broadly, we run GeoMob, an event and now also a podcast, featuring interesting geospatial projects and the people building them. Geocoding itself is a tiny building block in a much bigger, genuinely innovative space, and it would feel disingenuous to spam customers weekly about incremental geocoding features when the far more exciting work is happening around us. Sponsoring and highlighting that broader community is how we build a positive brand association, so that when someone's geocoding need eventually surfaces, months or years later, we're already near the top of their shortlist.
That kind of brand-building sounds genuinely hard to measure. How do you deal with that?
It is hard, and honestly slow. We ask people, optionally, how they heard about us at signup, and try to have that conversation directly with bigger customers, but it's not always reliable — sometimes the customer themselves doesn't fully know, just that a colleague mentioned us, with no visibility into how that colleague originally found out. As a bootstrapped business with limited resources, it would be easy to burn a lot of energy trying to perfectly track that attribution chain. We've made peace with focusing on what we can actually control — doing the right things consistently, getting positive feedback from the communities we're part of, and trusting that trials and signups moving in the right direction means it's working, even without a clean conversion path to point to.
Do enthusiasts or informal experts in the geospatial space play an outsized role in how people find you?
Anecdotally, yes. When a developer's manager suddenly tells them a project needs geocoding, their first instinct usually isn't to search cold — it's to ask whoever they know who's touched this space before, a former colleague or friend, because geography and geocoding are complex enough that most people don't have deep, day-to-day familiarity with it, even if they've heard of something like OpenStreetMap in passing. Our goal is simply that the person they ask is someone who's already come across us — through the podcast, an event, following us on Twitter — so we're already part of that informal referral chain, even though it's genuinely hard to measure directly.
Have you tried more direct, measurable marketing channels, like paid search?
If I found a channel where I could reliably say I put in X and got X-plus-one out, I'd absolutely use it, but our attempts with things like Google AdWords have shown it's easy to spend real money without clear results — you can definitely get clicks, but the question is whether those clicks convert into actual customers, or whether you're just reaching people with no real, immediate demand. We offer a free trial because people genuinely need to try it, but plenty of people find the free trial more than sufficient for their actual needs, and spending heavily to acquire users who were never going to convert isn't a sustainable strategy. We don't have all the answers, but we keep experimenting, and so far the community-first approach has worked well enough.