No Priors: Artificial Intelligence | Technology | Startups - Why Platforms Win and Point Solutions Fail with Rippling CEO Parker Conrad

Episode Date: July 10, 2025

As a three-time founder, Parker Conrad has one piece of advice for aspiring entrepreneurs—don’t do it. The Rippling co-founder and CEO joins Sarah Guo to talk about what he learned from the crash at Zenefits, why most advice to founders is wrong, and how building a real platform—not a point solution—is the only way to win in SaaS. The two get into founder psychology, the myth of learning from failure, and what true ownership looks like inside a company. He also shares why AI won’t shrink teams anytime soon, what people misunderstand about vertical software, and why ambition trumps efficiency with long-lasting companies. Sign up for new podcasts every week. Email feedback to [e-mail] Follow us on Twitter: @NoPriorsPod | @Saranormous | @parkerconrad Chapters: 00:00 Introduction to Parker Conrad 00:33 Lessons from Zenefits to Rippling 01:54 The Psychology of Founding a Company 07:56 Rippling's Ambitious Vision 10:41 Building a Platform Company 15:05 Challenges and Strategies in Scaling 30:36 AI's Impact on Software Development 42:06 Public vs. Private: Rippling's Future 44:19 Conclusion 

Hi, listeners. Welcome back to No Pryors. Today I'm here with Parker Conrad, co-founder and CEO of Rippling. Parker needs no introduction as one of the most admired founders in Silicon Valley. We'll talk about his founder redemption arc, why the conventional wisdom is wrong and the biggest companies are actually platform companies, the future of the SaaS industry in the age of AI, leading teams of the ownership, how he thinks about going public, and why you should only start a company if you have no other options. Welcome, Parker. Thanks so much for doing this. Yeah, thanks for having me. I think there's a very apt phrase that's the best revenge is massive success. What do you think you got wrong at Zenefits that you've done differently at Rippling?

You know, in some sense, there are kind of some superficial things. But I think like mostly like Xenifetz failed for like dumb reasons. And so I, you know, I don't think there were like a ton of lessons. I mean, you know, there are obviously there were sort of some of the specific. things that kind of, you know, let it to not work, that, you know, you want to make sure not to repeat. I mean, we're, like, we try to be, like, really extremely, extremely careful about compliance at Ripley and regulatory compliance in particular. And then I think at Zenefits, we, we probably leaned way too much on, on ops. And I think, like, Ripling has, as a result of that, you know, maybe just like a deep aversion to, to that. And maybe actually to our detriment in some

cases, you know, where we perhaps should be willing to, you know, do things that don't scale a little more. But we tend to go just really deep with software at, you know, and sort of not take on sort of like operational, you know, builds and overhead. So those are, those are probably like the biggest differences. I think there are probably some other things that like I took away from the experience. But they're much more general. I mean, like, I think, you know, for a long time early on at at rippling like you know i i felt like it was just much easier to manage like my own sort of psychology on this stuff i mean it's it's just really hard i always found it personally maybe i was just sort of not cut out for this but always found it personally like very hard to sort

of deal with kind of the psychology of running a company like the big ups and downs and um you know at rippling it was it was a lot easier because no matter how bad things got i sort of always had this thing where I'm like, oh, man, this like just pales in comparison to how bad things were, you know, right at the end and just after I left at Zenefits when things got like really very dark. And so there's this sort of like idea in Silicon Valley that you should learn a lot from failures. And I, I'm not sure that I agree a lot with. I think that actually people probably learn a lot more from their successes. And, you know, companies fail for like many dumb reasons.

And like it's really hard to sort of take a lot of lessons away from that. And actually, you probably learn a lot more by being at a company that's working and seeing, like, how it works. I remember talking to you during that period and when you were just starting the company. And I think you said something to me like starting a company sucks, especially when you were, you know, not in Silicon Valley and, you know, the social sphere is good graces at the time. You were sort of fighting a big reputational battle. You described it as like, well, you're just like sitting in your parents basement again and like nobody believes in what you're doing. that sucks. What made you do it anyway and start over? I felt like I didn't have a lot of choices, to be honest. You weren't going to work at Google? I mean, I didn't have an offer. You know,

like, I think I was personally, like probably pretty radioactive. And I think it would have been hard for me to get a job. I've started three companies. And I think the first company I started because I was naive and didn't know what I was getting into. And the second company I started because I sort of looked around and I'd been at the first company for like seven or eight years and kind of it was sort of worthless from a resume perspective and was sort of like totally unqualified for, you know, any job that wasn't sort of like entry level other than like maybe starting another company. And so I felt like, oh, crap, like this is, I guess I'm doing this again. And then the third time around, it really felt like, you know, this was kind of,

there weren't really a lot of other options. And also this was kind of like the one path that that I sort of saw that maybe there was this sort of narrow ray of light when when sort of it felt like I was being buried reputationally that like, okay, if I if I could like build this specific company and make it really successful, you know, maybe there was some future world where, you know, there would be like a different story or a different narrative or, you know, a chance to kind of like. you know, sort of tell my side of the story on it. So in learning from, you know, the success and as far as Rippling's scale today, what have you learned about founder psychology for yourself beyond perhaps, well, you could go through like a really bad crucible and just assume it's not going to get that bad again? I mean, I generally, sometimes people come to me and, you know, say, I think, I think, I think, like, do I have any advice?

Like, what do I think about? And my advice is pretty much always, like, don't do it. And it's because there are a number of reasons. that like you're you're your your most people are likely to fail um and i think that failure gets glamorized inappropriately um or just incorrectly maybe um that you know you don't actually usually take away a lot from failure and it's extremely destructive it's destructive it's destructive to your your psychology it's destructive to your marriage to your relationships you know it's like it's really hard and so like there there are a lot of costs

to doing this that I think are generally in most cases, like, not worth it. And that's like why I tell people they probably shouldn't do it. Nobody ever follows that advice, of course. You know, if anything, it's sort of like redoubles everyone's resolve. But, but I do think that that's the case. And so I don't, I don't have an answer for why, for this sort of psychology piece. I think there are some people that are just like better at it than than like I have been in my career. I think of you as one of the nicest angry people I know. but I remember I saw you it was maybe a year back and you told me that you were hopefully this is okay to say you told me you were worried you weren't angry enough anymore

to make Rippling as successful as it should be and I just burst out like fucking laughing and said like well like my friend don't worry about this no one else is worried um do you think being angry is important I don't know if being angry is important but I think that there were at least in the early on it for the first couple years of Rippling um this sort of like um for me personally um this sort of idea that this was like the only way and this was the only thing and like this the sort of focus of that um you know it was the first thing i thought about every morning when i got out of bed and it was the last thing that i thought about when i went to sleep and it was the thing that got me up in the middle of the night you know

and and i i think that that was extremely motivating like not maybe not like super healthy it sort of got me through a bunch of like difficult years and a bunch of a bunch of sort of grind because it is a grind for a number of years. And I think like since then, um, I don't remember this conversation by the way, but I think, you know, since then, like there are a lot of other like motivations, you know, that are that are there. Like I really love the product that we're building. I really like the people, um, that I work with. So there's a lot that I enjoy about work. There are a lot of other sort of like positive motivations. But yeah, you know, the nature of like some of that other stuff is it starts to kind of fade over time.

You know, that's just the reality. You have the ambition of Rippling changed over time. It was always like a wildly ambitious company. You're like, oh, well, don't worry. We're going to take HR and IT and identity and, you know, do all of it all at once from the beginning. And I remember talking to one of your early engineers in the first, I don't know if it was like the first real office or the first office, but he was just like, yeah, this is like, we're going to do Salesforce. And I'm like, Salesforce took a long time to get there. And he's like, we're going to do it all now.

Do you, I try to remember who this was. Do you feel like the ambition is the same or is changing ambition part of that? We've probably gotten better at articulating, like, sort of how we think about it. And so it started out with just this, like, this belief that like actually, all of this, these ideas that people had that the way to build great products were to, like, focus, you know, really narrowly, was wrong. And that actually the right path was to try and build, like, a coherent product suite of seamlessly integrated and interoperable applications. At first, it was just like, no, no, no, we're going to do, like, HR, and IT,

and there are these other things on the roadmap, like, you know, sort of finance and stuff like that. And I think over time, we probably got like a little bit better at articulating sort of why that, why that was. And I think the best way to express it is that I think that what people get wrong about software is historically, we've been building software in this way where if you focus really, really narrowly on a very specific domain or application area. And people think that you can sort of craft these artisanal products and experiences that way. the problem that you run into is that ultimately companies end up having a lot of different applications and that creates a lot of problems for them. But also these artisanal software companies really can't afford to invest in a set of underlying capabilities that are ultimately what make these applications powerful for their customers. And that end up being repeated across a lot of

these different application areas. So things like permissions and reports and analytics and workflow automations and approvals. And like, there's a set of underlying capabilities in business software that end up being repeated and relatively conserved across this just broad array of domains. And if you're building a lot of applications, you can afford to invest much more deeply in those areas and make what are ultimately much better experiences for customers because of that. And you simply can't afford to make that R&D lift.

if you're building just one thing. And that's also like if you sort of look back, like this isn't, it's not really a new idea. It's sort of an old idea that, that's come again, which is that you, you know,

this is the way, you know, Oracle and SAP and Salesforce and Microsoft were built, was that sort of idea of like building, you know, what they would call platform, you know, that this underlying set of capabilities that you then, you know,

use in sort of assembling all these different applications. And that kind of articulation came later, but I think the sort of the fundamental idea was like the company was deeply committed to building software or religiously committed to building software in this way, like right from day one. So that's not been, as you mentioned, like the conventional wisdom in building software startups for maybe a decade and a half now. Why do you think people miss that? Because as you say, like some of the biggest software companies for time and I'd add like epic to that list, right? some of the biggest and most powerful company is like the reason they are so powerful is because they work in an integrated way and they have a lot to sell their customers. But I have a hypothesis. I was wondering if you do. I think it's because of like the platform shift from like on

prim to cloud created a bunch of opportunities for like a bunch of kind of like base hits, you know, with SaaS where you can sort of peel off like one one sort of application area from the sort of big on-prem providers that, you know, just took a long time to move to the cloud and get that really stood up. And you could, you could very easily actually get a lot of traction with something that was extremely narrow. And that was like good enough for a period of time. And I think what happens is over time, the bar goes up in terms of what you need to be able to do for clients. And it's like no longer enough to have like, you know, a standalone SaaS application. You start needing these other capabilities or these deeper capabilities, and that sort of forces things

like back together. And I think like that's, you know, sort of, you know, where we're going right now. It'll be interesting to see, you know, with AI, like how AI, because some people would argue, like, well, AI is sort of like a similar kind of shift from like on prem to cloud. And I probably don't agree. I think it's actually probably more centralizing as a technology. But that, you know, that's that's kind of my view. on sort of what triggered that, at least for a period of time. I think that's right. I also think that there, I mean, you know, the latter half of the SaaS revolution has

coincided with like a massive bull market, right? Through like the 22 period, right? And I think that if you had internet distribution of software to like mid-market companies that could buy online and rapidly, then a rippling might be the exception to this. But selling point solutions was a faster thing than getting people to shift core systems. And you could start selling with much less product. I think you guys worked on rippling for a while with a lot of people before you really had something to sell. And so I think it's also part of the investing cycle of like how quickly people expected progress from the investing community.

I think that's some of that is like the nature of like the sort of bar raising where I think there was a period of time where, you know, yeah, if there was. no sort of SaaS application for, I don't know, whatever, like, time tracking or expense management or something like that. Yeah. You could build a standalone thing for that. And it would get, like, very rapid uptake. But as soon as you start to get the sort of bigger core systems that now just that comes standard in a SaaS, you know, this SaaS way and, you know, in the cloud, not on-prem software,

suddenly it's like, that's not good enough anymore. And so there's like the window of opportunity. that kind of closes over time, but eventually you need to find sort of new islands of product market fit that are a little bit further out and sort of maybe over the edge of the horizon. And I think that tends to be sort of something that solves a bigger and broader class of problem for customers that usually requires you to take on a lot more in order to solve problems that are often about sort of like internal business process coordination that that do cut across a lot of these different applications.

And it's a lot less work for customers ultimately to be using one thing. How do you, I'm sure this has changed over time, but given platform and broad application surface area, like how do you organize at Rippling, given you don't have like contemporary, many contemporary companies with a similar strategy? And you can't be like, I'm going to do what Microsoft does at this scale. I mean, I think we try and, I mean, we have, we have teams that build capabilities. you know, that are kind of the platform teams. And then we have application teams that are building, you know,

sort of hopefully out of the underlying platform capabilities applications. And I think it's like, it's really important to have like the right leader for these application teams. Like former founders are great. But also you need people that can like scale over time as, as the product grows. And so, you know, ideally in an ideal world, you want someone with just like real ownership. of those areas who can drive it because otherwise, you get this, um, you get this sort of bottleneck at the level of executive attention where, you know, if I have to drive it, it's just like,

I can't do that. I can only do that for so many things. And then inevitably a lot of balls get dropped. And so you need people like in seat who can like really own it and run like the business holistically, who can think about the product roadmap, the marketing, um, you know, the sales elements, you know, the competition. You like the whole thing and kind of, you know, and synthesize it down to like, okay, here's what we're going to do. And that's always sort of the most challenging thing is to find those people. I mean, we try and hire a lot of founders at Ripley to make it work. But that's always ultimately the bottleneck.

I don't know a single founder who doesn't feel like they could use more owners at their own company. Like, do you have any advice on how you filter for this? No, in terms of filtering, I think it's hard. Like people who have had that experience before, I think it's, sometimes it just, you know, having a conversation with someone, you know, are they kind of naturally, you know, jumping to, you know, sort of conclusions and implications about the business and kind of getting there on their own or, you know, how much do you kind of need to lead them there? It's hard. I think the difference is like it sort of comes out in, in like planning, in like quarterly planning. Like some people show up to quarterly planning and there's like, there's a list of things that they're like, here are the things that we kind of need to get done from a. product perspective and the list inevitably sort of like, you know, that you unfurl it and it kind of goes like down the hallway. And some people are like, okay, well, you know, we're going to do about one quarter's worth of work. We've prioritized the list and one quarter's worth of work is like

this much of the list and that's what we're going to get done. That's my job. And the problem is it's like now it's like my job to kind of make the ends meet because like that part, that's not going to cut it. You know, it doesn't, you know, we actually have to get a lot more done to make things work. And so now it's, it's sort of my job to figure out, like, how do we sort of bridge this gap? And what you really want is you want people who are going to find a, find a way, sometimes through seemingly impossible constraints where they're like, this is, the reality is like, it's not, it's not like the CEO of the company who's like giving me this impossible task.

Like, the problem is like, this is fundamentally the situation that we're in. Like, this is the market reality. You know, we're here. We need to be here. We can't win unless we get there. And it's a lot of that is like, you know, it's what you see at a startup because you're sort of doing a startup is somewhere between completely impossible and very, very hard. And there's this just kind of very slim sort of like window between those two to make it out. And, you know, companies often have to find early on ways to do seemingly impossible things. And you need someone in these roles who's going to like find a way to make it work. So there's the innate. There's like finding people with that mentality and ability and, you know, recruiting them. And then there's like trying to get people to act more like this, which I'm sure you do. I know that you do across Ripling. When I was looking at the, I think it was the series A, I called 20 some people that used to work for you. And one of the things that was like most universally loved was like I would follow Parker to the ends of the earth because he got more out of me than like I knew how to give in terms of. of my own capability and I got more done.

What advice would you have for founders on making that happen? It's an amazing skill. I'm not sure I'm great at and that's wonderful that you've played, you've sort of couched it. I didn't say it. There are probably other people that are like fucking asshole, like, you know, just drives everything way too hard. Totally unreasonable. Yeah.

Totally unreasonable. So I have like two thoughts on this. One is I, you know, I genuinely believe that people are usually capable of so much more than they believe themselves to be capable of. People sort of grumble about the kind of the work culture in Silicon Valley being sort of about this sort of grind kind of culture. And I think what that what that misses is it's not, I think it's important to understand like it's not that I'm like, why isn't everyone in the office like seven days a week or something like that? It's like, it's like, look, this is the situation that we're in and it sucks. And like the reality is like this is, you know, we need to kind of find a way to bridge this gap.

and I can kind of lay out the gap. And it's not, but, you know, I didn't create the gap. You didn't, maybe you didn't create the gap either. It's just, but it's like, it's there and we can either give up and go home or we can like try and find a way. And sometimes when you kind of lay it out for people, they can really accomplish incredible things. Like Patrick Collison has this great site that talks about these different organizations and how, how, like,

you know, teams of people that like, you know, did the moon landing in four years. or like the sort of Van Ness Bus Lane in San Francisco at like 12 or whatever it was. And like just the discrepancy between how some organizations are able to do so much in such a small amount of time and some organizations are not. And so I think the difference between like working really hard, you know, some people think it's like, well, if I sort of kill myself, it's like an extra 20%. And actually like the difference between teams that can really accomplish a lot, it's not like 20% on the margins. It ends up being like an order of magnitude in terms of what you can do.

And so I think you've really got to like ask for that and ask for people to try and find that within themselves. Like one very concrete example of this is I, a lot of times sort of I get people like to come to CEOs with with what I call like CEO in the box options where they say, look, you can have A or you can have B. Like which one is it going to be? You tell us like what the priority is. And it's this sort of illusion of choice where, you know, the important decision has already been made because the important decision is like, you know, A or B versus like, you know, A and B. And so reflexively, I try whenever I get choices like that to sort of reject the premise and be like, I want A and B. Like, why can A and B not coexist? Does it violate like the second law

of thermodynamics? Like what? And some, you know, one way of looking at that is like, oh my God, this guy like asking for something impossible, but sometimes it's really just about the solution is to just, you know, think a little more deeply about the problem. And like, you know, is there some third path? Is there, you know, like what, you know, what's the sort of creative approach? Because often there is a real cost to making those tradeoffs that if you can find a way around it, you know, it can mean the difference between success and failure. Yeah. One thing that's striking to me is there are a lot of very talented people at Ripling. But I think most people be like, well, they're not all Parker Conrad, except that you are treating them like they should be,

right? Like you're saying, like, but I think you can figure this out. I tend to expect a lot of people, but, you know, in reaction, I think I like see people do amazing things. And I wonder if like more founders shouldn't try actually to like have real belief that their people can figure more out and we'll get a lot more from that you know for me it it comes from like you know some like like sort of deep reservoirs of like panic and insecurity about you know sort of like the company and sort of the looming you know there's sort of looming failure constantly when you're building a business and so the way to i think channel that productively is is to sort of really push it down into the organ sort of lay out for people you know here are here is the situation you know when you're

when you're facing sort of like tough situations and, you know, see if you can't get people bought in to like, oh, man, like this is like, okay, we've got to, we've got to bridge the gap between point A and point B versus like, you know, I've got to like do this like task for the next month or the next quarter. You know, it's like it sort of you can get people to take more responsibility for, you know, where you need to get to. I guess I would just posit that many leaders, they don't necessarily push that problem down into the organization because they don't really believe other people can solve it, right? And I think if they do, I think they'll get more back. You have capabilities teams and then you have these application teams. Like, what is the cadence of communication and coordination there across such a big product surface? You know, I think that's that's an area that like candidly, like we always, we don't always get that right. I think there's there's constant, you know, anyone that's like trying to build in this way, there's constant tension. between, you know, people building at the application layer and people building at the platform

layer because you get, you know, the interface there is not always clean. And, you know, you get an application team and they don't want to build on the platform team stuff. And like, you know, they need something slightly different. And so a lot of, I think, the really kind of meaty product decisions end up being around that kind of stuff. Like when, you know, when do you allow teams to disconnect from the underlying systems? When do you reprioritize the platform team? to build the stuff that they need. You know, when do people have to sort of, you know, eventually migrate back onto like the core underlying platform capabilities?

Yeah, I don't know that there's like a good, that there are good rules of fun about this because it's one of these problems where locally people would almost always like prefer to disconnect. Like it's easier for them just like build their own thing. But ultimately, in long term, you know, it's the worst thing for the business and even the worst thing for their application because like you lose. the benefit of shared investment in the underlying capabilities if you do this. Like, you know, as the underlying systems get better and better because you're continuing

to, you know, every, every like dollar of R&D that I spend on the underlying stuff, it pays off 35x because it, you know, it hits, you know, every system in Ripley and that gets like a little bit better because of the new capabilities I built in the underlying systems. And that's the dynamic or that's, that's really the underlying math that I think makes this approach to building software work better than building sort of, you know, narrow focused point solutions. And so you got to, you got to hold on to that, which means that you've got to ultimately build on the Lego blocks that you have. It's very interesting to me. I was talking to Olivier, the co-founder CEO of Datadog, which I think is one of the other true

platform companies of this era. And they bought a company that I was on the board of in a new space and then made them rewrite it over the first, like, year and a half onto their platform, which I don't think I'm, like, exposing any secrets to say was a painful process. And yet, like, exiting that, all of the people from the acquired company screen were, like, we believe, right? Like, you know, there's, there's religiosity in that. It's very interesting to me that if you look at companies from that at least got to scale in the last era that are still very dominant, like, workday, people tend to make fun

of these companies that have the, like, you know, we have our internal language, we have a bunch of development frameworks, we have a bunch of components, we have a platform team, we have applications as very insular. And yet, like, this is how some of the most dominant platforms are built. I mean, Workday obviously, one in, you know, in the ACM industry, but also, like, I think there's a lot, you know, a lot of the thinking around this, like, comes from, like, Microsoft, you know, like, you know, it's certainly the way they think about the world. So I think there are a lot of you know, sort of big and even kind of like multi-category companies that sort of think about the world in that way.

Rippling, I mean, we've been talking about a bunch of principles that are very specific to Rippling doing its own thing versus listening to conventional wisdom. How much do you think about beating incumbents in HCM or payroll or identity or whatever it is versus capturing Greenfield and, like, your strategy internally? The two things are related. Like a lot of the time, you know, We can beat incumbents because of the sort of, we've sort of pushed the envelope a little bit into new horizons. And so that allows us to solve problems for customers that incumbents can't solve.

And even like sometimes like it's like not always clear to me internally, like what the difference is for customers between like new applications versus existing, you know, and like new features versus bug fixes. Like a lot of times like whether we categorize. something as like a fix or like a new thing is about whether we internally believed that this capability was part of like the original spec. But from the customer's perspective, it's always just like, I wish it did this thing and it doesn't do it. Um, you know, so to them like everything's a bug. We're building a variable compensation product right now. And like in some sense, it's a new thing. It's a new application, new skew. But it also like, you know, really helps, um, you know, if you're, if you're an existing customer,

it's an existing problem that you have. You just wanted Rippling to do this. Yeah, you're kind of like, oh, yeah, like this makes like payroll easier because I have people, whether it's like salespeople or like other people that are on simpler kind of, you know, variable compensation structures. A lot of businesses end up having, you know, bonuses, commissions, you know, things like that that you are just kind of tough to manage that if you did it in one place, it would be a lot easier. But to answer your question, I think more directly, you know, if you look at the

headcount of the org, like over 80% of the engineering headcount is really focused on the existing stuff. Very little headcount is focused on building the new things. Like, most of it is just in continuing to develop and sort of extend all of the existing applications and the underlying platform of the system. And some of, I think, why that is is like you need fewer people when you're building something new and you don't you don't have any existing customers yet and you get to build on a lot of these underlying applications like you can make it very far with a very small team and so the you know we always kind of have like you know four or five like new things in the works but collectively the teams that are building those are it's it's not that

large it's you know it might be you know five to seven engineers on each one you know out of an engineering org that's now, you know, I don't know, over 1,000 people. I'm going to use this as a chance to talk about AI, because we're not going to get away without that, but we'll start with engineering, approximately 1,000-person engineering team, right? Do you believe in the premise of, like, do a lot more with many fewer people over the next two years in engineering? I, like, am very skeptical that AI will be employment conserving because I just think that like in basically every area like we have not seen and I think most large engineering orgs have not seen like a huge number of efficiencies from these sort of

like the sort of coding assistants that you know they're they're very popular with the engineering team there are clearly some ways that they you know that they help but it's not like we're like oh man we need like so many fewer people yeah to kind of do this and and I think that I mean, that could be that we're just like not very good at using them, but like in talking to like a number of other kind of late stage companies, I think that that's been true for most of the organizations that I've spoken with. I don't I don't know like quite why that is and maybe it will come. But even then, I think like if you make it easier to build software, I think the demand for software will actually go way up. And and I think by the way, I actually think the same like I believe the same thing is going to be true for customer support. I think as you, which is the other major area of product market fit here, that, you know, as you make it easier for customers to access something that feels like support, where the experience is really good and it's instantaneous and it's not, you know, it's not frustrating because like, you know, it takes a while to communicate something and there's a lot of back and forth and maybe the person doesn't know, you know, what you're asking exactly.

I think people will use more of that, not less. You know, even as like ticket deflection rates go up, you know, we see like at least internally at Riplane, like, you know, a lot more use of like our sort of like AI enabled support tools where it's clear that people have just found that like, hey, actually, it's like this is an easy way to sort of get things done quickly in the product. And so they start, they start using it a lot more. And like on the engineering side, like one sort of theory I have is that I think that as, you know, if and when it gets to a point where it's just much, much easier to build software because you know, like engineering engineers are so much more productive. I think what will happen is rather

than needing like way fewer engineers, what's going to happen is a lot of these like core software systems are going to end up getting like highly verticalized. You know, like you're going to end up having rippling for ophthalmology clinics where there's going to be a lot of specific capabilities of the system like just for like ophthalmology clinics. And that's going to be possible because, you know, it's like a lot easier to build an application. much more quickly because the cost has come down and unlike sort of people that are building like independent vertical software like if you're a company that's actually building like hey we're rippling for ophthalmology clinics the challenges i think it's like it's really hard to have all

of the underlying platform capabilities that you need in that system and so you know some of the challenges with vertical software historically have been that you have this choice between like heavily customized for the industry but missing a lot of of like core underlying capabilities. And so if you're as a company that needs something like, you know, serious, you eventually need to go to like, you need to move to Salesforce or something from like the thing that's like very industry focused. And I think what will happen is that like actually as the cost of software building applications comes down, it will let the sort of core companies build a lot of like industry specific vertical applications. And so this is just kind

of a long way maybe maybe of sort of giving an example of like why. I think that, like, look, if you and your small team can, like, vibe code an application that gets a lot of distribution very quickly, so can a lot of other people. And so inevitably what's going to happen is, like, the bar will go up and, like, what customers expect. And it might not happen immediately, right? Like, you might get, you might be able to get for some moment of time a lot of distribution very quickly.

But eventually, they're going to be competitive. And the expectations are going to go up. The pricing is going to come down. You know, you're going to need to, like, the frontier is going to move out. And you're going to need to be there. And that's going to take people. It's going to require more engineers, more investment, you know, at the sort of bleeding edge of whatever's possible. And the same thing I think will be true on the go-to-market side, that, you know, it will become harder to make progress through the market. And you're going to need to have teams of people that can, like, interface with the world. that can talk to customers, can talk to decision makers. And, like, yes, those people, maybe they're more productive because, like, some of those interactions are, you know, handled or enabled by AI, but you're still going to be competing against a set of businesses that also have all of those efficiencies. And it's going to be as a result of that, like, that much harder to cut through the noise. And so there's always going to be this sort of, like, leading, there's going to be this frontier that

you're going to need to play out. and that's usually going to require investment and headcount. I think I see the race the same way. And then for some set, you know, there's going to be some set of industries that have, like, different enough workflows, maybe not around people, but around go to market. Like, pharma's the classic example, right? If you're designing around a regulatory regime, like, maybe that is different from Salesforce enough. I think there's one version of, like, more verticalized companies that, like, you know,

they ship something that won't work for customers forever. And then they're investing backwards in capabilities. and in a race against companies that are more horizontal. I think the other version, and now I'm talking my own book because I think we have portfolio companies that are doing well in this direction is they don't really look at themselves as much as software companies in the traditional category sense. They look at themselves as doing more work that people used to have done. The horizontal players will clearly see this too, but the specialization may be useful

in some verticals. Yeah, that makes sense. I want to go back to something you said at the very beginning about being allergic to ops because of Xenafits or, you know, from that experience. I'm sure you've heard about a bunch of these ideas of, well, you know, we believe we're going to need humans doing distribution. They own the distribution. These verticals are not adopting AI technology as quickly as they logically should. we're impatient for that as technology people, let's go buy distribution and roll services companies up or whoever has access to the customer. What is your perspective on that given

those are like operationally intensive businesses? I'm not sure that like we fundamentally disagree because it sounds like they're also saying, hey, we don't want to be in the ops business. Like we want to be in. So it's about replacing the ops with software. I think it's hard to replace ops with software, or at least I found it difficult. You know, maybe AI changes everything. But like, you know, at Zenefits, we kind of had this, this theory that was ultimately, I think, part of like the downfall of the company that, you know, we could move through the market more quickly by doing a lot of things manually. And then, you know, we would just replace it with software over time. And like, it sort of turned out that was actually very hard to replace

ops with software, like after you'd scaled it up. Like, it's a lot easier to start small with automation and gradually grow over time, even hopefully grow. quickly, but like the point is, is like you, you sort of start with sort of a simpler set, you know, you start with a small set of customers. I don't really think that there are like customers with simple needs. I think all customers have sort of like ultimately have a bunch of, you know, edge cases and long tail things that they, that they require. But just a smaller set of customers is easier to deal with than a larger set of customers. And if you start with that, I think you can gradually expand the capabilities over time. And if you start with like, like a really

large group. It's like hard to even capture the requirements, like the superset of all of the requirements that you need the system to do. That was like sort of the problem that we found is like we thought we were going to automate everything. And then the automation was just much harder and it was constantly delayed. And so we were in this situation where the automation was constantly coming, but like never there. And that caused a lot of issues. So, you know, I don't know if people will be more successful at that with AI. But I think it's really probably important to understand if you're in an area where things have to be deterministically correct or not.

And that's obviously the place where it gets like harder to do that reliably with AI, particularly when you have just like a really large complex space of edge cases and long tail scenarios and things like that that need to like definitely work correctly every time, which is sort of like the space that we're in. If your payroll's like not correct, you're super pissed. And like, you know, and so you kind of need like there are deterministic rules about how this needs to work. And so you need to just make sure that that rules engine is like programmed in. And it, it can't be, you know, sort of entropy of some of these AI systems. Rippling is one of my favorite examples of like software companies that I think are very durable to everything that's happening with

AI, does it change anything about your strategy fundamentally? It definitely makes us a lot more focused on data, like a lot of other companies, obviously, and capabilities around data. What I think is going to be very durable with AI is like everything that I've seen is like building the applications is like, I mean, I don't want to say it's like, obviously everything's hard, but what's much harder than building AI applications are building, you know, governance and permissions and data pipelines and things like that. And so, you know, that those are the areas like, you know, that we spend a lot of time on

because they tend to be like our core strengths, particularly because like permissions and governance are very tied to an understanding of the work, you know, understanding, you know, usually permissions are about job and role and function and or chart relationships. And so if you understand that deeply, you can be opinionated. about who should have access to what, you know, who can do what in the system. And ultimately, I think, like, all of these AI agents are going to need to inherit the permissions of a person. Like, some people would say, well, you know, maybe it can be like a service account that has distinct permissions. And the problem then is, like, well, ultimately, like, people are going to be

interfacing with it. And if it has different permissions than they do, there's just this leakage problem. And so I think you always need to ensure that the agent inherits the permissions of the person that it's, like, working with directly. And then when you do that, you need to understand, okay, what permissions does this person have across all these systems? And you start getting into, like, identity and job function and governance and things like that that that tend to be, I think, like, some of our, like, strengths from a platform perspective. A last question for you. Rippling is already at, you know, public company scale. But at the same time, you know, companies are staying private for much longer.

How do you think about this choice? I don't have any religion about it. And I'm not sure that, like, I am like the world's expert on it. It, you know, it seems like, you know, historically one of the big advantages of being public is liquidity. And what's happened over the last couple years is obviously there's just a lot more liquidity in the private markets, you know, whether it's for employees or early investors. And so, you know, if you can if you can do that in the private markets, you know, there's a lot of upside to stay in private. I mean, certainly. I think you look at like Databricks versus Snowflake, and it seems like Data Bricks has had some advantages by not being public, you know, in that fight. And then you also have this dynamic in the public markets where the public markets have kind of become something of like a retirement community for, you know, very slow growth, but very profitable companies. You know, just everything is sort of structured around that. You know, like when research analysts are talking about like high growth versus low growth public companies, is they're like, are you growing more than 20%, you know,

because it's not more than 30 anymore because it doesn't exist in the public markets. And so, you know, if you're a company that is growing a lot more quickly than that, there just aren't comps in the public markets. And so there, I think there's actually a lot of risk as a result of that because, you know, there aren't, there aren't clear comps on like what the multiples will be, what the valuation is going to be. That could change, though. I mean, like, you know, we could look at this in a couple years, and suddenly, you know, it's very clear the public markets, like, do value fast-growing companies, like, more than slow-growing ones. And you also may have, like, you know, maybe there isn't as much capital in the private markets anymore.

And suddenly, like, oh, you know, the entire kind of calculus changes on this. So, you know, like we've decided to be private for now. But that doesn't mean, you know, forever. So, you know, you kind of get to make that choice again every year. But obviously, if you go public, you know, that's a, you know, it's hard to undo. Awesome. Thanks so much, Parker. This is great. Cool. Thanks, Sarah. Find us on Twitter at No Pryorspod. Subscribe to our YouTube channel.

If you want to see our faces, follow the show on Apple Podcasts, Spotify, or wherever you listen. That way you get a new episode every week. And sign up for emails or find transcripts for every episode at no dash priors.com. Thank you.