There’s soft banter in the background and an espresso machine grinding away in the distance. It’s a warm autumn day and the sun isn’t baking yet. I’m at Octane Coffee in Grant Park downing caffeine at an alarming rate.

And as the jitters help keep the status of Faretrotter up to date, it’s almost starting to feel a bit redundant when launching and relaunching.

For those who are unfamiliar, ‘API’ stands for Application Programming Interface. In short, every website, app, or any piece of technology for that matter, is built with the help of other pieces of technology (duh!). One of the ways that this is done with with a single or many APIs. It’s a way of systematically making the inner-workings of one piece of software available so that others can leverage the meaningful information provided to another service.

A couple use cases are Weather.com’s forecast showing up on Google, or how NextBus works with municipalities to alert citizens of when the next bus will arrive. These services power not only their respective websites so that their partners can provide value to their customers, too. It helps their partners not having to worry about the technical side of that service and focus just on their customers.

Faretrotter’s API digs deep sits on our platform and exposing quite a bit of information. That is, it gives partners, developers, and anybody else, access to 13,103,975 distinct transportation routes globally. In lieu of wrangling disparate data sources to make travel information meaningful, that’s where our API comes to play. We serve it up at under 1 sec (1000 milliseconds is our main goal).

Not to nerd out too hard, but the special part of the API is that it takes two geo-coordinates from anywhere on Earth (sorry, not interstellar quite yet) and regurgitates every mode of option between the two points. That’s a pretty neat thing given the complexity of what we are trying to solve – never mind all of the issues surrounding the integrity and upkeep of our data. Putting our API out there like this does make us a bit uneasy. But also equally as excited.

We’ve drummed up a few exemplary applications that we’ll be launching in the coming weeks as well. No sneak peeks just yet. In the meantime, feel free to give us a follow on GitHub.

It has truly been a long time in the making.

I remember the exact moment in 2012 when I first thought of what would become Faretrotter — I was in Boulder, Colorado and I had just returned from a consulting trip to Belgium. Upon my return, we were in the living room in our small split level home off of Table Mesa in south Boulder. Nothing too out of the ordinary, but over a few glasses of wine, I shared with my friends the goings on of my latest trip.

The two week trip spanned three countries, two currencies, three languages, and seven modes of transportation – bus, flight, train, car rental, public transportation, taxi, and mitfahrgelegenheit. At the time, no tools were mainstream enough to make this planning easy and information readily available. So, to compensate, the preparation consisted of spreadsheets and multitudes of Google searches and translations.

“How’d you know how to do that?” asked one of my friends. I recalled the time I had spent in the area before, and knew it was something you could only known simply by having lived in the area before. As I answered, I remember feeling the gears turning.

There was an originating city, multiple arcs (modes) to get me to several other nodes (cities), and several more connecting from each of those. Compounded a few times over and I’ve arrived at my final destination. On top of that, all of these modes of transportation have several departures per day, over a few classes, and with various connecting cities. If you were to maximize things like convenience or comfort or minimize things like price or duration of travel time, combinatorics would tell you a trip like this could result in millions of combinations. College still wasn’t that far in the past at the time and as I was telling this story (while feeling the subsequent engineering gears turning), I can still vividly remember feeling the requirements of this being a quintessential Dijkstra’s algorithm, NP-hard, dynamic linear optimization problem. It composed all parts of the problems that really attracted me. The obsession with solving this problem has yet to leave.

Fast forward 7 years, involving a move to Atlanta, forming the company, researching, building MVPs, researching, forming partnerships, launching, studying, researching, relaunching, rebuilding, studying, researching, losing partnerships, rebuilding, relaunching, researching, rebuilding and relaunching. And we’re here. We’ve arrived.

The struggles that have ensued over the previous 7 years have seemingly accumulated into something far greater than the original idea that was conceived that night in Boulder.

As it would turn out, our suboptimal path has taken us through multiple iterations of what we wanted to test. We’ve managed to get our product in front of over 50,000 people in this time – executing hundreds of thousands of searches and holding thousands of conversations of how people expect to travel. And that has been the major battle all of these years – how to streamline a sophisticated algorithm into something that is useful to how travelers want to plan their trips?

And while we didn’t take the optimal path to where we are at today, it has been such an important trip.

Happily, I can introduce Faretrotter 2.0. Here are four things:

1. We still search every mode of transportation – flights, trains, buses, ferries, ride shares, airport shuttles, public transportation, subways, and even dog sleds – although without live pricing like before. This is forthcoming.
2. For travelers, there is more of an emphasis on human contextualization of these modes of transport. A ferry costs $15? Great, how can I get insider tips to make this information even more helpful?
3. We now have an API that you sign up for today. This is for businesses who are looking to supplement their marketing initiatives, companies, startups, or developers who want to build apps using our data, or anybody else who might want to fill in the gaps.
4. Every picture on our landing page? We’ve taken all of them. Just a personal touch 🙂

Cheers,

Justin