Peter Zhou, CEO of Rutter, on building the Plaid for ecommerce

In terms of customer profile and core use cases, we think of our customer segment in terms of two bubbles. The first is fintech: business banks, business credit cards, business insurance, lenders, acquisition and PE-type companies, payment processors for businesses or B2B payments. For them, the core use case is underwriting. They use our APIs as a single easy way to collect financial health data so that they can underwrite their merchant, give them a loan, assign them a credit limit and so on.

The second bubble is what we call “commerce enablement” and is a lot more diverse. This is where we want to go and be more horizontal in the future. These are all non-financial tools that a merchant would end up using—for example, a shipping and fulfillment platform, a drop shipping company that drop ships products for you, an accounting automation tool, a channel marketing tool, an inventory management tool, a BNPL tool or one-click checkout tool, and so on. There's a ton of tools that are just exploding in the ecosystem right now, and they are all trying to do some kind of workflow across those platforms. We give them the APIs to do that workflow just once across whatever commerce platform that they operate on.

What early signs of product-market fit have you seen?

Eric and I have been working on all sorts of different startups for the last three years. There were a lot of failures, a lot of stuff that didn't work out. I think our largest contract was a $6k annual contract by a Series C company. We built all this product out for months to serve them.

When we started Rutter, we knew that there was something here and that it was going to work because we ended up closing $100k in annual contracts in the first two months. There's been such a massive pull for the product, and we closed this basically off of slide decks. We hadn't actually fleshed out the entire product yet. We just had API documentation. When we showed that to people, they just instantly got it. That’s one of the signs of early pull.

The second sign is that people are constantly giving us suggestions on how to improve the product. When a customer becomes more of a partner to us, that's a really good sign.

Permalink

How do you differentiate as a developer-friendly product? What does “developer-friendly” or “developer-centric” mean to you in 2022?

I think one of the ways that we differentiate as a developer-friendly product is having very clean and interpretable developer documentation and modern workflows—so, having the most up-to-date authentication flow, being security-aware.

The hardest part about what we do—as a universal API especially—is what I call domain mapping. It's figuring out the right abstractions to represent these different entities across these different platforms. Developer-friendly in this sense means creating abstractions that work well across all of these platforms.

Permalink

Plaid had the challenge of creating an API into uncooperative banks, many without APIs where data had to be scraped. To what extent do you think you face the same problem? How open are the APIs you use in ecommerce, and how should one understand what's hard about what you're doing?

I think there are three dimensions to this. There's breadth, depth and then self-hosted versus hosted by a third party.

Plaid is very wide. They operate across, let's say, 3,000 plus different banking institutions. But in terms of depth of API, it is literally just transactions data. I think they're rolling out new products now, but the core is just transactions information. It’s not very deep on the API. And all the banks are hosted by the bank. There’s no issue of self-hosting, and there are no differences between an account on one platform and another account on that same platform. Their issue is they have uncooperative banks, and they have to do data scraping.

We're different. We are mostly built on top of open APIs. In terms of those three dimensions, I would say that we are probably not as wide as banks. There are probably 1,000 to 2,000 different marketplaces, payment processors and other commerce platforms that we want to integrate into. But it is probably 10 times deeper. It's not just transactions information; it's orders, products, customers, fulfillments, storefront transactions, etc. There's a lot of different information to take in. And it's not just read, it's read-and-write.

Then a lot of times these platforms are open source or they're self-hosted, and they're also quite extensible. Take Salesforce Commerce Cloud, for instance. The data that you'd find on one instance of Salesforce Commerce Cloud might look completely different from the data that you'd find on another instance of the same platform. Where Plaid has this uncooperativeness issue, we have the opposite: it's an open platform that people build on top of, so you get a ton of different flavors and a ton of different versions that you have to deal with and maintain. That's what makes this problem so hard. You have to see all of the different versions and all the different ways that people can describe that data in order to build a platform that doesn't have any holes in it.

Rutter integrates with two types of platforms, commerce and accounting. With commerce platforms, you integrate into storefronts like Shopify and Wix, marketplaces like Amazon and Etsy, and payment providers like Stripe and PayPal. Can you talk about what type of platform is needed for what type of use case? Do developers tend to want all the integrations or a specific subset when they integrate with Rutter?

As I described before, there are two bubbles of people that we sell to: fintechs and enablement companies. Fintechs being underwriting, enablement companies being workflows and other non-financial tools. In terms of how those types of customers use the API, I would say the fintechs generally use the commerce and accounting platforms, and the enablement companies mostly use commerce platforms instead of accounting. We're starting to see some enablement companies use accounting, though. They treat accounting as a place for them to read and write stuff as well.

In terms of wanting integrations or a specific subset, what makes the product valuable is that people don't have to think about what platform they're integrating with, which means that the long tail is incredibly valuable. A lot of times the people we work with have an idea of the next five to seven platforms they want to integrate with, and then there's a catch-all that’s like, “Oh, and if you could give us all of the other platforms that you have, that would also be great.” The product gets way more valuable the less you have to care about any niche or one-off integration in the long tail.

Rutter serves as an integration layer between ecommerce platforms like Shopify, BigCommerce and Amazon and accounting software like QuickBooks, Xero and NetSuite. How does that integration enable the underwriting process for fintechs?

There's a ton of components to this. The first is speed to loan. In the old days, you would have a merchant send over PDFs of their financial statements, go into Shopify and export all of their orders data or go into Amazon and export all that data and send that over as a CSV. You would build what's called a data room, which is a shared place to store all types of financial data. It would be a month-long process, because it takes time to create and collect that data. Then someone on the other end, like a risk analyst, would have to go interpret the data.

Where Rutter comes in is with what's called “data-driven lending.” Now it's either a human in the loop or entirely automated. A lender is able to look at the data algorithmically and make a decision on whether or not to assign a loan. It results in a much faster turnaround time, because now you can make a loan programmatically and you don't have to have a risk analyst take a look at it. There's no months of process to create this data room. It’s a one-click process, and you can have a loan as quick as 24 hours in.

Then the second piece is that there's a lot less human error and much higher fidelity data that you can deal with. It's not just looking at financial statements and having a risk analyst interpret them. It's all done through the computer.

Permalink

What are the trade-offs between using a universal API and integrating natively? What does a developer lose by not integrating directly with an ecommerce platform's native API?

The trade-off is the “least common denominator problem.” What that means is, if we build a universal API, whatever this API is capable of doing, we need to be able to support it on every single platform. Where that runs into pitfalls is if there's some niche API that you need to use on a specific platform. It'll be a lot harder for you to access that, or you'll have to implement platform-specific logic to use that API.

The way that Rutter solves this problem is that you're able to fetch the native tokens created for every authentication. It works a lot like React Native if you're a developer, where you can use our universal abstraction layer to do all of the things that you'd normally do. Then for anything niche, like fetching a seller ID on Amazon, you can actually use the Amazon keys to that specific information from the Amazon API.

Permalink

How do developers use Rutter for its breadth of integrations and then integrate natively with the small handful of most commonly used integrations? How does a developer decide when to do a native integration?

I would say the typical customer journey is that they usually have one or two integrations already and they have five to seven more planned for the roadmap. They probably have a Shopify integration. The second one might be WooCommerce, or it might be Amazon. That's what we've usually seen. Then they have Squarespace, BigCommerce, Wix and so on planned.

The journey for a customer working with Rutter is that they start using us for the longer tail. What we see is that most migrate over their existing connections from Shopify, Amazon or WooCommerce onto Rutter. If you maintained your own native integration and use Rutter, you're not entirely solving the problem of completely abstracting the integrations away. You're still dealing with, let's say, two integrations, one being Rutter and one being Shopify. It makes way more sense from the developer standpoint to just work with one and have that one integration provider be responsible for everything. We usually see this happen when developers run into maintenance issues. Shopify's API updates every quarter, and there might be breaking changes. When something like that happens, that's when a developer says, “Okay, it’s time to migrate over and just use Rutter.”

Permalink

Can you talk about your usage-based pricing model? How do you prevent getting rate-limited with various APIs that you use? How do you scale usage with your big customers versus getting swapped out by native integrations and partnerships?

I think that any usage-based company has to deal with this, whether you're Twilio, Stripe or Snowflake, so the answer's probably not super surprising. There are economies of scale. As your usage gets progressively bigger, the cost doesn't scale linearly with your usage. It flattens out. That's what we do with our biggest customers.

In terms of how we prevent getting rate-limited, the way that Rutter works is a universal cache where we optimize the way that we fetch data from the native platforms. Instead of passing through requests, we send back what we received internally in that cache. What that means for the customers that we work with is there are actually no rate limits, because we're not directly passing through requests to the underlying platform.

Permalink

In the case of Plaid, not only are there many different banks for developers to integrate with, but customers themselves often have bank accounts with multiple banks. Is that also true with ecommerce merchants, so they might be using Shopify for ecommerce and Square for their POS? If so, to what extent is that merchant platform promiscuity a tailwind for Rutter? Similarly, to what extent is omnichannel ecommerce a tailwind?

It's a huge tailwind. What we usually see is a hub-and-spoke model. People usually have one D2C storefront, like a Shopify, a WooCommerce, or a BigCommerce. They operate that as a source of truth for all the other marketplace listings that they have. It’s the centralized source of truth for their Amazon listings, their Etsy listings, their eBay listings and so on. It's actually quite common.

In the future, I think there's a huge opportunity for Rutter not only to enable financial services and other tools to access merchants, but also to enable easy onboarding flows and to get merchants approved and available on multiple platforms. We want to enable a merchant to be on all of these marketplaces more easily.

Can you talk about which merchant connections, both individually and combined, you most commonly see and what insights you've been able to glean from that data? How much concentration risk do you have in terms of usage of particular platforms? What do ecommerce stacks look like?

I think this is what surprises people the most. People basically think that everyone is on Shopify. I think what makes a lot of this possible, and what surprised us a lot, is that it's actually quite fragmented. Shopify is one of the leading players. We've seen WooCommerce and Magento more than we've seen Shopify. Then the longer tail after that is Square, BigCommerce, Wix, Squarespace. It's way more fragmented than we thought, and that reduces a lot of the concentration risk that we have. The other thing is that omnichannel and platform promiscuity alleviate all of the concentration risks, because people are on multiple of these platforms, not just one.

In terms of ecommerce stack, I think what makes Rutter so interesting is that the stack is kind of shattering right now. It used to be the case that Shopify or WooCommerce would do every single thing for you—they'd be an all-in-one provider. Now you have this giant app ecosystem where Shopify, WooCommerce and these other platforms basically act as the backbone. They’re like the order management system, and they allow other partners to build each single part of the ecommerce stack themselves. Now you have one shipping and fulfillment tool, one drop shipping tool, one marketing tool, one inventory management tool and so on. That's how we see the merchant ecommerce stack. It's one core provider and then a ton of these other tools.

Permalink

There's several companies doing universal APIs for data and different verticals, including Vessel for CRM and Plaid for fintech. Why is ecommerce particularly attractive for a universal API company, and how do you see the opportunity there?

When we first started, our go-to-market motion was basically to go to the Shopify App Store, message all of the apps and say, “Hey, you're on Shopify. Why are you not on these other platforms?” Most of those apps were in channel marketing, like Klaviyo or Yotpo, or in drop shipping or shipping and fulfillment.

What we ended up realizing a couple of months in is that, if you think about the companies that use a universal API for commerce or ecommerce, it's way more diverse than any other type of universal API company. A Plaid or a Vessel sells specifically to a narrower set of customers that deal with CRMs or banking infrastructure. The universe of companies that deal with commerce in some way is massive. You have marketplace aggregators, accounting and fintech companies, lending and financial institutions. Ecommerce is so attractive because there are so many different types of players in the space and so many different companies for us to sell to.

I don't know how to size the opportunity here. Any numbers that I would come up with here are completely wrong. Just think how many companies end up touching commerce or dealing with physical or digital commerce in some way. That's the entire world, basically.

Permalink

While Rutter is more vertically focused on ecommerce, Plaid is a more horizontal data layer for all financial data. Where Rutter is used by fintech for underwriting, etc., is Rutter competitive with Plaid? What makes this an unattractive market for Plaid to get into? Assuming Plaid goes deeper into B2B, why does Rutter beat Plaid?

I would qualify this and say that we're actually horizontal. Ecommerce is such a wide array of different types of services that it's really hard to narrow down on just a single use case in that service. We consider ourselves a horizontal data layer for commerce data rather than financial data.

Rutter is used complementary to Plaid. Banking data has a lot of transaction-level information and money in/money out. It has no information on any type of fidelity on that data—so, exactly what was purchased, what line items were involved or who bought the items. The best you can get from that is a transaction statement. Rutter is the opposite, where we show a single view into revenue data and not the entire money in/money out. But within that view, it's extremely high fidelity, so you understand exactly who bought the item, where it's going, what the cost breakdown was, what the line items were, what the products were that were being sold. I would say that we would not be competitive with Plaid. We're the opposite side of a coin to them.

What makes this an unattractive market for Plaid is that we are horizontal across commerce. It's not just read, it's read-and-write. That diversity of use cases is not something that Plaid, being a financial services company, is focused on.

How do you think about your competitive positioning versus Shopify, which wants to be the universal API for ecommerce with its platform approach? To what extent is headless ecommerce a tailwind for Rutter? Can you talk about how you view market fragmentation and/or consolidation for the major ecommerce platforms going forward?

I think eventually we would want to have deeper partnerships with all of the different platforms that are out there. Shopify is a massive player in the ecosystem. I would almost frame it as, “How does Bank of America see its positioning with Plaid?”

You bring up headless commerce as a tailwind. There’s this giant wave of headless commerce platforms that are being built out right now. What we've seen is that it's not a zero-sum game. In terms of market fragmentation, different merchants of different sizes end up going with different types of platforms. You usually see Shopify for a lot of smaller merchants. Then as they scale, they try to optimize and move more towards headless, and there's way more diversity there.

Shopify is always going to be a massive player in the space. But ultimately, there will be different tools and different platforms that suit merchants at different stages of their journey. There's always going to be fragmentation there. We see them more as partners rather than a winner-takes-all type of thing.

Rutter and Alloy both address data fragmentation by enabling interoperability of ecommerce platform and tools to help the end user merchant get its data into the tools it uses. Alloy has an integration platform for developers called Forge that enables developers to quickly integrate with other tools. Can you talk about your positioning with respect to Alloy?

I think what people need to know is that we would never be competitive with Alloy because we'll never offer services directly for merchants. We are a B2B data infrastructure company, so our target is the providers that sell to merchants, and Alloy's target is strictly merchants themselves. Forge is meant for developers within these brands to be able to build workflow tools. That's not our target at all. That's how we're different position-wise.

We're the B2B version and the API version, and Alloy is like a low-code or no-code workflow tool for merchants. We would definitely consider partnering with them, but I don't think we're competitive.

How do you think about where the most interesting growth opportunities might be? Going deeper into ecommerce vertical and the needs of developers there, or going horizontal and building universal API functionality for different verticals?

Definitely going way deeper into ecommerce and commerce. There's just so much opportunity to reinvent the way that people do commerce. We could start working more into supply chain, or we could work more on POSs, so doing physical and brick and mortar commerce as opposed to digital commerce. We're just at the first steps of building this layer for commerce, so we definitely plan on staying there.

How do you think about providing universal API for data for SaaS providers given that you already integrate with key infrastructure like Stripe and QuickBooks?

We have a mission statement and a vision. The vision is that we want to organize the world's commerce data. What we're doing by providing this universal API is essentially making this data interoperable. The mission is that we want to enable new commerce experiences. This question ties in a lot with the mission statement, which is enabling new commerce experiences.

What we've seen, especially building our own tools, is that people spend so much time building the actual integration that it slows down on their innovation of building their own core product. Essentially what we want to do here is to be the building block that gets them that entire way on the integrations end. Instead of them spending years building integrations out, from day one they can start on their core product. In the same way that Stripe erased all the different complexities of dealing with bank accounts, ACH and different ways to accept money, we want to do the same for people connecting to commerce data.

Can you talk about how you see the future of ecommerce platforms evolving? Are we moving towards a headless world where more and more ecommerce brands are built on APIs, with services like Shopify serving as a simple backend instead of an end-to-end platform?

I don't think either will be the dominant. As I said before, Shopify basically functioned as an all-in-one solution, and then the app ecosystem that Shopify built turned it into this core backend and enabled everyone else to build on top of them. It's not going to be only headless, and it's not going to be only all-in-one solutions. The way that the world will end up shaping out is that it's going to depend on the stage of merchant that you are. If you’re a smaller merchant that doesn't have as much ability to optimize or build in-house, you'll go with an all-in-one. If you're a larger brand that wants to start optimizing or configuring or customizing things, then you'll go more towards headless and APIs.

If everything goes right, in five years what does Rutter become?

We're doubling down on fintech this year because that's the vertical that we've seen a ton of momentum in. It’s the best for us to go into because the companies in that space are extremely fast, and they push us to make the product as best as we can make it.

Ultimately, we want to be the horizontal platform that is the glue for any enablement tool or any financial tool with any merchant and small business in the world. The path to getting there is we start in fintech, get really good at that, then slowly layer on more types of APIs and different services that we can offer the rest of the enablement companies. In five years, we want to underpin any type of commercial activity that happens in the world.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.