Watch our second webinar with our co-founder and CEO Peter Zhou on the founding story of Rutter and deep dive into the future of fintech and commerce data. Peter discussed the founder's journey, why he decided to start Rutter, lessons learned during the founding and scaling phase of a startup, takeaways from working with some of the fastest-growing fintech companies, and where he sees the future of commerce data headed.
Hey everyone, I'm Peter, and we're going to do Rutter's second webinar. Today we're going to talk about the fintech founder journey. So how we actually came to starting Rutter and what that journey has looked like and then the future of commerce data. So what we're currently working on, what the landscape looks like, and what are all the things within financial services that we want to do next. My name is Peter, I am the cofounder and CEO of this company called Rutter. We basically do data infrastructure for commerce. Just a little bit of a breath background on myself.
I graduated with combined BS and Ms in computer science from Yale in class of 2019 and actually applied to Yale as a chemistry major, switched halfway through and then got really deep into the world of startups and tech during college. During my time there, I worked at Facebook on the payment platform team. So it was a full stack role covering messenger, pay and payment history. And then I was actually engineer number nine at a legal tech company called Atrium. They provided legal services and it was sort of a hybrid law firm and tech company, so empowering lawyers and paralegals to do their best work through automation. And I joined as engineer number nine in, I think it was January through August 2018. They were a series A company at that time.
My first taste of actually working at startups for real. Definitely a lot of lessons learned and it was quite a ride. I think that was like one of the experiences that I had where I realized I truly loved working on and building startups. Graduated in 2019, went straight through white combinator as part of their summer 19 batch, had about three years of iteration and working on companies that didn't work out until we started Rutter in February of 2021. And so I'll go a little bit more into that in a couple of slides, but just a really brief context on what is Rutter, what is the company that I'm working on right now? The first thing is that I definitely get a lot of questions on the name. So what is an actual Rutter? So just so that I can answer all of those questions, the inspiration for this company name came from a book called Shogun, which talks about feudal Japan. And back in the day, there's no such thing as Google Maps, there's no GPS or anything like that.
So if you were to navigate the seas as a sailor, you basically had a guidebook, and that guidebook was called a Rutter. So when we started this company, which does data infrastructure for commerce and helps businesses connect to merchants and SMBs, we essentially thought ourselves as the guidebook for understanding the commerce and accounting landscape. So that's how we came up with the name for Rutter. It leads into what we actually do. So the tangible product that we build is data infrastructure for commerce and our mission. So the thing that we aspire to achieve in the long term future is to empower businesses with new commerce experiences and the tangible on what we do. What does the data infrastructure for commerce actually mean is we are a single API for reading and writing data across any commerce system, payment, processor, or accounting platform.
So if you are a company, whether you're in financial services or you're a marketplace or marketing company, any company that sells to businesses or merchants, you need to connect and access their data and need to understand and be able to read and write that data. And there are a ton of different platforms where that types of data can exist. And so instead of you having to integrate into every single one of those platforms, Rutter is a single integration for reading and writing data across all of them. And so integrate once with Rutter and you can support and interact with data on any payment, processor, storefront, or accounting platform. So it begs the question, I graduated Yale 19 through YC, how the heck did we end up building a data infrastructure company? It's a very niche space and hard to understand how we got from graduating to where we're at right now. I'm going to provide a little bit of context on that actual journey, getting started with Rutter and then deciding eventually to focus on financial services. So back in YC, when we started in summer 19, we were actually an entirely different company called Lang.
And what that company did is it offered internationalization services. So we were a single piece of tooling and API for translating your website or your app into any foreign languages with professional translators. So if Facebook or if Venmo, et cetera, wanted to serve customers an audience in a different country that spoke a different language, we were basically the infrastructure that you would set up to enable localization and internationalization of your app. That was like our first foray into actually running a go to market motion ended up not working out for a bunch of different reasons, which probably deserves its own webinar. But long story short, we ended up not working on that idea at the end of 2019 and then decided for all of 2020 just figuring out what we're going to work on next. And so the evolution of what ended up becoming Rutter, it all started with a company called Cursive. So back in the middle of 2020, if you imagine this is basically like the first leg of the pandemic, all of the schools shut down and we were focused on building ed tech products at that time.
And so a lot of schools shut down and all of the students were basically forced to learn virtually. So what a lot of parents and students decided to do is create this thing called micro pods, where they'd basically get a teacher and have that teacher teach their children outside of school. So Cursive started as an identification of that problem, and it was just a marketplace for matching parents with teachers. Super simple, we didn't charge anything, it was just that we could understand more about the space and be able to interact with parents and teachers. Eventually we went down this rabbit hole where we ended up talking more to ed tech vendors. So people that were selling books and subscription kits, so we ended up more on the B to B side of things rather than interfacing directly with parents and teachers. And so eventually ended up working with education vendors.
And all of those vendors had this problem where their sales were going through the roof now that everyone was switching into sort of micro pod in person education and needed all of these education materials to enable that. So all of these etc vendors that we were talking to, their sales were going through the roof. They had their own storefront, whether it was on Shopify or WooCommerce, or Magento, or their own homegrown storefront. And now they're starting to digitize and sell on different marketplaces. So we constantly get these edtech vendors and subscription kit vendors asking us to help sync their inventory onto different marketplaces. So hey, I'm on Shopify, can you please help me sync my inventory onto Amazon? Hey, can you help me sink my inventory onto Etsy. I'm on WooCommerce, can you help me sync my inventory onto Amazon or Etsy and so on.
Vendor Pal was basically the product that we built as a direct to merchant offering for managing their inventory across all of these different channels. And what we ended up realizing is we kept getting merchants come to us asking us to help them with inventory, and they were always on different platforms. So obviously we started with Shopify, we get another merchant come in saying, hey, I want to manage my inventory across these different marketplaces, but instead of Shopify, I'm on WooCommerce. And then we get another merchant come in saying, oh, instead I'm on big commerce or I'm on squarespace. So what we ended up realizing is that we actually spent more of our time building this integrations layer for understanding what product and order information looked like and being able to read and write that information across all of these different platforms instead of building the actual business logic for managing the inventory. And so Rutter basically started out of this problem that we identified building a product to solve a separate problem. So we realized to build vendor pal, which was this inventory management solution, we actually had to build this integrations layer, or we're spending all of our time building this integrations layer.
And so that was really interesting for us. We ended up taking a step back and just looking at the landscape of people that need this integration layer. And we ended up realizing that it was actually quite horizontal and quite massive. So if you think about where we want to go in endgame and who our target audiences. This integration infrastructure is beneficial for any company that sells a product or service to merchants and SMBs and needs to read and write or interact with or understand that data. So it extends from anything from a marketing platform so like a Clavio or a CRM, like a salesforce or HubSpot to a shipping and fulfillment company that needs to receive orders and automate order statuses. So like Bolt Logistics or I guess now called Go Bolt or Ups or FedEx to the exact product that we built when we started with Rutter vendor Pal or any other inventory management platform like a saucer Phy or Channel Advisor to even marketplaces for supplier onboarding.
So if you think about how a marketplace like Amazon or Marketplace like Anchor Store or Fair loads up their suppliers catalog information and routes orders that are placed on that marketplace back to the supplier, we are the infrastructure for them to do that. And then the last bucket here is financial services. So a lot of financial services is underwriting businesses and understanding their financial health. And that financial health information. Same problem as with all of these other categories of companies. There's so many different platforms to get that financial health information and every platform has their own way of expressing it. We are the single API for financial services companies to read and ingest that financial information across any commerce platform, payment, processor or accounting platform.
And so classic early stage company, we have all of these different customers. It's a very horizontal product. We decided that we really want to double down on financial services. And the core reason why is because that sector is where we had the strongest momentum. And we're a startup company. We basically optimized for speed of product iteration. And there are a ton of different fast moving companies that are our customers, that are people that we work with within financial services or fintech.
And so we decided that in order to optimize for speed of product iteration, it was really important that we work with all the other fast movers in the space. That's why we decided to focus on financial services. So that's a little bit about our evolution. To being a fintech company from all of the different ideas that we worked on as part of YIC, to creating vendor pal and realizing that we had this problem with integrations, to realizing this entire landscape of all of the companies that need this integration infrastructure, to finally focusing on financial services. Now, I'm just going to talk a little bit about what we've learned operating in this space for the last 15 months and what we think will happen in the future. So, the first thing that I want to talk about is the underwriting staff. What we ended up realizing, if you are a company that underwrites businesses or provides a loan or credit to businesses, we are one player in this space of all of the tools that you'd end up using as that lender or that bank or that credit card.
And so this is basically the rough abstraction on how we think about the underwriting world and the underwriting stack. So just to start, when you're a lender or a bank or credit card or a business insurance company, you actually need to understand the business that you work with. And so the first thing is making sure that they're not a fake business or that they're actually real and not going to just disappear in a moment. So you probably work with a KYC or a KYB provider like Middesk or an Experian. The next thing is understanding the data that comes from that business or that consumer, if you're an underwriter for consumers. And so that's where the next layer comes in, which is data aggregation. So Rutter for commerce and accounting data, plan for banking data and payroll data, and then Pinwheel for payroll and HR data.
You probably use a fraud or anti money laundering tool to understand the transactions going through and do real time transaction monitoring. So like a Unit 21 or compliant manage, you might have a decisioning tool to automate the way that you decide whether to offer someone a loan or whether to underwrite someone to like an alloy. And then if you have a risk analyst that you work with internally, you probably also need a visualization tool because that person can't just ingest data into their brain via an API. So you probably work with a tableau or what we've commonly seen just like plain and simple Excel. And then those are basically the atomic elements of what we understand as the underwriting stack. You basically have these bundlers that orchestrate and combine all of those elements into a single product that offers some type of financial service, whether it's lending as a service, cartridge, screening as a service, baking as a service, and so on. So examples of those players are like a landflow or a unit or marketa, or lithium.
And so I already alluded to this. Rutter basically sits at the data aggregation layer. So if you think about the entire puzzle of all the companies involved in underwriting, we are that one portion. We are used in complement to Applied or a Pinwheel to understand someone's financial data. So if you think about our charter as a data infrastructure or data aggregation company, it really is all about collecting and understanding data. We don't make any decisions on it, but our objective is basically to provide as much and as full of a picture of financial data as we can. And so talking a little bit about the future, the future is basically building this full business picture.
In Fintech specifically we'll talk about building the full business financial picture, but it is really understanding all of the ins and outs on what makes a business work. If you think about the data that we work with today, we're commonly used alongside banking data and all of these three sources of data, commerce and accounting, which is provided by Rutter, and then banking data, which is provided by a plaid or a stripe or an MX or Finicity. All three categories of data have their pros and cons. So the way that I thought about it is on four axes. So correctness retrieval, breadth and depth, and just listing the pros and cons of all the data here, commerce data has really high correctness. It's real time. Any transaction or any purchase made on a payment processor or a storefront is reflected immediately in the API.
Correctness means that the data is accurate. And so it's very hard to fib or make fake commerce data since it comes directly from that system of record retrieval, basically. Meaning, do you get all the data from that entity that you showed. And so because it's not manually entered, you have very high retrieval for commerce data. But you do suffer from two things. You suffer from low breath, and it being revenue only data. And so you miss the cost side of a business when you only look at commerce data and you also suffer from low breath, where a business can operate on many marketplaces or have many different storefronts.
So connecting a single entity from a commerce platform or a payment processor may not show the entire revenue side picture for a business. Accounting has its own set of pros and cons. So it has high breath. People usually work with one accounting system or have one general ledger that they work with. It has high depth. And so you're able to get skew level data and customer level data for all transactions and purchases made. It shows both revenue and cost data.
But because it's human entered, some people might have different cadences that they update their books, whether it's closer to tax season or every quarter or so, it might be out of date. There's very low correctness, and then they have medium retrieval. So they might miss some things because it's human entered, the books might not add up and so on. And then baking has its own set of pros and cons. It's always real time. It has high correctness and high retrieval. It shows the entire financial picture.
Companies might be on different banks or have different bank accounts, and so it has medium breadth. But the main flaw for banking data is that it's low debt. And so, whereas commerce and accounting data show you skew and customer level information. So who's bought what product, what the actual product was? So what the skew of that product was. Baking data suffers from just being money in and money out and then a description. And so there are just entire categories of companies that try to categorize and understand banking data. And so that's basically the current state of things.
When I talk about the future and where everything is headed for fintech it is having complete financial health understanding. And so, if I allude on this slide, there's pros and cons of working with all this data. All of these three categories of data really just slice up what is the full financial picture of a business. And so what you really want is to be able to connect and relate all of those different categories and create this cohesive picture that solves for every single category sweetness. So you want real time data with high correctness, high retrieval, high depth, all of the depth, so all skew and customer level data and then covering both revenue and cost data. So, if you think about how we get there, this is basically where the future is headed. Well, all of the different categories are just different slices of a business.
And so the next step is basically combining all those slices and building that full picture. And so the first thing is that those three categories might not represent or might not be the correct abstraction for all of the data. There's also marketing data, understanding where you're burning money and how burning that money returns to the business is super important. And that's usually reflected in buying inventory or spending on ads. And so understanding return on ad spend and understanding marketing attribution is one of the next steps here. Understanding all the other sources, so understanding your consumers, so who actually buys the products that you're selling, what is their demographic look like? Understanding warehousing and inventory data, so understanding how much free cash flow you have, how much inventory you have in stock, what the freshness of that inventory is and then understanding software spend. I put a little bit of an asterisk on that because software spending is just so broad and I'll talk a little bit more about verticalized finance in a couple of minutes.
But basically understanding all the different tools that you use that are not just commerce, accounting and banking. Once you've pulled in all of those sources of data, you want to be able to interrelate and understand where each part of that data fits in with each other. And so the next part is reconciling all of that data with one another. The first is using banking data and reconciling all the transactions, banking data to the transactions that you find in your accounting ledger, to the payments or the orders that were placed on your commerce platform. And then further understanding the picture and the breadth of information that you have. So, using all of the unreconcilable data within your banking platform or your sources of truth to understand all of the sources of information that you don't yet have with your existing platforms that you're connected with. And then as a fallback, instead of attaching source of truth data, so your commerce or accounting data to banking data, if you are unable to get that data, the fallback to understanding a little bit more is just inferring a categorization.
And so there's a ton of companies that are dedicated to just categorizing a bank transaction or credit card statement based on the description. So it is not source of truth data because it doesn't come directly from the point of origination, but it provides a better picture than having it be completely uncategorized. And so by doing all of these things at the core, one is pulling together all of the different sources of data and then two is connecting all this together. We can build a financial picture that has all of the pros of all of the different categories. So it's real time, it has all the data that you need in as much depth as you need. And so it's not just pulling in the data, but it is understanding and being able to compare that data. And so that is one of the core reasons why data infrastructure and data aggregation exists.
When you have a unified model for abstracting and understanding a bunch of different platforms and grouping them all into a single segment, what you're basically doing is making data from those different sources interoperable. And so whereas before I would have to basically try to figure out on my own how Amazon data or an Amazon store is performing versus a shopify store which has a completely different way to represent its data. Now with a unified model and a unified API, it is very easy to better compare apples to apples on this Amazon store's revenue and performance versus Shopify stores revenue and performance. And so if you think about future products, what is enabled? So we're sort of seeing this sliding scale on underwriting and lending becoming more and more granular. So the first thing is just personalized or verticalized finance. And so historically the main way that you'd offer a loan or underwrite business is just via their cash flow. And so very simple what companies realize nowadays is that there's so much more information reflected in your commerce platform or your accounting platform that you can take advantage of to offer a better loan.
And because loans and underwriting is all about capital and it's largely commoditized the better the offer, the more of the market that you do it. And so now people are coming up with different ways to underwrite businesses. So instead of just looking at cash flow, for instance, Ramp here looks at commerce sales, other companies so like a kick further look at amount of inventory that you have and what inventory sells. Well, there are other companies that offer equipment based lending and so on. And so that is basically lending on a specific category or a specific vertical in the long term future. What this enables at a really granular level is that financial services are underwritten at the transaction level. And so historically, what would be involved in underwriting or giving a loan to a business is you give them some lump sum of money and basically give them the freedom to decide what they would spend that money on.
Well, now, if you understand and are able to categorize all of the different things that a person is spending on, or all of the different revenue streams that that business has, you can now underwrite at the transaction level. And so understanding, like, buying this amount of inventory is a positive ROI on the business. And so we want to underwrite and cover that versus like, oh, we now know that spending money on this ad or on this channel is not really good for the business. And so we won't underwrite that. And so instead of just providing someone with a lump sum of money, you can now underwrite at the transaction level and approve or disapprove specific purchases. And all of that requires an understanding of the effect of that purchase on the actual business. And so that leads into the next future breakthrough, which is quantifiable ROI.
And so not only do you gain an individual understanding of how that one business is performing with the Unified Data Model, you can understand how all of the businesses that you interact with are performing. And so one example I like to give here is your CRM software. So now that we have categorized someone's spend and we can see like, oh, this person is buying the software tool, let's say they're buying HubSpot, we can now compare all of the businesses that have bought HubSpot and their revenue to all of the businesses that have not bought HubSpot or have bought some competitor and the revenue that they have. And that gives us a rough understanding of the actual quantifiable impact that buying HubSpot would have on a business. Obviously, there's a lot more caveats on different types of businesses, different business circumstances and so on. But being able to understand that financial health and categorize that spend starts getting us to that place where we can now say, like, this is the actual ROI that a HubSpot would have versus a salesforce versus an outreach or something. And so in the last couple of minutes before I open it up to Q and A, I want to talk a little bit about emerging product categories.
So one of the ones that we've seen when I allude back to the underwriting stack is Embedded Lending. Paraffin and Lend Flow are really good examples of this. So instead of providing a direct to merchant lending service and having your own website and relying on owning the customer experience and drawing merchants to your site, now you can offer lending in partnership with another marketplace or another platform that already has merchants. So a lot lower cost of acquisition for getting a merchant on and being able to provide that service at a much higher conversion directly in the platform that that merchant's on. So an example here is Paraffin offering lending for DoorDash merchants instead of that merchant having to find a specific lending provider. They can just go to a DoorDash dashboard and receive a loan directly inside of DoorDash. I already mentioned verticalized banking and Credit, Mercury and Ramp both deciding to focus on ecommerce and also startups.
Each of those segments has different spend patterns and different revenue patterns. And so what we'll end up seeing is that every single category of business, every single industry of business will have a specific way to interpret that business's data, whether you're an agriculture company or you're a biotech company, or you're an e commerce company, or you're a traditional SaaS company. And so you'll have a specific expert on being able to provide credit and loans and underwriting for each of those categories. This relates very closely to verticalized credit and banking, but it's slightly different, not only being able to understand someone's revenue coming in via their orders and transactions data, but also understanding when that revenue hits the bank. So understanding their payouts data exactly the same as like an earning. We can provide better cash flow and instant payouts as a product to merchants or businesses that you work with that rely on payouts from a platform to their bank account. So high beam and hatch being example customers here and then the last category that I wanted to point out, going back to the HubSpot analogy, once you are able to categorize all of a person's spend and understand their tooling, whether it's their inventory provider or some type of marketing software and so on, now you can understand the ROI of that.
You can understand how other businesses or what the other the spend of other businesses are on the exact same tool. You can help a lot with procuring and providing suggestions on what type of tools people should use and how they can negotiate pricing. And so Vendor and Cloudmore being examples there, I'm going to open it up for Q and A now, if anyone has questions. All right, I see some questions coming in. So the first one I have is what is on the roadmap for Rutter? Yeah, that's a really good question. So I think of the short term roadmap going back to our charter and financial services is basically pinning the full financial picture. And so if I think about the short and medium term roadmap, it is basically one as a universal API that enables interoperability of different platforms in a certain category.
It is enabling coverage of those platforms and so rolling out all of the integrations within payment processors or storefronts or accounting platforms that you'd ever need. And so you never have to worry about building a bespoke integration or one off integration again. So the first would be platform coverage, and then the second would be reconciliation and data cleaning. So once you're able to ingest all that data, the next step towards building the full financial picture is being able to understand that data. So categorizing that data, reconciling all the different. Sources with each other, that would be what's next on the roadmap? Great. The next question is what has been the most challenging thing about scaling from a seed to Series A? Does this refer to personal challenges as a founder or company challenges? I guess I can talk about both.
Yeah, talk about both. Sure. I'll start with the personal challenge. So most challenging personal things from C to Series A is definitely delegation. So you get to a point where you can't write code anymore as the founder and there are just so many things to do that you can't do all of them by yourself. So bringing on the right team and empowering them to actually execute on those things I would say was one of the personally challenging things as a business. Scaling from seed to Series A.
I would say in the early days when you're a seed company, just finding product market fit, you're able to give a very personal interaction to all of the customers that you work with. And I think the challenge of scaling is figuring out how you can offer that same experience to all of your customers when you have ten times or 100 times more customers. And so that's probably like the main challenge of C to Series A is understanding scalability and repeatability. The next question is where can I find the whole list of integration platform coverage Rutter has? Yeah, that's a great question. So we support a whole variety of payment processors, storefronts and accounting platforms. You can find all this in our Docs. So Docs Rudderapi.com, I think there's a tab on the side that shows supported platforms.
The next question is how will the lending and fintech space be impacted by the recession? That's a good question. I do think that the volume of loans that will be offered. So if you think about it from first principles, it starts on the consumer level. So in a recession people are less willing to spend, which means that businesses sell less. And so when you take on a loan it is to accelerate the business. And so people will probably be working a little bit slower and not as willing to ask for a loan because they're not sure what the return is on that. So consumers will be impacted primarily and then as a downstream, you basically get businesses impacted.
And so I think what we expect in the recession is for the overall quantity of loans out to businesses to go down. The interesting thing there is that means that the bar for approving a loan becomes a lot higher and that is where data infrastructure and being able to actually understand that business beyond just their cash flow becomes even more. And so just like a TLDR, the quantity of loans will go down and then the quality of loans has to go up. All right, what are the biggest challenges you're focused on right now as CEO? Interesting, it definitely goes back to the question about scaling from a C to series A company from series A to series B. It is all about proving that a dollar in equals a dollar out and proving repeatability and scalability. And biggest challenge for me is building that machine and understanding and being able to delegate responsibilities to the right people. Awesome.
So that's all the questions I'm seeing for today. I think we're going to wrap it up now. So if you could please fill out the survey and the chat that would be my much appreciated. Thanks everyone for joining us. Thank you Peter. And we hope to see you at the next one. Yeah, this is a lot of fun.
Let's do this again. Thanks everyone.
Subscribe to newsletter
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Stay up to date with the Rutter blog
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.