Startup Experts Discuss Doing Things That Don't Scale

There's nothing like that founder FaceTime in the early days, right? And that's a great example of something that doesn't scale, but that's so important in recruiting customers, recruiting employees, anything you can do to optimize for these learnings is good to do. And doing things that don't scale, I think the main goal is that how much can I learn?

In 2013, Paul Graham, the founder of Y Combinator, wrote an essay entitled "Do Things That Don't Scale." This essay transformed the culture of Silicon Valley. PG said not to worry about the theoretical problems of scaling and fix the thing in front of you right now. Do everything you possibly can to get early customers and delight them, even if it meant doing things in a manual and one-off way. The essay created a playbook for startups who needed to get from zero to one, and many of them made it, and they're making it right now.

So today, we'll hear from the Y Combinator partners about the best examples of companies that did unscalable things to get off the ground. Let's get started.

To set this up, what I remember from being a founder in the early 2000s is that investors and people in general at big tech companies were obsessed with this word scalability. Because the issue with the internet and the issue with websites was that people created these early web servers, processors were pretty slow, the size of bandwidth was pretty slow. So if you wanted to build an internet company, if it only could serve 10,000 or 100,000 people and the site crashed, it didn't scale. It was actually pretty hard to scale. It was a real problem.

This meant, in addition to technically scaling, which in this case just means the servers can handle the load; it also meant business models had to scale. A scalable business model would mean a business model that does not top out at a small amount of money. It's a business model that could go all the way into making billions of dollars.

I actually think Google is indirectly responsible for warping the minds of a whole generation of founders and investors and creating the problem that Paul Graham had to solve with his essay. Because Google became so famous for this, because they did so much content marketing, everybody wanted to emulate Google. So everybody from one wanted to do the same thing and to be thinking about how they were going to build something that was as scalable as Google. You wouldn't be able to raise a dollar from investors if you did not have a scalable solution.

Period. Full stop. And again, I'm not saying this is wrong, but this created the elephant in the room when you were a founder during that era. I would argue, to a lesser extent, still to this day, if you did not have good answers to how your product or solution or business model scaled, it was not considered a venture capital fundable company. Paul Graham heard this problem because many Y Combinator companies were obsessed with this thinking of scalability for all the reasons I just mentioned. So he had to invert it and say the opposite: ignore this.

He wrote this essay with this amazing title "Do Things That Don't Scale." Yep. This essay, I would argue, transformed the culture. It actually transformed, not overnight, but over the years that followed, it transformed Silicon Valley culture, and it became ingrained in the psyche of the current generation of entrepreneurs.

I agree because what he realized was the biggest problem that most startups have is they can't get users and they're not making something people want. Not that their architecture is not scalable enough. Think about how many startups build something this beautiful thing that has like so much scalability, and no one wants it. It's like, if you build it, they will come. The field of dreams startup, right? It's this beautiful thing and you hire a big team and it's like you got all the servers set up and you're ready to scale, you got a Chief Architect in place, and like no one cares, and everyone churns. It's game over.

This "do things that don't scale" and at the time, it was such a contrarian title. I would say it's analogous to Mark Zuckerberg's "move fast and break things." Do things that don't scale. It sounded at the time like somebody was crazy. It was so contrarian, especially coming from an investor, which is why it had a real impact.

The context to me, the point of Paul Graham's essay, and that we talk about all the time in office hours is worry about the thing that is your biggest problem at any one point of time and try to slay that dragon first before you worry about later dragons. You have to slay. And for most startups, it's just getting from zero to one. It's getting a first customer, it's building the first product.

To just get from zero to one, you don't need to worry about scalability. So don't. If you're lucky enough that people want your product enough, yes, that you have the luxury of worrying about scalability, great. Okay, then you should totally scale again, like he's not saying never scale ever for any reason, that is not what the advice is. It's just worry about it at the right time.

As Dalton and Jared pointed out, "do things that don't scale" really encouraged founders to focus less on the future problem of scaling and more on solving the hair-on-fire problems of their first customers. It was about focusing on what really matters in the moment.

Next, Harge and Pete talk about the Airbnb founders and what they did to inspire Paul Graham's essay. So what do we mean, Harge, when we say do things that don't scale? What are those actual things?

I feel like a lot of the spirit behind PG's essay here was to get startups to feel urgency and be like, "Hey, you don't have time to spend 6 months writing the perfect piece of software before you go and get a real customer." I feel like what inspired him with this was the Airbnb guys. They had been working on that idea for a while, had no users, and they needed to get the flywheel turning. One of the pieces of advice he gave them was, "Hey, look, like you need just like really high quality listings. The most important part of a listing is a photo. So if you can't get people to upload high-quality photos, just go and take them yourself and like have this catalog of really great places to stay with like professional quality photos."

So the Airbnb guys would go out and do that. That was clearly something that did not scale. That's what got them that flywheel turning early on. If they had been like, "Oh, we can't do that because that's never going to scale," they would have totally missed out on that. Totally right. It's like so much of that work is actually just like, it can feel beneath you in a way.

If you come from like a really well-paid job at like Google or Facebook, you're used to having reports and infrastructure and people doing all this stuff. Then you come into a startup and it's like, "Okay, I've got to send the cold email, I've got to cold call, I've got to do all of this, I've got to manage all of the admin stuff, I've got to get the company incorporated, like no one else is going to do it."

One thing I've noticed is that the best founders, no matter how smart they are, like they just dive into that. I think you just got to have that mindset of like nothing is beneath me. The only thing I care about is like getting to product-market fit, serving customers, getting users, and that will send you in the right direction as an early-stage founder. No task is beneath you. No action is too small or manual if it is in service of your customers. That's an important piece of this philosophy.

Next, Nicholas and Brad talk about the unscalable things that Nico did at Algolia to get his first customer and how he used that practice to more deeply understand what his users needed. We in our jobs run across companies sometimes that are terrific examples of doing things that don't scale. There's a company from the winter 22 batch that I worked with called Fleek. They are a marketplace for secondhand clothing connecting wholesalers—the people who just like get tons and tons of clothes coming in in boxes from all over the world—and actual secondhand clothing shops.

So it's like the back-office stuff. How does the clothing and the secondhand clothing shops get there? Fleek is this marketplace that connects the two. So what did they do? When they started out, it was just three guys with an idea, and they didn't have a website, they didn't have any clothes, they didn't have anything. They had to figure out how do we get a marketplace started between these two parties.

They would go to the wholesalers in London, these giant warehouses full of clothes, and they would say, "Give us this box. Just pick a box of clothes and say give us six hours. Just give us the box for free. We'll bring it back in six hours and either you'll have all the clothes back or you'll have a bunch of money."

So they would get these clothes basically and they would sell them to all these shops around London and come back with $6,000 for the store. They would do that over and over and over again and go to these different wholesalers. Eventually, people knew them as these like useful people in the wholesale community who were helping match buyers and sellers.

So what did they learn from that? They did it because they had to figure out who actually sells, what sells, what doesn't sell, when's the best time to bring clothing in there, how to price this stuff, how elastic is the demand for it. These are things that you need in a marketplace. But it's very, very hard to figure that out by building a marketplace webpage and then emailing a bunch of people and asking them to transact in it. Instead, they did this mishmash in person, carrying cartons of clothes around and selling them by hand to get all those lessons into their bones.

How long did they do that? They did that for about four months. That was a great way for them to get started, but eventually, they needed to transition and start introducing the buyers and sellers to each other through their website. Because at the end of the day, in order for them to have a scalable business that can start making money with good margins, they needed the buyers and sellers to be transporting the clothes themselves and using their own delivery fleet and employees to actually make the connections. It can't just be the CEO and the founders of the company moving products back and forth.

A great story that gives me a good impression is the story of Stripe. It's a pretty well-known story. When the Stripe founders would actually work with their customers, like implement their software, their API directly in the software of their customers. And we actually did that with Algolia too. I remember when we implemented Algolia in Product Hunt. You know, Ryan, the founder, that was before Product Hunt became huge and he didn't have like any resource to implement search himself.

So we remembered the Stripe story. We did it. He gave us access to his GitHub. The first version of Algolia of search on Product Hunt was us implementing it and pulling requests and him putting that. He was probably thrilled for the help at the time. He loved it. He couldn't ever have done it otherwise.

For him, it was such a help. And for us, of course, it paid back like thousandfold. Do you feel like you learned anything from setting customers up in that way? Yeah, because that created connection. Because from that point, you have that contact, that connection with the customer that is so much stronger. You can ask them anything. You have way more candid conversations with them than if they are your customers and always worried about what else you're going to ask them, like money or whatever.

That's a great point. You have context that all of your later conversations and interactions with them kind of grows out of. You know why they're using it, what they want to get out of it, and that helps you develop the product yourself. But it also helps them have a much better experience using the product. Anything you can do to optimize for these learnings is good to do and doing things that don't scale.

I think the main goal is that how much can I learn today, not waiting to have developed anything. Maybe what I'm going to develop is going to be the wrong thing. Like if I can do anything manually, even physically doing the job yourself, not with software, you are going to make sure that what you're building is actually providing value. Better do that before being needed too much.

So said differently, really strong, exciting founders that we run across are people that are operating in a way that optimizes for learning. When we see people, oh like let's jump to self-service early on, in some ways, you wonder like, oh they want to hide behind their computers versus going out and talking to their customers and really grappling with their problems and their pain.

Optimizing for learning is a good way of looking at it. As Brad pointed out, the best founders we work with at YC operate in ways that optimize for learning, and getting in the trenches with your customers is an incredible way to learn about their biggest pain points.

Next, Serban and Aaron talk about how founder FaceTime with customers can give you a real advantage over your bigger, better-funded competitors. There's nothing like that founder FaceTime in the early days, right? And that's a great example of something that doesn't scale, but that's so important in recruiting customers, recruiting employees.

One of the best sales founders that I worked with was Ryan from Vendor, and Vendor is SaaS software for startups and big companies. He's really great at sales. One of the things that I've heard him talk about and that I learned from him is that as a founder, you have to sell yourself. Especially when you don't have a product, you have a product. That's the only thing you have. Exactly. It's like really janky.

When you're reaching out to somebody, you say, "Here's my cell phone, contact me any hour of the night," or, you know, "Reach out to me because I'm basing the future success of my company on making you successful, and I'm going to do whatever it takes to do that. I will stop at nothing to do that." Ultimately, when you're selling to somebody, especially as an early-stage founder, what you're really selling is yourself. You have to get them to make a bet on you.

Leaning into that is important because, especially sometimes, people are scared like, "Oh, I'm going up against this big, well-funded competitor or a public company." Like, what middle manager is going to give out their personal cell phone number when trying to win a customer's business? Like, nobody's going to. If you make people feel like you care about them and you're going to stop at nothing and your personal career depends on making them successful, people are going to want to go with you every single time.

Don't be afraid of taking that first step that doesn't scale so you could truly validate what it is you're working on. Anything is better than standing still, and sometimes making progress means doing things that don't scale. One of my favorite examples of a company that did unscalable things to get off the ground is Instacart. In his original essay, he says partnerships usually don't work. They don't work for startups in general, but they especially don't work as a way to get growth started. Startups can't rely on big partnerships with brands to get going, so they're forced to be more creative.

Here's the story of how Instacart launched without a single grocery store partnership. Do you have any good examples of this, maybe from your own companies or from other companies you work with? The best example that I love is from Instacart.

Instacart is a service that lets you, I'm sure a lot of people are familiar with, you open your app and you can browse the inventory from a grocery store and make an order. So a normal person starting this business might think, "Oh, we've got to support Trader Joe's and Whole Foods, so let's go talk to the management of Trader Joe's and try and get some kind of corporate partnership or something, get access to the data, and like it's going to take a really, really long time."

You know, we have to pay salaries and some lawyers and all this kind of stuff that might take years. Instead, what Instacart did was they took their YC money and went to Trader Joe's and just bought one of every item at Trader Joe's. Over a weekend, got access to a photography studio, took all the produce that they bought, took it to the studio, took pictures of it all, wrote down the prices, and on Monday morning put all of it online and said, "We're Instacart, you can order anything from Trader Joe's."

Some founders might say, "Maybe this is not perfectly legal. Trader Joe's might object." You'd get a cease. Even if it is legal, does this matter? I think it matters that you're not doing anything illegal. Yeah, I think if Trader Joe's objected to you running this thing honestly, they'd probably only notice when you get to a certain scale. Then you have the negotiating leverage. You have all these customers who are already buying through Trader Joe's that actually they don't want to shut you down, and that's exactly how it played out with Instacart.

They struck deals with these grocery stores eventually after they got to scale and they'd used this kind of hacky, janky solution to get to scale because it took a founder to highlight to them that this idea was a good idea; otherwise, they would have never come up with it themselves. Absolutely. If you'd have gone to Trader Joe's or Whole Foods with nothing and tried to present this idea, you'd have been laughed out of the room.

Probably, at the very least, it would have taken you years to get that deal. Okay, all of these examples end up succeeding, but the cases where you do things that don't scale and it turns out no one wants a thing, actually that's good as well, right? Because you've just saved yourself months or potentially years of building something that actually no one wants. It's way better to know that up front and be able to pivot your product slightly or choose a whole new idea completely.

By doing this stuff that doesn't scale, you've not like hardcoded yourself into a corner. You know, you haven't written so much software that it's hard to change. A lot of the processes are manual. You're doing it yourself. So if you want to try something different the next day, it's really easy because there's no software to change. The bet that you're making ultimately is once you figured out the right configuration of the service or the product or whatever it is, that you will then be able to use software, right? An algorithm that will provide the same level of quality of service at scale.

But it might take you several years of investment to do that, and so in the early days, without making that investment, you can give the appearance of that service or product already existing by basically faking it manually, by pulling the strings in the background, doing tons and tons of hard work yourself to deliver that incredible white-glove experience to customers.

Doing things that don't scale lets you experiment, fail fast, and try new things. It lets you test your assumptions before you spend months building a product from an engineering perspective. Doing unscalable things gives you the freedom to move more quickly. The first version of your product doesn't need to have a robust technical infrastructure.

Next, Diana and Michael will talk about DoorDash and how they built the first version of their product in one day and did a lot of clever manual work to find out whether people wanted what they were building. DoorDash as a product was built in one afternoon. Whether you believe it or not, the tech stack was basically Google Drive to upload the menus, HTML, CSS for putting the menus. The phone was Tony's phone, and then Find My Friends to pretend to have real-time dispatch.

It would be one of the founders going to pick up the order, and then the other founder, it was a team of four, would be watching in real-time where with Find My Friends where the order was, and it would text the customer, "Hey, your order ETA is 10 minutes, 20 minutes." The orders were just taken on Google Form.

Granted, the team was actually very technical. It was a team of Stanford engineers, Stanford MBAs. They totally could have done the fancy thing and built a dynamic site with Google Maps, real-time tracking, and everything. But the founders were very pragmatic. That was not the hardest thing to prove out. It was like, "Is this even a thing that people wanted?" That was the startup way.

That's the path no big company would ever take. This is the advantage you have as a startup, right? It's the thing you can do and no one else can do. To your point, too many founders kind of have to unlearn what they learned at the big companies. If you play the big company game, they will always beat you. You always have to think about what would you have gotten fired for at the big company. That should be your playbook at the startup.

I think the second kind of misconception that's embedded inside of a lot of startup founders' minds is there's a way to do this in an error-free way. Like if I'm working at Google, I have to be far more careful, right? I need to create plans that are kind of error-proof. That's why it takes Google forever to do anything. As a startup, your path is full of errors. Errors are the feature.

So like should you be so lucky to have a product that so many people want to use that it crashes, and then you have to figure out how to scale, that is the correct thing. The way I always try to describe this is like imagine a house that has a number of cracked pipes, and you have no idea which pipes are cracked or not. The big company person would go and check every pipe one by one, and it would take two years.

The startup person turns on all the water and says, "Where's water coming from?" That pipe's cracked, let's go fix it. It turns out that when you are dying because too many people are using your product, the motivation to fix those bugs goes through the roof, and they get fixed rather quickly.

I don't think we've seen startups die because of that reason. That is actually 100% solvable problem, and you're not going to die from it because the incentives are so high to fix it, and you're on the path to build a large company at that point. But most of them don't even get to see that, and you got to run the pipe and run with the mess and embrace the chaos.

Doing things that don't scale is the startup way. It's the advantage you have as a small company. But at what point should you stop doing unscalable things? When do you flip the switch? This is a really important one because people who get from zero to one often get stuck here. Harge and Pete discuss the other side of this advice, though.

It's like "do things that don't scale" is great advice, but at some point, you do need to scale. I think that's where it's useful to have good advisors and investors around you because they can tell you like, "Hey, look, no, no, no, no, like you're in do-not-do-things-that-don't-scale mode." And like, "Oh, actually, like now you need to flick the switch, and now this is working, now you should scale."

Yeah, I think that's a great point, and you can think of kind of those early doing things that don't scale as a quick way to answer an important question. Once you've answered that question, well, now you have license to invest.

One of the forms that I've seen this question take with founders that are building SaaS software is that there's this moment in the earliest stages where you can make money by selling consulting services to other companies, right? We actually had this example at Optimizely, where we were building software to help companies run A/B tests. But at the earliest stages, we got companies to pay us just to go in and manually build A/B tests for them, right? And so, we're making money.

Great. The first version of our product was actually something that we used to make ourselves more productive in delivering those consulting services. That's all great, right? Because it helps you answer the question, "Is this something that anyone will pay for?"

Yes. It turns out the answer is yes. The failure mode here, though, is getting addicted to that consulting revenue because like that's the thing that won't scale. Quite literally, like it won't scale, and you won't be able to build a big business if you depend on human labor. It's a really interesting example of where you can't just fixate on just your revenue number because you can always get revenue to go up by taking on more consulting.

That's why you can get around it by just setting yourself really ambitious growth targets. I feel like this is partly why we push the companies to have such big growth targets. One way investors tell apart what's a consultancy or a small business from like a startup that could be Stripe or Airbnb one day is like can it grow 10x? You can't grow a consultancy business like 10x in a year. You can grow like a real software business totally.

The advice to do things that don't scale might sound counterintuitive, but it is truly the best advantage startups have over their larger competitors. It helps you intimately learn about your customer and their problems, it ties those early users to you more tightly, and gives you opportunities to delight them. It makes it possible to experiment quickly and fail fast.

If things aren't working, go read Paul Graham's essay right now. Link in the description below. That's it for this episode of office hours. If you like this and want to see more, please be sure to click like, subscribe, and the bell icon down below. We'll see you next time. [Music]