Tips For Technical Startup Founders | Startup School

[Music]

Welcome everyone to "How to Build and Succeed as a Technical Founder" for the Startup School talk. Quick intro, I'm Diana, who I'm currently a group partner at YC. Previously, I was a co-founder and CTO for Azure Reality, which was a startup building an augmented reality SDK for game developers. We eventually had an exit and sold to Niantic, where I was the director of engineering and heading up all of the AR platform there.

So I know a few things about building something from was just an idea to then a prototype, to launching an MVP, which is like a bit duct tape-y, to then scaling it and getting to product-market fit, and scaling systems to millions of users.

So what are we going to cover in this talk? It's three stages. First is, what is the role of the technical founder and who are they? Number two, how do you build in each of the different stages where all of you are in startup school? Ideating, which is just an idea and you're just getting started; building an MVP, once you got some validation and getting it to launch; and then launch, where you want to iterate towards product-market fit. And then I'll have a small section on how the role of the technical founder evolved post-product-market fit.

I won't cover it too much because a lot of you in startup school are mostly in this earlier stage, and I'm excited to give this talk because I compiled it from many conversations and chats with many YC technical founders, like from Algolia, Segment, Optimizely, WayUp. So I'm excited for all of their inputs and examples in here.

All right. The technical founder, sometimes I hear non-technical founders say, "I need somebody to build my app," so that isn't going to cut it. A technical founder is a partner in this whole journey of a startup, and it requires a really intense level of commitment, and you're in just a dev.

What does a technical founder do? They lead a lot of the building of the product, of course, and also talking with users. Sometimes I get the question of who is the CEO or CTO for a technical founder, and this is a nuanced answer. It really depends on the type of product, the industry you're in, the complete scale, and the composition of the team to figure out who the CEO or CTO is. I've seen technical founders be the CEO, the CTO, or various other roles.

What does the role of the technical founder look like in the early stages? It looks a lot like being a lead developer. If you've been a lead developer at a company, you were in charge of putting the project together, building it, and getting it out to the finish line. If you're contributing to an open-source project and you're the main developer, you make all the tech choices.

But there's some key differences from being a lead developer. You’ve got to do all the tech things. Like, if you're doing software, you're going to have to do the front-end, the back-end, devops, the website, the UX, even IT to provision the Google accounts—anything. If you're building hardware and maybe you're just familiar with electrical and working with EagleCAD, you'll have to get familiar with the mechanical too.

And, of course, as part of doing all the tech things, you'll have to talk with users to really get those insights to iterate. You're going to have a bias towards building a good enough versus the perfect architecture. Because if you worked at a big company, you might have been rewarded for the perfect architecture, but not for a startup. You're going to have a bias towards action and moving quickly, actually deciding with a lot of incomplete information.

You're going to get comfortable with technical debt, inefficient processes, and a lot of ugly code, and basically lots of chaos. All of this is to say is the technical founder is committed to the success of your company, and that means doing whatever it takes to get it to work. It's not going to cut it if you're an employee at a company. I sometimes hear, “Oh, this task or this thing is not in my pay grade.” No, that's not going to cut it here. You've got to do what you've got to do.

This next session is on how to build. The first stage is the ideating stage, where you just have an idea of what you want to build. The goal here is to build a prototype as soon as possible, with the singular focus to build something to show and demo to users. It doesn't even have to work fully. In parallel, your CEO co-founder will be finding a list of users in these next couple days to set up meetings to show the prototype when it's ready.

So the principle here is to build very quickly in a matter of days. Sometimes I hear, "Oh, Diana, a day prototype? That seems impossible! How do you do it?" One way of doing it is building on top of a lot of prototyping software, and you keep it super, super simple.

So for example, if you're a software company, you will build a clickable prototype, perhaps using something like Figma or InVision. If you're a dev tools company, you may just have a script that you wrote in an afternoon and just launch it on the terminal. If you're a hardware company, or hard tech, it is possible to build a prototype; maybe it takes you a little bit longer. But the key here is 3D renderings to really show you the promise of what the product is.

The example I have here is a company called Remora that is helping trucks capture carbon with this attachment, and that example of that rendering was enough to get the users excited about their product even though it's hard tech. So I'll give you a couple examples of prototypes in the early days. This company, Optimizely, went through YC in Winter 10, and they put this prototype together literally in a couple of days. The reason why is that they had applied with YC with a very different idea. They started with a Twitter referral widget, and that idea didn't work, and they quickly found out why.

So they strapped together very quickly this prototype, and it was because the founders, Pete and Dan, and Dan was actually heading analytics for the Obama campaign. He recalled that he was called to optimize one of the funding pages and thought, "Huh, this could be a startup."

So they put a thing together very quickly, and it was the first visual editor by creating an A/B test that was just a JavaScript file that lived on S3. I literally just opened option command J if you're in Chrome, and they literally ran manually the A/B test there, and it would work. Of course, nobody could use it except the founders, but it was enough to show it to marketers, who were the target users, to optimize sites to get the user excited. So this was built in just a few days.

Another example is my startup, Azure Reality. Since we were building more hard tech, we had to get computer vision algorithms running on phones, and we got that done in a few weeks. That was a lot easier to show a demo of what AR is, as you saw in the video, than just explaining and hand-waving. It made selling and explaining so much easier.

Now, what are some common mistakes on prototypes? You don't want to overbuild at this stage. I've seen people have this bias, and they tell me, "Hey Diana, but users don't see it, or it's not good enough; this prototype doesn’t show the whole vision!" This is the mistake when a founder thinks you need a full MVP at this stage.

And not really, the other mistake is obviously not talking or listening to users soon enough. You're going to get uncomfortable and show this kind of prototyping duct-tape thing that you just slapped together, and that's okay. You're going to get feedback. The other mistake at this stage, as an example for Optimizely, is when founders get too attached to an idea when the feedback from users is something obvious that is not quite there—not something that users want—and it's not letting go of bad ideas.

Okay, so now into the next section. So imagine you have this prototype, you talk to people, and there's enough interest, then you move on to the next stage of actually building an MVP that works to get it to launch. The goal is basically to build it to launch, and it should be done also very quickly, ideally in a matter of few days, or it can be done in a few weeks or sometimes months, but ideally more on the weeks range for most software companies; again, exceptions to hardware and deep tech companies.

So the goal here at this stage is to build something that you will get commitment from users to use your product. Ideally what that commitment looks like is getting them to pay. The reason why you have a prototype is while you're building this, your co-founder or CEO could be talking to users and showing the prototype, and even getting commitments to use it once it's ready to launch.

So, I'm going to do a bit of a diversion here because sometimes founders get excited, like, "Oh, I show this prototype; people are excited, and there’s so much to build. Is hiring a good idea?" First, it's a thing: "Okay, I got this prototype; got people excited; I'm going to hire people to help me to build it!"

As a first-time founder, you're like, "Oh my God! Oh my God! There's a fit; people want it! Is it a good idea?" It really depends. It’s going to actually slow you down in terms of launching quickly because if you're hiring from a pool of people and engineers that you don't know, it takes over a month or more to find someone good.

It's hard to find people at this stage with very nebulous and chaotic. So it's going to make you move slowly. The other more insidious thing is going to make you not develop some of the insights about your product because your product will evolve if someone else in your team is building that and not the founders. You're going to miss that key learning about your tech that could have a gold nugget, but it was not built by you.

I mean, there are exceptions to this. I think you can hire a bit later when you have things more built out, but at this stage, it's still difficult. So I'll give you an example here: Justin TV and Twitch. It was just the four founders and three very good technical founders. At the beginning for the MVP, it was just the founders building software as software engineers, and the magic was Justin, Emmett, and Kyle building different parts of the system.

You had Kyle, who became an awesome, fearless engineer tackling the hard problems of video streaming, and then Emmett doing all the database work, and Justin with the web. That was enough to get it to launch. I'll give you an exception: after they launched, they did hire good engineers, but the key thing about this is they were very good at not caring about the resume; they tried to really find the misfits and engineers that Google overlooked, and those turned out to be amazing.

So Amon and Golem were very comfortable and awesome engineers, and they took on a lot of the video weapon just three months since joining. You want people like that that can just take off and run.

All right, so now going back into the principles for building towards your MVP. Principle one is the classic Hologram essay on "Do Things That Don't Scale." Basically find clever hacks to launch quickly in the spirit of doing things that don’t scale.

And the Drake posting edition of this: avoid things like automatic self-onboarding because that adds a lot of engineering building a scalable back-end automated scripts. Those sound great at some point but not at this stage. The hack, perhaps, could be manually onboarding; you're literally editing the database and adding the users or the entries and the data.

On the other counter thing, insane custom support: it's just you, the founders, at the front line doing the work, doing things that don't scale. A classic sample is with Stripe. This is the site when they launched. Very simple; they had the API for developers to send payments, but on the back end, the thing that did not scale was literally the founders processing every manual request and filling bank forms to process the payments at the beginning. That was good enough to get them to launch sooner.

Now, principle number two: this is famous—create a 90-10 solution. That was coined by Paul Buchheit, who was one of the group partners here at YC and the original inventor of Gmail. The first version is not going to be the final. Remember, and there will likely be a lot of the code be rewritten, and that's okay. Push off as many features to post-launch, and by launching quickly, I created a 90-10 solution.

I don't mean creating bugs; I still want it to be good enough. But you want to restrict the product to work on limited dimensions, which could be like situations, types of data you handle, functionality, types of users you support, could be the type of data, the type number of devices, or it could be geo. Find a way to slice the problem to simplify it, and this can be your secret superpower as a startup at the beginning because you can move a lot quickly, and large companies can't afford to do this.

Or even if your startup gets big, you have lawyers and finance teams and sales teams that make you kind of just move slow. So, give you a couple of examples here: DoorDash, at the beginning, they slapped it together in one afternoon. They were actually called Palo Alto Delivery, and they took PDFs for menus and literally put their phone number—the phone number there is actually from one of the founders.

The site is not dynamic, static; it's literally just plain HTML and CSS and PDFs—that was their front end. They didn't bother with building a back end. The back end, quote-unquote, was literally just Google Forms and Google Docs, where they coordinated all the orders. They didn't even build anything to track all the drivers or ETA; they did that using Find My iPhone to track where each of the deliveries were. That was enough.

So this was put together literally in one afternoon, and they were able to launch. The very genius thing they did is because they were Stanford students, they constrained it to work only on Palo Alto, and counterintuitively, by focusing on Palo Alto and getting that right as they grew.

It got them to focus and get delivery and unit economics right in the suburbs right at the beginning so that they could scale that and get that right versus the competition which was focusing on Metro cities like GrubHub, which make them—now you saw how the story played out. The unit economics and the ops was much harder and didn't get it right.

So funny thing about focusing at the beginning and getting those right can get you to focus and do things right that later on can serve you well.

So now at this stage, how do you choose a tech stack? One thing is to balance what makes sense for your product and your personal expertise to ship as quickly as you can. Keep it simple. Don't just choose a cool new programming language just to learn it for your startup. Choose what you're dangerous enough and comfortable to launch quickly, which brings me to the next principle: choose the tech for iteration speed.

Now, the other thing is also it’s very easy to build MVPs very quickly by using third-party frameworks or API tools, and you don’t need to do a lot of work. For example, for authentication, you have things like Auth0; for payments, you have Stripe; for cross-platform support and rendering, you have things like React Native; for cloud infrastructure, you have AWS, GCP; for landing pages, you have Webflow; for backend, serverless, you have lambdas or Firebase or hosted databases.

In the past, startups would run out of money before even launching because they had to build everything from scratch. Shift from metal. Don't try to be the kind of like cool engineer just building things from scratch—no, just use all these frameworks. But I know CTOs tell me, "Oh, it's too expensive to use these third-party APIs," or "It's too slow; it doesn't scale to use XYZ."

So what I'm going to say to this is, I mean, there's two sides of the story with using third-party. I mean, to move quickly, but it doesn't mean—this is a great meme that Sean Wang, who is the head of developer experience, posted. The funny thing about it is you have at the beginning quartile kind of the noob that just learned PHP or just JavaScript and just kind of use it to build the toy car. Serious engineers make fun of the noob because, "Oh, PHP language doesn't scale," or "JavaScript," and all these things.

It's like, "Oh, PHP is not a good language, blah blah." And then the middle or average or mid-wit engineers are like, "Okay, I'm going to put my big engineer pants on and do what Google would do and build something optimal and scalable." They use something for the back end like Kafka, Linker, Ros, AMA, Prometheus, Kubernetes, Envoy, big red, or hundreds of microservices.

Okay, that's the average technical founder, and the average startup dies, so that's not a good outcome. Another funny thing, you got the Jedi master, and when you squint, their solutions look the same as the noob. They chose also PHP and JavaScript, but they chose it for different reasons—not because they just learned it, but they recognized it's because they can move a lot quicker.

What I'm going to emphasize here is that if you build a company and it works, and you get users, good enough—the tech choices don't matter as much. You can solve your way out of it. Like Facebook famously was built on PHP because Mark was very familiar with it, and of course, PHP doesn’t quite scale or is very performant.

But if you're Facebook and you get to that scale of the number of users they got, you can solve your way out. And that's when they built a custom transpiler called HipHop to make PHP compile to C++. So that it would optimize—see, so that was the Jedi move.

Even for JavaScript, there's a V8 engine which makes it pretty performant. So I think it's fine. WayUp was a 2015 company at YC that helps companies hire diverse companies and it’s a job board for college students. So JJ, the CTO, although he didn’t formally study computer science or engineering at UPenn, he taught himself how to program and freelance for a couple of years before he started WayUp.

JJ chose, again, as the Jedi Master, chosed technology for iteration speed; he chose Django and Python, although a lot of other peers were telling him to go and use Ruby on Rails. I think in 2015, Ruby on Rails were 10 times more popular by Google Trends, and that was fine—that didn’t kill the company at all. I mean, that was the right choice for them because he could move and get this out the door very quickly; kept it simple in the back end: Postgres, Python, Heroku. And that worked out well for them.

Now, I’m going to summarize here. The only tech choices that matter are the ones tied to your customer promises. For example, at Azure, we in fact rewrote and threw away a lot of the code multiple times as we scaled in different stages of our tech, but the promise that we maintained to our customers was at the API level in Unity and game engines, and that’s the thing that we cannot throw away. But everything else, we rewrote, and that’s fine.

All right, now we're going to go to part three. So you have the MVP; you built it and launched it. Now you launched it. So what happens at this stage? Your goal here in the launch stage is to iterate to get towards product market fit.

So principle number one is to quickly iterate with hard and soft data. Use hard data as a tech founder to make sure you have set up a dashboard with analytics that tracks your main KPI. And again, here, choose technology for your analytics stack for speed. Keep it super simple; something like Google Analytics, Amplitude, Mixpanel—don't go overboard with something super complex like Logstash, Prometheus.

These are great for large companies, but not at your stage. You don’t have that load. Again, use soft data—keep talking to users after you launch and marry these two to know why users stay or churn and ask to figure out what new problems your users have to iterate and build.

WePay, another YC company, when they launched, they were a B2C payments product, kind of a little bit like Venmo-ish. But the thing is, it never really took off. They iterated. So in terms of analytics, they saw some of the features that we're launching, like messaging—nobody cared; nobody used it.

They found out, in terms of a lot of the payments, their biggest user was GoFundMe back then. They also talked to users; they talked to GoFundMe, who didn't care for any of this B2C UI stuff—they just cared to get the payments.

Then they discovered a better opportunity to be an API and basically pivoted into it, and they got the first version. And again, applying the principles that did a scale, they didn't even have technical docs, and they worked with GoFundMe to get this version, and this API version was the one that actually took off and got them to product-market fit.

Principle number two in the launch stage is to continuously launch. A perfect example of this is Segment, who started as a very different product. They were classroom analytics. Similar stories, they struggled with this first idea; it didn't really work out until they launched a stripped-down version of just their back end, which was actually Segment.

See the impressive number of launches they did. Their very first launch was back in December 2012. That was their very first post, and you saw the engagement on Hacker News very high—that was a bit of a hint of a product-market fit, and they got excited and they pivoted into this and kept launching every week.

They had a total of five launches in a span of a month or so, and they kept adding features and iterating. They added support for more things. When they launched, it only supported Google Analytics, Mixpanel, and Intercom. By listening to the users, they added Node, PHP support, and WordPress. It kept on going, and it took them to be then a unicorn that eventually had an exit to Twilio for over three billion dollars—pretty impressive too.

Now the last principle here, what I want to say for when you're launching: there's this funny state where you have tech builds; you want to balance building versus fixing. You want to make thoughtful choices between fixing bugs or adding new features or addressing technical debt.

I want to say technical debt is totally fine. You've got to get comfortable a little bit with the heat of your tech burning—totally okay. You're going to fear the right things, and that is towards getting you product-market fit. Sometimes that tiny bug in rendering maybe is not critical for you at this point to fix. Like, in fact, a lot of early products are very broken.

You're probably very familiar with Pokemon Go when it launched in 2016: nobody could log into the game, and guess what? That did not kill the company at all. In fact, to this day, Pokemon, I think last year, made over a billion dollars in revenue. That did not kill them.

And I'll give a little background to what was happening on the tech: it was very straightforward. They had a load balancer that was on Google Cloud, and they had a back-end, and they had a TCP termination and HTTP requests that were done with their NGINX to route to the different servers that were the AFE, the application front end, to manage all the requests.

The issue with there was that, as users were connected, they didn't get terminated until they got to the NGINX. As a result, the client also had retries, and that what happened was you had such a huge load that, in fact, I think Pokemon Go, by the first month after launching, they had the same number of active users as Twitter, which took them ten years to get there, and they got there in one month.

Of course, things would break. It was basically a lot of users trying to log in, which was kind of creating a bit of a DDoS attack.

Now, December is a bit on when you launch. Some of the common mistakes after launching, and I myself have made! CTO Doge said it is tempting to build and say, “What would Google do?” That’s almost certainly a trap. You'd try to build like a big company or hire to try to move quickly.

Sometimes, I think this is more of a nuanced question; it can be a mistake. Or the other thing is focusing too much on fixing, refactoring, and not building features towards iterating to product-market fit—not discovering insights from users.

Sometimes I see CTOs like, "Okay, we launched; I get to hunker down and just get into building!" No! Again, your role as a technical founder is very different. You've got to be involved in the journey and really understand the insights of why users stay or leave your products. You have to keep talking to them.

The other mistake I see is like, "Oh, we're just building features for our product," but you also need to build tech to grow. In fact, some of the best growth hacks where engineers pair it up with sales and growth folks who are non-technical.

So now the last section on how the role evolves. So assuming you got product-market fit, what happens? This is this point where you can actually then put on your big engineering pants and figure out pieces of the tech that need to be built to scale. You need to, and the tech will break—which is actually a good thing, breaking because of too much demand, and that's totally okay.

That’s my example from Pokemon Go. You'll find the pieces that need to be reworked, refactor. This is when you do it—not before! Not before product-market fit. You’ll decide also what the engineering culture will look like.

This is a stage where you actually do more of the hiring. Here, you're probably going to evolve from leading a small team of engineers to hiring your first hires who are going to be people that you know. At this point, your role really changes because you'll start having communication overhead, and this is when you realize your role morphs.

Like between two to five, you still get time to code about 70%. When you get to five to ten, you have less than 50%, and beyond ten, you probably won’t really have time to code and have to decide how to structure things and whether you’re going to remain as an architect type of role, or you want to be more of a people role and be more of a VP.

Now, to summarize here the talk:

First stage: Ideating. Build, the goal is to build a prototype as soon as possible, and the principle is build very quickly in a matter of days.

Stage two: You're in the process of building an MVP, which I think a lot of you are in this or the previous one. The goal is to build as quickly to launch in a matter of a few weeks, and the principles are do things that don’t scale, create a 90-10 solution, choose the tech for iteration speed.

The last one is once you launch, all of the previous ideas on a 90-10 solution, doing things that don't scale still apply, and add these onto it. The goal is to get an iteration towards product-market fit. So you're going to also quickly iterate with hard and soft data, with analytics and user interviews.

You're going to continuously launch, and you’re going to find the fine balance between building and fixing, and where tech debt is totally fine. Feel the heat for that tech—that is totally fine.

And if there's only one takeaway from this whole talk, it’s that startups move quickly.

So thank you, everyone!

[Music]