"Plaid for X" startups

Led by companies like Plaid, universal APIs enable developers:

To learn more about how universal APIs are accelerating developer productivity and creativity, we teamed up with Sandhill Markets to host a panel conversation with:

Transcript below.

Adam Hardej:

Today, we're talking about what it's like building a universal API company and some of the go-to-market related to it. We'll start relatively simple and then, move into some of the strategy, their experiences as founders in the space, making decisions such as whether to be vertically focused or more horizontally focused with their product, as well as competition in the landscape.

To give you an example, think of Plaid. A big API integrations company and probably the most common version of what we've thought about here. You may have experienced it, seen that Plaid offering, and if you've ever built a product with Plaid in it—rather than integrating with a bunch of banks, you can just integrate with Plaid and they handle it—that idea of integrating with one thing instead of a bunch of things, and getting out of the integration game, is really what's been a lot of the inspiration behind these companies. 

Sara Du:

I'm Sara. I grew up in Atlanta. I started coding as a teenager. Got into the open source world when I was pretty young, so I was playing around a lot with RPA frameworks and various other open source libraries. That led me to Alloy. 

I eventually started Alloy with a longtime friend in 2019. We started life as this no-code automation tool. At the time, Zapier did not have for loops and a bunch of these functions, so we just built a different version of it. It took off on Twitter (now X) and Product Hunt and we actually became known for our commerce use cases. 

In the first two years of the company, people knew us as this Zapier for commerce. A few years in, we actually got a lot of requests from our partners to white-label our platform and that's how we got into the embedded integrations game. 

We've been doing embedded integrations in this unified API for one and a half to two years now, depending on how you count it. Today, I guess, the latest is in terms of fundraising metrics or series A, backed by Andreessen and Bain.

Jeremy Zhang:

I'm Jeremy Zhang, C.E.O. and one of the co-founders of Finch. I come from a product and engineering background and have always been in startups. Prior to Finch, I was actually also in an API company. We were building API infrastructure on top of physical vehicles and road infrastructure. 

What that meant was, there's a lot of different makes and models of vehicles on the road connected to the internet and sending vehicle telematics data and receiving commands. We built and standardized a communication protocol with the vehicles on the road. So basically, another unified API company in the very different automotive sector. 

I was an early engineer transitioned to the head of product of that company. I met my co-founder who actually was also tied in this space. He was an investor and client of Finch for four to five years and invested in companies like Plaid and Brex etc. You mentioned Plaid, but that's another unified API in the financial services sector. We knew we wanted to build an infrastructure product. We wanted to build an API product. We landed in the employment sector. 

What Finch is building is a programmatic API on top of employment systems. The three main ones are HR, payroll, and benefits. Kurt was just talking about this, but we connect employers and act on behalf of employers to connect to applications. So there's two layers that we do. 

The first is pulling data, which is things like employee directory, company pay statements, benefit contributions data. 

There's a second layer that we launched a new product on earlier this year, or earlier last year, that maybe people don't have a good understanding of, which is actually applying payments. So, the first product there was adding deductions and contributions into the payroll rails. Another product we're thinking of is adjusting earnings, enrolling in benefits via an API through our infrastructure.

Kurt Lin:

I'm Kurt, co-founder and C.E.O. of Pinwheel. We're a Series B fintech infrastructure business. We have an API, but we think about it as a network that we've built directly in partnership with payroll providers and HR systems like an ADP, etc. What we've basically convinced these payroll providers to do—which is different from what Jeremy's said even though it may seem related—to re-architect their systems. 

Pinwheel is solving a problem that is core to all consumers in the financial services world. When you think about it as a consumer and how you engage with anything in financial services, it requires data. When you want to get a mortgage, a credit card, an auto loan, and a bank account, you need to provide information about who you are, how much you make, where you work.

Most of that data is locked away in these walled gardens that we call payroll systems or HR systems. That information, if it can be unlocked and that data can be put into the hands of a consumer, allows for a ton of really powerful and amazing things to happen. Use cases like instant income verification, underwriting in real time, direct deposit switching, earn wage access, automated taxes, all of these things can only exist on a platform where you've actually integrated into all these different payroll systems and unlocked that data at the employee and consumer levels—not at the employment level—which is what Jeremy and the Finch team are working on.

Some delineations here—Kurt and Jeremy, more focused on B2B kind of sales, whereas Sara, a company would be using it but with a smaller focus. What's an example of someone who's using Alloy or your kind of target customer? We'll go back around the room with target customers.

Sara Du:

We are actually B2B and today, we're totally focused on SaaS as customer base and mid-market, usually. One of our larger customers, for example, is Amazon. They have a product called Buy with Prime where merchants can essentially embed a Prime button on their store regardless of if they're on the Amazon Marketplace or not. In order to do that, they actually need to sync products—their product catalog from say, their BigCommerce or Shopify store—and their NetSuite and QuickBooks. You can think of any SaaS company whose users need ERP/CRM or commerce integrations we can service.

Is this where the unifying aspect of all of the things that you all do—instead of them building separate integrations for all of those points—going to flow into Alloy? Is Alloy going to handle it and spin out the one kind of touch point on their side?

Sara Du:

We have both the unified API and then, with embedded iPaaS, that's actually a bit separate. Technically, it's point to point and it enables more configurability.

Kurt, what's a target or a typical customer for Pinwheel? Obviously there's bigger customers and smaller customers, but let's talk about typical?

Kurt Lin:

Our ICP fits two buckets. The easy way to think about it is that our customers themselves are consumer businesses—mostly consumer fintechs and big enterprise banks. The examples on the fintech side would be Cash App, Credit Karma, Dave, Current, Varo, Acorns. On the big bank side, we have American Express, Discover, Citizens, and many more. 

They serve these consumers, but they need a better understanding of that consumer, their income, their employment status, etc., to do everything for example, from approving them for a loan to offering a whole new product to them that they couldn't do without that data, or without access to their payroll settings for direct deposit switching. 

We help them enable that for everything—from a seamless account opening, for a one-click direct deposit switch, to underwriting them for a mortgage—all at the same time with a frictionless passing of the information.

Jeremy, over to you for the last part. Then, we'll zoom out a little bit and talk API, more generally. 

Jeremy Zhang:

Finch currently has three API products—organization, pay, and deductions. We have different customer focus and different customer base for each. 

On the organization product, the goal is to be able to pull back directory data census—who's reporting into who, management structure, etc. The customer base here is mostly HR and B2B SaaS tools. 

Our second product is our Finch Pay product, which is pulling back detailed pay statements across the employer. So, it’s not on a specific employee, but every single employee within that employer. The customers here are using this information to either underwrite the business or specific employees at the business. So these include B2B fintech like workers' compensation, general liability, business lending, taxes, etc.

Our third product is our first product into the payments layer—the deductions product. This allows a customer to be able to write deductions and company contributions into the payroll rails. This opens up the entirety of the benefits sector. The two main categories there are retirement and health insurance, but there's also fringe benefits like financial wellness and mental health.

How does one come to build the API market? If we take a very below the radar business that requires a lot of understanding of actually building products, then, it's very different from maybe the more common and in-the-news startup like maybe a Cash App. That is a great example where everyone experiences Cash App but no one understands the fact that maybe Pinwheels is supporting some of the tech underneath that. 

How do you describe building in that type of market? Sara, do give a little bit of background there on what brought you into building specifically in the API space. Jeremy, tell us about your experience in the API side from a business perspective. 

Sara Du:

On the personal side, it was just building with a lot of API frameworks. From a business perspective, it was just as a developer at these companies, but I noticed there’s a lot more apps out there these days. There's more SaaS. Everyone talks about this Cambrian explosion and it's true. 

We were in the Shopify app ecosystem for so long and we started working in that ecosystem in early 2020, and then, just 2020-2021, you saw this huge explosion and all the different partners in the ecosystem were getting requests from their customers to integrate with 20, 40 other apps. No one can keep up because there's a new dominant player in every layer of the commerce stack every few months. That's what led to all of our partners demanding that they could white-label our tool and so we almost got pulled into that because of this ecosystem growth.

Kurt and Jeremy, I guess different sectors but similar? Growth of the need for integrations?

Kurt Lin:

Our story is actually a very specific archetype and it's actually very similar to the Plaid story where we actually began our journey trying to build an app ourselves and then uncover the problem. Back in 2019, we were trying to build an automated health savings account app, which by the way, here’s a disclaimer, somebody should build this thing. It's a great idea. It's a problem that needs to be solved. 

Basically we saw that a bunch of people could benefit from the savings that HSA would provide, but no one knows how to use these things because they are super janky. We were like, if someone connects their spending accounts with an aggregator, we could look at all the relevant transactions and then, pick out the medically qualified ones, go back in their payroll system and automatically handle all the contributions, and make sure that it actually ends up being completely automated. They just get tax savings added to their paycheck every month.

To enable that required us to connect to all these different payroll and HR systems. We looked around and didn't see anything. We built this platform internally just to power our own app to actually make it work and then realized that there were thousands of other companies out there that were like us trying to build new products but needed the same access into these payroll systems to actually power the app and make it work.

Once you realize that, we're like, “Oh well, there's a way bigger opportunity here for us to still serve the core mission. But instead of being on the app layer, let's enter it into the infrastructure layer so we can help builders like us achieve that same vision.” That's how we ended up where we are today. I think it's very similar to, “Oh! I-feel-the-pain-myself story, so I'm going to go build the solution.” 

You also asked this question that, I think, is interesting about “Why build the API?” When you say universal API, I think there's two pieces. 

One, is aggregation and two, access.

Aggregation is like nobody's going to sit there and try to integrate thousands and thousands of payroll HR systems. Only Jeremy and I are crazy enough to do that kind of shit.

Two, access. It's also hard as hell to get access to these systems. You're not going to build a team internally to go do this. That's why this universal API contract is so important because somebody needs to do it, but it's not going to be your internal team.

Jeremy, you came from building in the API space before so you were familiar with that. But it sounds like you explored a little bit in the space before deciding to focus on what you do now?

Jeremy Zhang:

Yes. Just to add to Kurt's thing, you might actually have this under the aggregation side, but another aspect of universal API is the standardization, and actually having a single data model that is consumed versus thousands or hundreds of thousands.

Yes, I worked in the API space. I also think it's because I come from the engineering side so just purely from a product standpoint and understanding customers like the API interface is a lot easier for me than trying to build a consumer product or a B2B banking product. That's purely on the personal side.

In terms of the business, when we build products, we think about not in terms of building integrations, but unlocking functionalities in the underlying systems. It's what we call primitives. For us, one might be pulling directory, one might be applying deductions. Of course, to be able to do that, you have to build the integrations. But when we're selling to customers, we are selling these functionalities and valuing these functionalities for our customers. 

I know Kurt is nodding along because you also do the same thing with direct deposit switching. It is a full functionality that you're selling to banks. We believe that by unlocking these functionalities that previously were inaccessible, we're actually allowing new applications, new use cases to be built on top of us that we might not have thought about in the past.

This is all super heavy engineering. It's really messy because you're being paid by companies to deal with the messy things that they won't want to deal with. Talk a little about what it's like building—because no one wants to deal with a hundred or a thousand integrations, so just come to us and we'll deal with it—but then you have to deal with it. 

The common complaint can be about Plaid when something screws up in Plaid. I've had friends who've built on Plaid before where some random bank and some random place will change part of the way that they expose data and it breaks and then you have to go and within the company building and thinking more about building an organization that handles this, are you building on top of systems that are moving? 

Do you have to constantly fix things? Do things get to a steady state? What's it like? It's easy to say to the customer, “Hey! Don't worry about it, we'll handle it.” But then internally, is it just a shit show all the time or do things get pretty steady? How does that go? Sara, I think you all deal with this.

Sara Du:

Yes. For anyone who does a unified API or any API middleware where you have to deal with endpoints that are discontinued or deprecated, fields changing, field names, we liken it to gardening. There's always going to be weeds. For some partner companies—especially the ones that are less mature and have a worse rollout or release cycle—we have tests in our CI where we can proactively catch those changes. 

I wouldn't call it a shit show. It's more just part of the business. It's like a headache and you develop systems to make it just less of a headache.

Kurt Lin:

I would add to what Sara said. 

You mentioned Plaid. It's really important to understand the nature of the integration. I might have been talking technically. A lot of folks, including us to a certain extent, build integrations without a direct partnership with the other platform. Call them scrapers or whatever and those exist because that data needs to be unlocked. At least from our vantage point, where we are in the consumer financial world, there's actually a regulatory reason why we have to do it, because consumers need to be able to access their information at any time. It's their data. But that doesn't mean that the partner on the other side sees it the same way. 

A big reason why historically some integrations or some platforms have that issue is because they're trying to build connections where it's really like—I wouldn't say unwanted, but it hasn't been a formalized partnership—and that's how a lot of early companies start. That's what you have to do often to get going.

We believe that eventually, for you to be successful, you can't be in an ecosystem where your partners don't want you to exist. That's just not a good place to be. We realized quite a long time ago that in order for this to really be a big business, you have to sign partnerships with folks and then co-build these integrations together, because not only does it lead to much higher conversion rates, much more stable integrations, it also actually is really important that they feel invested. That’s because you can build integration and just let it deprecate, not take care of it and stuff, but as you send more traffic to a more partnership, you need to continue to invest in it and make it better and change as you go, and eventually deepen the partnership with more and more data being shared or added to the model, etc.

Actually it's funny because I think integrations are actually more relationships more than anything else first, and their technical part actually is the table stakes piece after the relationship has been built.

Interesting. Where you need them to, I guess you can bootstrap in and be like “We're going to scrape it out. We don't have to talk to you.” But in order to be an enduring business and something that lasts, they need to understand the value that you bring to them and in order to make it something that's sustainable. Same with Finch?

Jeremy Zhang:

Yes. I know you were talking about how people complain about Plaid's reliability, but in the end, Plaid is at the forefront. They probably could not build a better product in-house. Plaid is doing everything they can, of course, on the technical side, the monitoring, and also on the partnership side to push the industry forward. A lot of times it's just the state of the industry, not that Plaid has a terrible engineering team and creates all these errors.

Plaid is also amortizing the cost of building this infrastructure, the cost of air handling the partnerships across the sector so that none of the consumer applications have to do this sort of work. But that's how I think about Plaid. 

For us, we do operate in a space where there's not too much APIs. This is a sector that is transferring hundreds of millions employment records and trillions of dollars mainly through .CSV upload, SFTP, EI file feeds, like human manual operation. We're definitely trying to push the industry along, but that does mean for us, a lot of times we do have to connect to the SFTP file feeds or the EDI file feeds, but we return to our customer the API kind of standardized API that you would expect for a tech company.

It's nice to see the API found a camaraderie in defending Plaid. “It's not their fault actually. They're doing really great and they're doing it for you.” That's actually, it's like a sign of the luxury of Plaid. It's a sign to complain about Plaid, "Oh! There's a thousand banks on here, but sometimes it breaks. It's such a pain." Actually, they're handling a lot of it and they're covering the cost of it.

One thing that came up is how the industry is moving. Then, on the usage side, building, people who are the API and the universal API market has grown substantially. Can you weigh in on how you've seen this industry change within, again, the partners that you're talking to and maybe their openness around it, as well as how you've seen usage on the people on the other side of the API. 

Sara Du:

Yes. At our end, in terms of dealing with partners and approvals and marketplaces, it's usually that a lot of these marketplaces don't know how to categorize unified API or IPaaS, and they try to fit you into something else. These days there's been a trend towards some of the larger companies trying to figure out data governance or how they should audit us. 

We're also not just a unified API, we're also this iPaaS. That becomes trickier, because technically we're stuffing data from their system into plenty of others and can really help with migration from one tool to another. A lot of partners don't like that. We are treading a fine line with some of these partner marketplaces. 

To Kurt's point, it's a very subjective building the relationship—if you have the right people inside, it can just help you get expedited, approvals, and asking for certain endpoints that don't exist. That's been really helpful for us.

Kurt Lin:

Yes. Adding to what Sara said, there's a couple key questions you have to ask. One, what is the philosophical point of view of the partner? Are they fundamentally an open or closed ecosystem? Some platforms just believe that they own their data and that it isn't either their right or it doesn't behoove them to create an open ecosystem.

To your point about how things have changed, if you were to poll the same companies 10 years ago, the majority of the people that we work with today would've been like, "No freaking way. This is our data. This is all the value. Why would I give it to you?" With the advent of these open ecosystems and seeing developers or whoever come in and build a ton of amazing new applications on top of things makes a huge difference. 

The example I used to give was like when Facebook first opened up their platform, I mean, Zynga was a billion-dollar business that was built on top of Facebook, with all these social games. If you leave it to folks to get creative with an ecosystem that can really benefit you and the data that you provide and ultimately, your customers, not everyone sees it that way because there's another argument, especially with all the different AI tools being built right now, that data is the value. So, the last thing you want to do is dole it out and all of a sudden you lose your key advantage.

I think the reception of that partner, based off of whether they believe they should be fundamentally open or closed, is the first question. Then, if they are open, it really has to be, are they architecturally set up to do what you want to do? 

The thing that we found with payroll providers is that they're not set up to allow for user permissioning. It's a system that is meant to serve employers. So, to get them to re-architect their system to allow an individual employee to share their information out was a huge uphill battle. You have to make the business case that this is actually going to hit their bottom line in a way that's really impactful. Otherwise, you're not going to get anywhere.

You start to get to this weird cold-start problem, where—I went to ADP three and a half years ago and I got laughed out of the room when I was like, "Hey! We should partner together," and they were like, "What rev share are you going to give me that's going to get me out of bed?" I was like, "Well, maybe I'll come back to you in a few years."—but, you have to present a strong enough of a reason for them to actually act. 

It almost always is something commercially driving them, opening up their ecosystem, because they’ll make more money if it's open instead of being closed.

I'm interested in the ‘building the business case on the partner side.’ In your ADP example, how is that going to work? How are they making money? I, from a fundamental perspective, understand what you had shared earlier too—it is the consumer's data. What you get paid? What’s your payroll? Where’s the money's going? All this is things that they can access as users. But, you asking them to spend engineering resources to reconfigure themselves, what are the arguments there? How do they make money in these situations, if they have to reconfigure themselves to make it available, but then it gets brought to be used somewhere else?

Kurt Lin:

For any payroll company or basically anyone who has data, they need to examine each and every use case and understand if it fits within their view of the world and where they want to go as a business. So, if you can convince whether it's a payer-provider or anyone else, that opening up the ecosystem enables a ton of new powerful use cases that will ultimately help their customer, then it ends up being a win-win.

In many ways, it's basically adding on a value-add services marketplace onto their core business. So you say, yes, your core revenue stream is selling payroll services to employers. But, if you connect into Pinwheel and you allow those employees to get better checking accounts, better savings accounts, a better mortgage, a better credit card, better whatever, now you're adding a lot of value to those employees and eventually that employer. That's just going to help your business grow and we make money off of you. 

So, why wouldn't you do this? 

Sara and Jeremy, is that a general way to think of these partner conversations? Is that generally the pitch that's being given?

If it's a situation where they don't already have a built-out API system, which, I know there's both, there's situations where they already have APIs that you're just integrating with and making it easier for people to not do it. But then, there's also these partnership conversations where you have to convince them to do it. Is that generally the framework that you guys have experienced?

Jeremy Zhang:

Yes. On our side, I do agree it's very important to show value to the end providers. I think of infrastructure, or at least unified API infrastructure companies almost as two-sided marketplaces, where it's like you have the applications built on top of you, but you also have the partnerships with the underlying providers. If you don't have the partnerships, then, there's not going to be any apps built on top of you. 

That's actually one issue I ran into in my previous company, where we were trying to partner with these car manufacturing companies like Ford and GM. It was taking a year and a half, but we didn't have a product because we didn't have access to the data. So, it was this cold-start problem that Kurt was talking about.

However, at Finch, we were able to show our partners like ADP or Gusto that we already support 8,000 of their employers. Here's what they're using our APIs for, it's benefiting your customers. That is a lot more concrete than going to them and being like, "Oh! We're building this API on top of you and we need access to your APIs."

It feels like a little bit of a building wave where, and I'm trying to touch on the momentum of the space, because it seems like once it opens up a little bit and once someone offers it, like, once one payroll provider has a value-add services marketplace built on top of their data, it's really hard to not have it, because you're going to look like you're not adding as much value as the other. You get left behind. Is that something that's happened recently? What's the timeline on that from partners being more open? Am I misrepresenting how that's moved?

Jeremy Zhang:

I do think that's the case, especially the value of a unified API company is larger in a more fragmented ecosystem. Therefore, there's definitely way more competition between the underlying players. So, if even a mid-level player or maybe the largest player is now adding this service or more applications are integrated with them, then, that's going to drive other players to see that this is a direction that the industry's going and form these partnerships.

One of the things I want your take on is this idea—as an API company, this idea of horizontal or vertical focus—and it sounds like there's a little bit of all of that. Do you have really strong feelings either way? Is it an ongoing conversation how you think about, again, this horizontal offering? Because we're using the word "universal" a lot, which would make it sound like, "Oh! It's all horizontal." But, the reality of it, that you could be a universal API that focuses on one specific kind of vertical. Sara, for example, you all were very active in the Shopify ecosystem for a long time. Is that where you got started, but then have built out of that since?

Sara Du:

Yes. Yes. We think there's two ways to cut it. I'm curious how others think. There's the apps you focus on integrating with. So, it's like you specialize in ERP integrations or commerce or payroll integrations. 

Then, there's the audience you serve whether that's like SaaS or financial services, whatever that is. 

We started out commerce to commerce and then, we became ERP and CRM and commerce integrations for commerce SaaS, because we wanted to focus on building this brand reputation. Like any commerce SaaS company, they see the big players in this space like Gorgias, Postscript, Amazon trust Alloy to power their integrations. You build up this flywheel effect. I think it's hard to be everything to everyone. So, realistically, most players have to just choose a couple in each access to focus on. 

For us these days, it's really being actually best-in-class for ERP, because we like to handle integrations that require some end-user configuration and then, being the best ERP for ERP integrations for all sorts of B2B SaaS companies. So, mostly SaaS, still.

Kurt Lin:

Yes. Another way to look at it is also that people make this common faulty assumption that all API businesses grow the same way. It's actually very fundamentally false, right? There's these classic API infrastructure businesses like Twilio, Stripe, and people assume, "Oh! Well, let's just pattern metric against that." 

The thing is with folks like Twilio and Stripe, the motion was fundamentally bottoms-up. PLG, right? Like Twilio's biggest customer, or I think, one of their biggest customers for a long time was Uber. The way that Uber became an eight-figure customer for Twilio was one random developer went to the sandbox, tried it out, liked it, integrated it. They just started seeing massive traffic coming through. They're like, "What is this?" [inaudible 00:42:15] and they sent their sales team like, "Hey! We should probably do an enterprise contract with you guys." But, fundamentally the discovery motion of it was bottoms-up, and that's supposed to be the appeal of an API business. Take it off the shelf, any developer can use it and they can start to get real value from day one.

We actually have a different motion, which is that, yes, it's an API, but we're enterprise top-down. We're selling to big financial institutions, or to big fintechs, where we are talking to a decision maker, and then, we need to get them to understand the business case and the value before they're going to adopt it. Then, as a part of the assessment, you have some developer who's doing a technical assessment and that's where it comes in. 

But, there's an important distinction there, because people assume it's all the same and it's two very different growth patterns, even though the vehicle of which you use the product is the same. Because of that, it also starts to inform whether or not you're going really wide, or if you're actually going super deep, because the go-to-market motion should match the market motion that you're trying to serve.

Super interesting. You're right when you think about those famous API companies. It definitely goes that route of, “Yes, jump in.” Then, once somebody will grow on top or whatever, you can do the build in the B2B, but you're really focusing on the consumer. Then, your point being that, it's just different for each API company and there's a lot of different API companies. Finch is similar, Jeremy, correct? Where you are more on that enterprise sales cycle? Or there's also the opportunity for both, though, correct? You probably have a sandbox available that someone could jump into if they wanted to?

Jeremy Zhang:

Yes, just jumping off Kurt's point, how I think about that topic is, what is the end in terms of your customer? For Twilio and Stripe the end is relatively large and therefore, they had to go more inbound. 

For us, even for companies like Plaid, where it's still important to have the developer experience, because that is marketing, that's the most important piece of marketing, it's more sales driven because you have a limited number of enterprise customers that you need to be able to target, and it's harder to drive that ROI purely on the marketing side. That's how I think about it from a go-to-market standpoint.

But, to answer your question on a wide and deep level for unified API companies, I do agree with Sara in terms of, it just depends on how you define the market. We define our market as the employment sector. We actually think that's pretty broad. It's not just HR payroll, it's time and attendance, it's benefit administration. Our verticals are not expanding into ERPs or CRM, but we don't think of ourselves as like, "Okay. We're narrowly focused on a specific sector.” It’s more like, “We're an infrastructure for this larger industry, which is the employment sector.”

The thing that shines through a lot of these answers is that it's usually like, "Yes, but ... " Or, "Well, a little bit of both." Or, "We serve them, but we also can serve that." Then, there's the double-sided marketplace aspect. 

As a founder, how do you prioritize, because like Sara said, it's really hard to be everything to everyone. How do you think about prioritizing target customers, new product? What's driving those decisions for you all, in a situation where maybe there's a little bit of demand from a lot of people for what you're doing? You end up having to make a decision about, "This is actually most valuable to these people for these reasons, and we're going to be the best at it." Talk me through a little bit of the decision making in your internal teams around prioritization in what could be a very broad market. 

Sara Du:

We'll just do the same cycle. Yes. For us, it's generally that focus has to be on how we market ourselves and then, also the sales experiments. But, that's the issue, or a blessing and a curse with API and infrastructure companies. Someone who's not in your ICP can come to you and you can serve their use case. It's a matter of if you want to say yes or no to serving them. Usually, you want to take the money. But, you don't want to market that too heavily, if it's against the theme of that, say, quarter-a-year focus. At least for us, we think of focuses.

So with commerce, we built up this brand reputation. We spent a lot of time in those communities in person. Now we're making a concerted effort to go broader into being present at Dreamforce and more general SaaS events. With the ERP focus, we chose that because we see a huge ecosystem of SIs helping SaaS companies set up ERP integrations. It's just a huge opportunity in terms of market size for us and so, that's our line of thinking for why we want to brand ourselves ... In addition to commerce, focus on this new vertical explicitly.

Jeremy Zhang:

Yes. For us, at the highest level it is mostly resource allocation, based off of data. It's just like, “Are we spending 80% of the time on core product and 20% of the time on experimental, whether it's on the go to market side, whether it's on some new product build? Is it 70-30? Is it 60-40?” That just depends on the stage of the business. How much revenue growth do you have ahead in terms of your current product set? But we always want to spend a portion of spend in terms of exploring adjacencies, whether it's horizontal adjacencies, whether it's building solutions for use cases that's built on top of Finch, and that is how we conduct product discovery.

Kurt Lin:

Yes, we can do a very similar thing in that. The thing you have to always check with yourself is, is this aligned at the very highest level with the vision and strategy we have for the business? Because I think what often happens is, per Sara's point, you get a ton of inbounds knocking on your door. People are like, "We want to do this, can you do it?" So, it's like, “Of course we can.” Then they give you a million dollars and say, "Well, we'll pay you a million dollars." So you're like, "Wow, that's a lot of money." Then you're sitting there with your product team being like, "Should we do this? Should we not do this?" 

The first question you used to ask yourself is, “Does this get us meaningfully closer to our end vision and strategy?” If the answer to that is “No,” then even if it's really lucrative, it's just not a good use of your time because it's just going to be a distraction, right?

Then, a layer deeper there the question to ask yourself is, if you have a good strategy, then, you should have core metrics that you hold sacred that are like the North Star metrics, the thing that you really want, that if it ends up being big, then the business is going to be big. 

If you have a couple of those core metrics in their stack rate in terms of importance, then you can filter every single feature idea and product idea through that to then force yourself to stack rank from an ROI and greatest impact point of view. From there, it's much easier to then have honest conversations about this idea sounds amazing, but if you risk-adjust it towards the ROI, it's actually not going to be as impactful as this thing that seems less sexy, but probably more impactful for the business. That's how you can force yourself to make the hard tradeouts you need to make.

But to Jeremy's point, you always need to find a balance between core business and new. If you're only ever only doing core, you're going to miss the forest for the trees sometimes. All of a sudden, you wake up one day and you see that the real 100x bet that you needed to place, it's too late or you missed it, right? 

Often, it's orthogonally related to what you're doing, but it's not even actually that related to your ICP or the core business you're building, but your job is always to look for that hidden insight or earn secret that is going to be able to give you an unfair advantage in whatever you do next. And if you're not... It's everyone's job to do that. It is certainly the C.E.O.'s job to be looking for that, and I think that's just... Making sure that you don't forget that is a really big part of being a good operator.

It's such an interesting kind of business model, because I think that in a lot of ways—and something that I didn't understand before the call is—how much stuff is stacked in. My experience with Twilio or my experience with Plaid, for example, has been that they have their core product in that bank, but they've expanded outside of that and they've started to be aware of other opportunities. But when you were first building the businesses and when you first got going, was that a part of the—because it's in the VC land, it's like, well, should you be doing 10 different things, or what's the one thing that you really do? When you were first getting going with it, was the core always set, and then you were... maybe we'd build off, but you knew that this one core thing could be big, or was the initial pitch that this is a... Was it a wedge?

Was it core was wedged into all these other things, or was it core is big, and if we do this, it'll be big? In all of your situations, like Finch, for example, you mentioned there's three kind of separate products, or they're all generally in the same space. But yeah, Sara, in early days of Alloy, were you pitching Shopify and dominating that space or was there, and then slides type of off of that? How did you think about and when you were thinking about the vision in the early days?

Sara Du:

Yes. I feel like the answer to this really depends on the style of the founder. We started as young naive engineers, so we were very focused on the technology, with very little... Our pre-seed did not really talk much about verticals or go to market. It was really like what we built traction, the potential of having this orchestration layer. For us, it's been a journey of having these new vertical experiments because we built it, and now it's a matter of how do we build our brand in each new vertical we're tackling. We actually, unlike Jeremy and Kurt, didn't focus on a specific space to start with. So, even moving outside of commerce is a huge lift for us because we almost got typecast into that, even though our initial vision with the platform was to be more generalist.

Kurt Lin:

My general hypothesis on infrastructure businesses is that you need to prove a land and expand for it to be a big business, right? The example I like to use is Stripe. 

Everyone comes to Stripe for payments, but then they end up sticking around because they want checkout, or connect, or fraud, or billing, or invoicing or the 100 other value add services they add on top.

You need to do that because one of the interesting things about universal APIs is the aggregation layer, that middleware layer, if you are only ever a middleware layer, eventually if you become too big, your partners are going to try to circumvent you because you're just adding unnecessary cost, or your customers try to circumvent you because you're adding too much cost to the equation. For example, the payment rails that Stripe sits on top of, or the communication rails that Twilio sits on top of, those can be built on top of by other people.

So, if you look at Adyen vs. Stripe, you're going to compete down to zero on just the rails themselves and just payment processing if you let it go on too long. The whole point is you have to continue to add value added services or differentiating things on top of it that they come for payments, but they stay for everything else. 

For us, it's the same way. Our wedge was the direct deposit switching, and now customers are adding on more and more products to deepen that customer relationship. But you have to prove that out because of the very nature of being a middleware player. Over time, competition will just start to squeeze you. That's just the nature of being middleware.

Jeremy Zhang:

I think I'm somewhere in between Sara and Kurt where I was definitely relatively young when we first started building Finch. We are also in YC, so their whole premise is focus on customers and just try to find product market fit. 

I don't think there was a grand vision as we were trying to figure out what's going to work and what's going to land, what's going to expand. But I think over time, as things have started to work, also as I've dug myself out of deep tactical items, there's just time to think about or talk to customers about, “Okay, what else are you looking for?” 

Even thinking about the industry as a whole, to kind of form a thesis on where we want to take Finch, how the industry is going to evolve over time. But that's something, I think, I wouldn't expect a founder to be able to paint this full picture, especially at the pre seed sequence.

I want to ask the obligatory VC question of how does AI play here? How is it or how is it not a part of your business? Obviously, that's the topic of the times, a lot of acceleration there around what's available, what things can do. How are you using it? How are you not using it? Where do you see it playing a role in this middleware world that you all live in?

Sara Du:

Yes. We're most bullish on AI for code gen, so generating integrations. All of us, within our code bases, we represent integrations a certain way, whether that's standardizing a schema, or essentially AI will make it such that you can translate any of these open API docs into what's in your system so that it actually doesn't matter. Everyone will support every integration. 

That brings up an interesting question of what differentiation will look like. I think, access two that I talked about earlier—which verticals you built a brand in and service and have use cases around—that'll become more important than ever. I do think right now, the accuracy of code gen for integrations is very low. Open API specs to that whole generator process is 70 percent accurate, so, I think it'll take a bit before we get there.

Kurt Lin:

I would echo what Sara said. The main use case for us would be like, “Okay, you have a thousand integrations, but there's a long tail of another 10,000. Are you going to have higher engineers to keep doing that, or are you going to find ways to make them much more efficient?” That's where the most obvious use cases outside of other ones like customer success, etc. feature. 

The other thing that is really interesting is that for a lot of aggregation players like ourselves, we come in contact with and often store—because we're legally required to—data. At the end of the day, if you put all of the craze aside for a second, what AI really is just models have gotten exponentially more sophisticated and exponentially more powerful with the advent of powerful GPUs, but what's feeding them is the data.

The winners of the space are the ones who have proprietary data—enterprises that have massive troves of data are the most valuable companies in this next wave of AI. We see that and say our AI strategy, as simplistic as it may be, is to continue to build a data mode where we know that we have data that nobody else does, and so we can start to train models on our specific data that will then provide unique and proprietary value to our customers.

Jeremy Zhang:

Yes, I would agree with both, to be honest. Those are the two points I was going to talk about. I do think just the pure connector layer is going to get commoditized over the long term. Either it's going to become like every API is going to be an open API, or it's going to be so easy to kind of build these connectors. Unless you have some business context business partnership that prevents other competitors from entering, it's just become extremely cheap, which means that you're either building value added service or solutions on top of this product, on top of your infrastructure that you're already selling, or your infrastructure in a specific space that has access to all the data that's flowing through the sector. Plaid is a great example, here. That's how they're able to kind of build their fraud products, because they see all the bank transactions flowing through their infrastructure. So I do think, as Kurt said, data is going to be a very important part.