$1 of R&D, 35x the return: why Parker Conrad says platforms beat point solutions

Sarah Guo opens No Priors by calling Parker Conrad one of the most admired founders in Silicon Valley, then reaches for an old line: the best revenge is massive success. Conrad is the co-founder and CEO of Rippling, and the arc Guo wants to talk about runs through Zenefits, the HR company that crashed after he left. He does not romanticize that crash. Asked what he got wrong there that he has done differently at Rippling, he says the company mostly failed for dumb reasons, so there were not a ton of deep lessons—just a few specific mistakes he is determined not to repeat.

The judgment he wants to leave in the room is larger than a redemption story. For a decade and a half, software startups were told to focus narrowly, craft an artisan product in one domain, and win on polish. Conrad thinks that consensus is wrong. Companies end up with dozens of applications that do not share data, permissions, or workflows. The products that last, he argues, are platforms: a coherent suite of interoperable applications sitting on a shared set of underlying capabilities. That is the bet Rippling has been religiously committed to from day one.

The specific mistakes at Zenefits still matter. Rippling is extremely careful about regulatory compliance, and Conrad says the earlier company leaned far too hard on operations. Rippling’s allergy to ops is now so strong that he wonders whether it hurts them: they perhaps should be more willing to do things that do not scale, but they tend to go deep with software instead of taking on operational overhead. The theory that you could move through the market with manual work and replace it with software later, he later explains, was part of Zenefits’ downfall. The automation was constantly coming and never there.

Silicon Valley likes to say you should learn a lot from failure. Conrad is not sure he agrees. Companies fail for many dumb reasons, and it is hard to extract durable lessons from a wreck. You probably learn more, he says, by being at a company that is working and watching how it works. Early Rippling was psychologically easier for him in one grim sense: no matter how bad a week got, it paled next to how dark things were at the end of Zenefits and just after he left.

Guo reminds him that he once described starting over as sitting in his parents’ basement again, outside Silicon Valley’s good graces. He felt he did not have many choices. He was “probably pretty radioactive” and did not have a job offer. He has started three companies: the first because he was naive, the second because seven or eight years at the first left him unqualified for anything that was not entry-level, and the third because there really were not other options. Building this specific company, and making it succeed, was the narrow ray of light he could see while being buried reputationally—a chance, someday, to tell a different story.

His advice to people who ask about starting a company is almost always: don’t do it. Most people are likely to fail, failure gets glamorized incorrectly, and the costs are not worth it. Failure is destructive to your psychology, your marriage, and your relationships. Nobody follows that advice; if anything, it redoubles their resolve. For the first couple of years at Rippling, the company was the first thing he thought about in the morning, the last thing at night, and the thing that woke him in the middle of the night. Guo recalls him worrying, a year earlier, that he was not angry enough anymore. He does not remember that conversation, but he does say the all-consuming focus faded, replaced by something healthier: he really loves the product, and he really likes the people he works with.

Rippling’s ambition has always been large. Guo remembers an early engineer saying they were going to do Salesforce, all of it, now. Conrad says they have mainly gotten better at articulating why. The original belief was that focusing narrowly was the wrong way to build great products, and that the right path was a coherent suite of seamlessly integrated applications. At first that meant HR, IT, and identity, with finance on the roadmap. The clearer version came later: what people get wrong about software is the idea that a tight domain lets you craft artisan experiences. Companies then drown in applications, and those artisan vendors cannot afford the underlying capabilities that actually make the applications powerful.

Those capabilities are conserved across domains: permissions, reports, analytics, workflow automations, approvals. If you are building many applications, you can invest much more deeply in them and deliver better experiences. If you are building just one thing, you cannot afford the R&D lift. The idea is not new. Oracle, SAP, Salesforce, and Microsoft were built that way—what they called a platform, an underlying set of capabilities used to assemble applications. Guo adds Epic in healthcare to the list. Rippling, Conrad says, was religiously committed to building software this way from day one.

So why did a decade and a half of startups miss it? Conrad’s hypothesis is the on-prem-to-cloud shift. Incumbents were slow to move, which created a string of “base hits”: you could peel off one application area, ship something extremely narrow, and get a lot of traction because it was good enough for a while. Over time the bar goes up. A standalone SaaS app is no longer enough; customers need deeper capabilities, and that forces things back together. He does not think AI is a similar unbundling shift. If anything, he sees it as more centralizing.

Elad Gil adds a capital-markets layer. The latter half of the SaaS revolution coincided with a massive bull market through 2022. Selling point solutions to mid-market companies that could buy online was faster than getting people to rip out core systems, and you could start selling with much less product. Investors also expected to see progress quickly. Conrad agrees the window closes. Once bigger core systems exist as cloud SaaS, a standalone time-tracking or expense tool is not good enough. You have to find new islands of product-market fit further out, usually problems of internal business-process coordination that cut across applications. It is a lot less work for customers to be using one thing.

Rippling organizes around platform teams that build capabilities and application teams that assemble products on top of them. The scarce resource is the right leader for an application team. Former founders are great; so are people who can scale as the product grows. Ideally you want someone with real ownership who can think about the roadmap, marketing, sales, and competition, then synthesize a decision. Otherwise you get a bottleneck at executive attention. If Conrad has to drive it, he can only do that for so many things, and balls get dropped. Hiring founders is how they try to make it work, and it is always the bottleneck.

Filtering for that mentality is hard. It shows up in conversation—whether someone jumps to business implications on their own—and it shows up in quarterly planning. Some people unfurl a product list that goes down the hallway, then announce they will do one quarter’s worth of work, prioritized, and that is their job. The problem is that this does not cut it, so the gap becomes the CEO’s job. What you actually want are people who will find a way through seemingly impossible constraints, because that is the market reality, not a theatrical assignment. A startup sits somewhere between completely impossible and very, very hard, with only a slim window between them.

Guo offers a diligence detail from Rippling’s Series A: she called twenty-odd people who used to work for him, and the most universal line was that they would follow him to the ends of the earth because he got more out of them than they knew they had. Conrad is quick to note that other former employees would call him totally unreasonable. His method is to lay the situation out. The gap is there; he did not create it and they may not have either; you can give up and go home or try to find a way. He cites a site Patrick Collison maintains comparing organizations: the moon landing in four years versus Van Ness Avenue in San Francisco taking something like twelve. People think grinding buys an extra 20 percent. The difference between teams that accomplish a lot, he says, is an order of magnitude.

A concrete habit: people come to CEOs with what he calls CEO-in-a-box options. You can have A or B; which is the priority? That is an illusion of choice, because the important decision—A or B versus A and B—has already been made. He reflexively rejects the premise. He wants A and B. Why can they not coexist? Does it violate the second law of thermodynamics? It can sound like asking for the impossible. Sometimes the work is to think more deeply and find a third path, because the cost of the trade-off can be the difference between success and failure. The fuel, he admits, is a deep reservoir of panic and insecurity about looming failure. The productive version is to push that down into the organization so people own the gap between point A and point B, not just this month’s task. Guo’s cut is sharper: many leaders do not push the problem down because they do not really believe other people can solve it.

Coordination between capabilities teams and application teams is something Rippling does not always get right. Anyone building this way lives with constant tension. The interface is not clean; an application team wants something slightly different and would prefer not to build on the platform’s stuff. The meaty product decisions are when you allow teams to disconnect, when you re-prioritize the platform team, and when people eventually have to migrate back. Locally, people would almost always rather build their own thing. Long-term, that is the worst outcome for the business and even for their application, because you lose the benefit of shared investment.

The math is the whole strategy. Every dollar of R&D spent on the underlying systems, Conrad says, pays off 35x, because it hits every system in Rippling and makes each one a little better. That compounding is why the platform approach beats narrow point solutions, and it is why you have to hold on to the Lego blocks. Guo compares notes with Olivier Pomel at Datadog, another true platform company of this era. After Datadog bought a company she had been on the board of, Pomel made the acquired team rewrite onto Datadog’s platform over the first year and a half. It was painful. On the way out, the acquired people believed. Workday and Microsoft get mocked for internal language, frameworks, components, and platform teams. That insularity, she suggests, is how some of the most dominant platforms are actually built.

Beating incumbents and capturing greenfield are related. Rippling can beat incumbents because it has pushed into new horizons and can solve problems they cannot. Internally, the difference between a new application, a new feature, and a bug fix is often just whether the team believed the capability was in the original spec. From the customer’s perspective, it is always the same sentence: I wish it did this thing and it does not. “To them, like everything’s a bug.” The example on the table is a variable-compensation product—new SKU, new application—that existing customers experience as the missing piece that would make payroll easier, because bonuses and commissions are tough to manage anywhere else.

Headcount makes the priority obvious. Over 80 percent of engineering is focused on existing applications and the underlying platform. Very little is on net-new things. You need fewer people when you are building something new: there are no existing customers yet, and you get to stand on the platform, so you can get very far with a small team. They typically have four or five new things in the works, each with perhaps five to seven engineers, inside an engineering organization that is now over a thousand people.

Guo puts the fashionable premise on the table: over the next two years, will a large engineering organization do a lot more with many fewer people? Conrad is skeptical that AI will be employment-conserving. Coding assistants are popular, and they clearly help, but Rippling has not seen a huge efficiency gain, and neither have most of the late-stage companies he has spoken with. Nobody is saying they need far fewer people. Even if the tools get much better, making software easier to build will, he thinks, send demand for software way up. He believes the same about customer support. As the experience gets instantaneous and less frustrating, people use more of it, not less. Ticket deflection can rise while usage of Rippling’s AI-enabled support tools rises even faster, because the tool starts to feel like a way to get things done in the product.

His theory of where the extra engineering capacity goes is verticalization. Core systems will sprout industry-specific versions—Rippling for ophthalmology clinics, with capabilities just for that setting—because the cost of building an application has come down. Independent vertical software has historically faced a nasty choice: heavily customized for the industry, but missing core underlying capabilities, so a serious company eventually has to move to something like Salesforce. If building gets cheaper, the horizontal platform companies can ship those vertical applications themselves. The vibe-coding corollary is cold. If you and a small team can spin up an app and get distribution quickly, so can a lot of other people. The bar will go up, pricing will come down, the frontier will move out, and staying there will take more engineers and more investment. The same logic holds in go-to-market: every competitor gets the efficiency too, so cutting through the noise still requires people who can talk to customers and decision-makers.

Gil sketches two vertical plays: industries whose workflows are different enough, such as pharma shaped by a regulatory regime, and companies that do not see themselves as traditional software vendors so much as doing work customers used to outsource. Conrad does not fundamentally disagree with the idea of buying distribution by rolling up services companies—those buyers also say they do not want to be in the ops business—but replacing ops with software is hard. At Zenefits they thought they could move faster manually and automate later; once you have scaled the ops, capturing the superset of requirements is brutally difficult. It is easier to start with a smaller set of customers, even though no customer has simple needs, and expand capabilities over time.

The test he would apply is whether the domain has to be deterministically correct. Payroll that is off by a rounding error makes customers furious. You need a programmed rules engine, not the entropy of an AI system, especially across a large space of edge cases. Rippling’s own AI posture has become more focused on data. Building AI applications is not trivial, but it is easier than governance, permissions, and data pipelines. Those are core strengths, because permissions are usually about job, role, function, and org-chart relationships. He thinks AI agents will need to inherit the permissions of the person they work with. A distinct service account sounds clean until a human interfaces with it; different permissions create a leakage problem. Inherit the person’s access and you are back to identity, job function, and governance—the platform layer.

Rippling is already at public-company scale, Guo notes, while companies are staying private much longer. Conrad has no religion about the choice and does not claim to be the world’s expert. Historically, a big advantage of being public was liquidity. Over the last couple of years there has been a lot more liquidity in the private markets, for employees and for early investors. If you can get that privately, there is a lot of upside to staying private. He points at Databricks versus Snowflake: Databricks seems to have had some advantages by not being public.

Public markets, in his telling, have become something of a retirement community for very slow-growth, very profitable companies. When research analysts talk about high growth versus low growth, the cutoff is whether you are growing more than 20 percent—not 30, because 30 no longer exists in the public markets. A company growing a lot faster than that has no clear comps, which makes multiples and valuation a real risk. That calculus could flip. Public markets might start valuing fast growers again; private capital might dry up. Rippling has decided to stay private for now, which does not mean forever. You get to make that choice again every year. Go public, and it is hard to undo.