Mobility is one of the most transformative forces in the 21st century, with the potential to radically change our lives and shape the future of our cities. The way we are going to get around our cities is changing with multi-modal transportation being touted as the way of the future. How can cities and other mobility service providers improve the transportation experience without having to worry about building an entire stack of APIs to take care of needs? We spoke to Stephen Smyth, the co-founder and CEO of Coord, to learn more about what it means to build a company that identifies itself as *#8220;developer platform for the mobility marketplace*#8221;. Read on!
Q: Stephen, let us get straight into it! When did you decide that you wanted to start your own company? And why did you decide to start a mobility company targeting the developers specifically? What’s your “unfair advantage”? A:*I have always been passionate about mobility *#8211; I actually began my career in transportation, developing virtual reality visualization and robotics simulation software for BMW in Munich. Subsequently, I worked in both product management and cross-functional leadership roles in digital media, education technology and, most recently, financial technology at lending marketplace Prosper in San Francisco. When the opportunity arose to co-found and lead Coord, it felt like a great combination of my experience in transportation, marketplaces and technology. I view running a company in the same way that I view building a product. You are iterating and testing things, measuring your performance, and building trust with your market. As a CEO, I’m lucky to have the opportunity to do this not only with customers but also with my team. We’re building the developer platform for mobility because we believe that developers will be the ones to create the connective tissue between the tech stacks of all the different players in the mobility space. That’s how you deliver a great trip experience in real-time. Our advantage is our team. We have come together from a lot of different backgrounds and experiences to focus on making seamless mobility available to everyone. *Q: Coord identifies itself as a “developer platform for the mobility marketplace”. Does that mean you that are building a full-stack API that developers can use to integrate mobility solutions i.e. getting from A to B (regardless of the transportation mode)? How does Coord differentiate itself from the routing APIs from Google, Mapbox, and others?A:*Yes, that’s exactly right! There are several great products that provide mapping services. We’re providing a layer of bookable mobility options *#8211; from curbs to bike-share *#8211; which sit on top of a map. Q:*One of the things that caught my attention about Coord was the Curbs API. I hardly realized how important curbs can be for a complete mobility solution before checking it out. In your blog post “building the curb map”, you mentioned that you use OSM and linear referencing to build this map. The blog makes it sound like it*#8217;s as easy as 1-2-3 but the engineering challenges must be quite remarkable. Could you tell us more about it? *P.S: It is great to see that the data is now open, kudos for that.A:*The system for collecting and processing curb regulations is one of the most exciting and deep pieces of technology at our company. The steps include:
Stephen and the coord team hailing a cabQ: As a startup founder, I am sure that there are many things that you must have learned along the way. What was the most interesting feedback that you received so far?A:*Everyone knows that startups are inherently risky. But what you don’t hear as often is how to manage these risks. A seasoned entrepreneur once advised me that this means you should seek to reduce or eliminate risk in all areas of the company except for the one that is core to your idea. In other words if your innovation is a technology, think twice about also offering a new pricing model. Doing both at the same will likely increase adoption risk. If you were right about the appeal of the technical innovation you can come back and innovate pricing later.Q: You are based in New York. How’s the mobility startup scene there? Are there any local meetups/events that cater to the geo-community? Are there any accelerator programs/venture capitals that focus on geo companies?A:*We love NYC! There’s a great geo meetup called GeoNYC that we’re hoping to speak at in August and another one called Transit Techies that we’re big fans of. Coord also offers developer workshops every two weeks at our offices to give developers time to come in and work on their projects with our support. Q: Oh and before I forget, How’s life as an Alphabet company?

Q: Stephen, let us get straight into it! When did you decide that you wanted to start your own company? And why did you decide to start a mobility company targeting the developers specifically? What’s your “unfair advantage”? A:*I have always been passionate about mobility *#8211; I actually began my career in transportation, developing virtual reality visualization and robotics simulation software for BMW in Munich. Subsequently, I worked in both product management and cross-functional leadership roles in digital media, education technology and, most recently, financial technology at lending marketplace Prosper in San Francisco. When the opportunity arose to co-found and lead Coord, it felt like a great combination of my experience in transportation, marketplaces and technology. I view running a company in the same way that I view building a product. You are iterating and testing things, measuring your performance, and building trust with your market. As a CEO, I’m lucky to have the opportunity to do this not only with customers but also with my team. We’re building the developer platform for mobility because we believe that developers will be the ones to create the connective tissue between the tech stacks of all the different players in the mobility space. That’s how you deliver a great trip experience in real-time. Our advantage is our team. We have come together from a lot of different backgrounds and experiences to focus on making seamless mobility available to everyone. *Q: Coord identifies itself as a “developer platform for the mobility marketplace”. Does that mean you that are building a full-stack API that developers can use to integrate mobility solutions i.e. getting from A to B (regardless of the transportation mode)? How does Coord differentiate itself from the routing APIs from Google, Mapbox, and others?A:*Yes, that’s exactly right! There are several great products that provide mapping services. We’re providing a layer of bookable mobility options *#8211; from curbs to bike-share *#8211; which sit on top of a map. Q:*One of the things that caught my attention about Coord was the Curbs API. I hardly realized how important curbs can be for a complete mobility solution before checking it out. In your blog post “building the curb map”, you mentioned that you use OSM and linear referencing to build this map. The blog makes it sound like it*#8217;s as easy as 1-2-3 but the engineering challenges must be quite remarkable. Could you tell us more about it? *P.S: It is great to see that the data is now open, kudos for that.A:*The system for collecting and processing curb regulations is one of the most exciting and deep pieces of technology at our company. The steps include:
-
Figuring out where the curbs are, as we describe in the blog post;
- Finding out what’s on the curb. This involves an app we call “Surveyor”, which lets data collectors use augmented-reality technology to locate different curb assets, like parking signs and fire hydrants, on the curb very accurately. We also ingest city-provided data: some cities already know where their parking signs are and what they say, and most cities know where their parking meters are and how much they charge. We ingest as much public, city-provided data as we can find.
- When we use the Surveyor app, we have to find out what the parking signs say. We have another blog post that discusses how we use computational biology to overcome some of the challenges around parking sign transcription!
- Understanding what the parking signs mean. This involves writing a parser that can read the text of parking signs and break them out into distinct regulations.

- Understanding how the different rules on the curb relate to each other. (If there’s a “no parking” sign on one side and a “2 hour parking” sign on the other, can you park or not?) We have a rule computation engine that takes in all of the curb asset data as well as the bylaws for each city and state that our API covers and produces the ultimate map of regulations.
