TravelTime’s CEO Charlie Davies shares the story behind building their API-first company from the ground up.

I didn’t set out to build an API-first company when I started TravelTime — I was just trying to solve a problem. I had noticed that the way locations were listed on apps didn’t reflect how I talked about locations in my daily life. Apps would list location-based search results ‘X miles away,’ but I would use ‘X minutes away’ when speaking to friends.

To solve this problem, I first started trying to develop a consumer-facing app. The unique selling proposition (USP) was a travel time-based search, and at some point, I intended to enable ads, turn on the revenue faucet and watch the money roll it. Yet as with many ideas, my ambitions outweighed my resources. The company had little money and no audience. I also failed to sell ads door to door and quickly realized I had to do something differently.

I had that pivot moment where I thought, “what if we could integrate our time-based search into all other applications where location is part of the decision-making process?”. This would turn all our competitors into customers. So easy to write, so hard to do.

Transitioning to API-First

The birth of our API-first company was far more complex than I ever could have imagined. I naively thought that all the technology to build the API existed. The development team would just need to plug it all together, and bingo, the API would be born. But the technology did not exist, so we had to build it.

We also had to:

• Convince technical teams to rely on our API inside their application.
• Reassure clients the API would not reduce the performance of their applications.
• Operate the API with a profit margin.
• Build our own network / private cloud.
• Convince established industries to swap distance-based searching for time-based searching.
• Ensure complete user data privacy.
• Learn the importance of saying ‘no.’

One of the biggest mistakes we made as a team was around positioning. We knew that TravelTime could help optimize where to place a new hospital, retail park, or office space. But when we positioned ourselves as a solution to these problems, our customers expected us to have an end-to-end location recommendation SaaS solution.

This expectation meant we spent our time training people on Geographic Information System (GIS) software or interpreting our client’s data so that clients could get value. Instead, we needed to come to terms with the fact that our API was not an end-to-end solution. When a potential customer approached us, but they didn’t have access to developers or GIS experts, we had to start saying no.

Knowing Your Limits

Our TravelTime API is a building block. Our customers use it to enhance what they are already building. We’ve now pivoted to focusing on creating support assets for developers, not location managers.

We still talk about use cases to bring the API to life. We love discussing how real estate websites can help people find a new home based on commute time or how travel websites can help tourists find a hotel based on access to nearby points of interest. But when it comes to UX, all we can do is give our customers recommendations based on how others have used our API. We now know our limits — we’re API experts, not real estate or travel industry experts.

Knowing Your USP

We’ve built the world’s fastest way of searching the physical world. Our customers apply this data in all sorts of ways to gain their own competitive advantages. For example, when it’s added to a job portal website, job hunters are more likely to apply for roles based on commute time rather than a distance-based search.

You’d never expect a DIY store to help you to build a house, but it can supply the bricks you need. That’s the same with an API-first company, we can provide the building blocks, but we won’t build the application.

As an API-first company, we must focus on delivering the feature or solution someone needs to power their application. That means we must focus on API speed, performance, stability, and value.

The Challenge of Pricing an API

Pricing is something every API business struggles with. (There is a fantastic article going through all the pricing methodologies for pricing an API from Nordic APIs). We solved the problem by first understanding our customer’s usage.

We have two types of users:

• Users that need to make large volumes of concurrent requests. They need ultra-fast API response times, but the value they get from each individual request is small. An example is adding TravelTime to a job portal website search.
• Users that make small volumes of requests, but the value they get from these small volumes is high. An example is a real estate developer deciding where to locate a shopping center.

A real estate development company can make ten requests and pinpoint the most profitable location for new development. This decision could help them earn millions — they get tremendous insight from these few requests. But if you’re a high-traffic job portal website, you need heaps of requests to achieve your business goals. We thus needed a way to price for both fairly.

This is why our main charging mechanism is concurrency. This means everyone can use the API differently.

If the real estate company needs to run a large analysis, they don’t mind having a low currency plan and staggering out their requests. That’s because their analysts can leave a large request running and come back to see the results once complete. Meanwhile, a large job portal must have large concurrent requests — they can’t stagger requests because their users will bounce off their page.

Not only does this pricing model make sense for our customers, but it also makes sense for us as a business because it costs us more to serve clients that require higher concurrency limits.

The API-First Journey

Our journey is far from complete, and being an API-first company means relentless work. If we want other technical teams to use our API in the core of their applications, we need to command respect and trust from the first touch point to the last.