These Yale Graduates Raised $27M To Build The Universal Commerce API

Service providers to SMBs need access to the latter’s data to effectively serve them, but the data is fragmented across many different systems and communication mediums, leaving a massive, multi-billion dollar market in need of a solution. Rutter, a universal commerce application programming interface (API) startup was founded by Peter Zhou and Eric Yu to serve as a data bridge between SMBs and service providers. The San Francisco-based startup recently raised a $27M Series A led by a16z.

Charley Ma, Ally’s GM of Fintech and angel investor in Rutter, states, “I invested in Rutter because I was really impressed at the rate of iteration on the product and team that Eric and Peter built in a short time! I was also really excited about the product surface area across their customer set that their data integrations provide – there’s lots of opportunity to build deeper integrations and solutions for their clients and thus expand LTV over time too!”

Frederick Daso: What were some of your biggest lessons as you pivoted and iterated into what Rutter has become today?

Peter Zhou: Only work on problems with potential customers and team members that excite you. Startups are based so much on the momentum that if you work on things that don’t give you energy, even if they would turn out to be successful, you’ll never make it to the end because you weren’t passionate enough about it.

Treat every idea as an experiment. People often get attached to whatever they’re working on, and it’s a huge blow when things don’t work out. It’s common for startup ideas to fail, and failing doesn’t necessarily reflect poorly on you as an operator. Treat failure objectively as a learning experience and move on to the next one.

The market is the ultimate litmus test. It’s important to have high conviction on whatever you work on, but your product lives and dies by whether people will use/buy it at the end of the day.

Daso: How did you come up with the concepts of open and closed markets, and how have you built on that framework to scope out newer markets for Rutter to expand into in a scalable manner?

Zhou: Open and closed markets come from conversations with many customers and many different markets. You can roughly judge an open/closed market by the ratio of companies with an open problem to companies with a solution. The higher the ratio, the more open the market – we built up the intuition for this by trying to sell a ton of different products and seeing, through hundreds of customer convos, how much positive feedback we received per product.

Daso: It’s clear that service providers to SMBs require the latter’s commerce data and thus went ahead and built their own integrations. Beyond the initial completion of these in-house solutions, were they maintainable from a long-term engineering perspective?

Zhou: There’s consistent maintenance cost that results from the different styles of platforms those SMBs can be on – sometimes the platform is self-hosted like WooCommerce or Magento, which means that every SMB built on top might run a different version, each with its own API, firewall, or customizable nuances. Other times the SMB is on a platform that isn’t self-hosted, and all SMBs run the same latest version, which means you need to make sure your integration is up to date constantly.

Daso: What is unique among financial services that made them ideal customers for Rutter to approach first as a beachhead market?

Zhou: They have concise requirements, represent a large initial market, and are so tech-forward that we were confident working with them was the fastest way to iterate and improve our product.

Daso: What were the key features in designing Rutter’s API that you needed to ensure were “stable” before putting the product in the hands of a diverse group of the startup’s customers?

Zhou: The baseline is that no matter what, the API must always be up – our data infrastructure is so crucial to our customers that if our product is down, it results in their product being down. So we spent a lot of time ensuring that our system was tolerant of faults (which are inevitable). Beyond that, we needed to ensure that all ways of fetching and writing data worked, so we tested those endpoints extensively. It’s inevitable for an early product to start cracking under explosive pressure, so we started logging requests early on to make sure we could respond instantly with a patch the moment someone submitted an API request that returned an error.

Daso: All founding teams have conflict within them. What techniques have you learned as Rutter has positively scaled to leverage conflict at all levels of the business?

Zhou: Communication is key, and it’s important to address issues as soon as they pop up. The worst thing you can do is let an issue fester and become unbearable down the road.

Make sure that the team is values-aligned – everyone gets along when things go well, but in hard times the team is tested on what they care about. If the team cares about similar things (personal growth, learning, etc.), it’s easier to make decisions.