- The speaker is Diana Hu, a group partner at YC and former co-founder and CTO of Azure Reality.
- The talk will cover the role of the technical founder, building in different stages, and the evolution of the technical founder's role.
- A technical founder is a partner in the startup journey and is responsible for building the product and interacting with users.
- The role of the technical founder in the early stages is similar to being a lead developer but with additional responsibilities.
- The ideating stage involves quickly building a prototype to show and demo to users.
- Building an MVP is the next stage, with the goal of getting user commitment, ideally through payment.
- Hiring at this stage may slow down the launch process and hinder the development of product insights.

- Building a product with founders allows for key insights and learning about the technology
- Hiring engineers can be done later, but finding misfit engineers can be beneficial
- Launch quickly by doing things that don't scale, such as manual onboarding and personalized support
- Create a 90-10 solution for the initial version and focus on limited dimensions
- Choose a tech stack that balances product needs and personal expertise for quick iteration
- Utilize third-party frameworks and APIs to save time and money
- Tech choices don't matter as much if the company is successful and can solve its way out
- The only tech choices that matter are those tied to customer promises
- In the launch stage, iterate quickly with hard and soft data to achieve product-market fit.

- Principle 1: Use hard data (analytics) and soft data (user feedback) to iterate quickly.
- WePay and Segment are examples of companies that iterated and pivoted based on data and user feedback.
- Principle 2: Continuously launch and iterate based on user feedback.
- Pokemon Go's launch had technical issues but didn't hinder its success.
- Common mistakes after launching include focusing too much on building or fixing without iterating based on user insights.
- Once product-market fit is achieved, the role of the technical founder evolves to include scaling the tech and hiring.
- The talk emphasizes the importance of moving quickly in startups.

- Diana Hu, a group partner at YC and former co-founder and CTO of Azure Reality, discusses the role of the technical founder and the stages of building a startup.
- The technical founder is responsible for building the product and interacting with users, with additional responsibilities in the early stages.
- The ideating stage involves quickly building a prototype, followed by building an MVP to gain user commitment.
- Hiring at this stage may slow down the launch process and hinder product insights.
- Launching quickly and focusing on limited dimensions are key strategies, as well as utilizing third-party frameworks and APIs.
- Tech choices are less important than solving customer promises.
- Iterating quickly based on hard data (analytics) and soft data (user feedback) is crucial for achieving product-market fit.
- Once product-market fit is achieved, the technical founder's role evolves to include scaling the tech and hiring.
- Moving quickly is emphasized as important in startups.

YC Group Partner Diana Hu was the CTO of her YC startup Escher Reality, which was acquired by Niantic (makers of Pokemon Go). She shares her advice for being a technical founder at the earliest stages - including topics like how to ship an MVP fast, how to deal with technology choices and technical debt, and how and when to hire an engineering team.

Apply to Y Combinator: https://yc.link/SUS-apply
Work at a startup: https://yc.link/SUS-jobs

Chapters (Powered by https://bit.ly/chapterme-yc) - 
00:00 - Intro
00:09 - How to Build and Perpetuate as a Technical Founder
01:56 - What Does a Technical Founder Do?
04:38 - How To Build
08:30 - Build an MVP: The Startup Process
11:29 - Principles for Building Your MVP
15:04 - Choose the Tech Stack That Makes Sense for Your Startup
19:43 - What Happens In The Launch Stage?
22:43 - When You Launch: The Right Way to Build Tech
25:36 - How the role evolved from ideating to hiring
26:51 - Summary
27:59 - Outro

Welcome everyone to how to build and succeed as a technical founder for the startup school talk.

And previously, I was a co-founder and CTO for Azure Reality, which was a startup building augmented reality SDK for game developers.

And 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 just an idea to then a prototype, to launching an MVP, which is like a bit duct tapey, to then scaling it and getting to product market fit and scaling systems to millions of users.

So what are we gonna cover in this talk is 3 stages.

First is what is the role of the technical founder and who are they?

Number 2, how do you build in each of the different stages where all of you are in startup school?

Ideating, which is just an idea, 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 evolves.

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.

Sometimes I hear Non-technical founders say, I need somebody to build my app.

A technical founder is a partner in this whole journey of a startup, and it requires really intense level of commitment.

They lead a lot of the building of the product, of course, and also talking with users.

And sometimes I get the question of who is the CEO or CTO for a technical founder.

It really depends on the type of product, the industry you're in, the complete scale composition of the team to figure out who the CEO or CTO is.

And I've seen technical founders be the CEO, the CTO, or various other roles.

And what does the role of the technical founder look like in the early stages?

It looks a lot like being a lead developer.

Like if you've been a lead developer at a company, you were in charge of putting the project together and building it and getting it out to the finish line.

Or 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.

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 you'll of course, as part of doing all the tech things, you'll have to talk with users to really get those insights to iterate.

And 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 bias towards action and moving quickly and 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.

And 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.

And 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.

The first stage is the ideating stage, where you just have an idea of what you want to build.

And 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.

In parallel, your CEO, co-founder will be finding a list of users in these next couple of days to tee at meetings to show the prototype when it's ready.

So the principle here is to build very quickly in a matter of days.

And sometimes I hear it's like, oh, Diana, a day prototype.

And 1 way of doing it is building on top of a lot of prototyping software.

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.

And 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 their 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 on winter 10, and they put this prototype literally in a couple of days.

And 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 Obava campaign.

And he recalled that he was called to optimize 1 of the funding pages and thought, huh, this could be a startup.

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 run 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.

Other example is my startup, Azure Reality.

Since we're building more harder tech, we had to get computer vision algorithms running on phones.

That was a lot easier to show a demo of what AR is, as you saw on the video, than just explaining and hand-waving, and 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.

This is a mistake when founders think you need a full MVP on the stage, and not really.

The other mistake is obviously not talking or listening to users soon enough.

Like you're gonna get uncomfortable and show this kind of prototype-y, duct tape-y thing that you just slapped together.

And that's okay, you're gonna get feedback.

The other 1 at the stage, as an example for Optimizely, when founders get too attached to idea, the feedback from users is somewhat obvious that it's not quite there, not something that users want, and it's not letting go of bad ideas.

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.

And the goal is basically build it to launch and it should be done also very quickly, ideally in a matter of can be done in a few days, 2 weeks or sometimes months, but ideally more in 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.

And ideally, what that commitment looks like is getting them to pay.

And 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.

It's like, oh, I showed this prototype, people are excited and there's so much to build, is hiring a good idea.

The first instinct is like, okay, I got this prototype, got people excited, I'm gonna hire people to help me to build it.

As a first time founder, it's like, oh my God, oh my God, there's a fit, people want it.

It's gonna 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.

And it's hard to find people at this stage, where it's very nebulous and chaotic.

And 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 think you can hire a bit later when you have things more built out, but at this stage is still difficult.

Justin.tv and Twitch, it was just the 4 founders and 3 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'd become an awesome fearless engineer tackling the hard problems of video streaming, and then Emmett doing all the database work, Justin with the web, And that was enough to get it to launch.

After they launched, they did hire good engineers.

But the key thing about this, they were very good at not caring about the resume.

They tried to really find the misfits, engineers that Google Overlooked, and those turned out to be amazing.

So Amon and Gilem were very comfortable and awesome engineers, and they took on a lot of the video web in just 3 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 1 is the classic Paul Graham 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 sounds great at some point, but not the stage.

And 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 to your thing is insane custom support.

It's just you, the founders at the frontline doing the work.

Doing things that don't scale, A classic example is with Stripe.

They had the API for developers to send payments.

But on the back end, the thing that did not scale, it was literally the founders processing every manual request and filling bank forms to process the payments at the beginning.

And that was good enough to get them to launch sooner.

Now, principle number 2, this is famous create 90 test solution that was coined by Paul Bukite, who was 1 of the group partners here at YC and original inventor of Gmail.

The first version is not going to be the final, remember.

And it will very likely a lot of the code be rewritten.

Push off as many features to post-launch.

And by launching quickly, I created a 90-10 solution.

But you want to restrict the product to work on limited dimensions, which could be like situations, type of data you handle, functionality, type of users you support, could be the type of data, the type number of devices, or 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 like lawyers and finance teams and sales teams that make you kind of just move slow.

So I'll give you a couple of examples here.

DoorDash, at the beginning, they slapped it in 1 afternoon and they were actually called Palo Alto delivery.

And they took PDFs from menus and literally put their phone number.

That phone number there is actually from 1 of the founders.

It's literally just plain HTML and CSS and PDF.

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.

And they didn't even build anything to track all the drivers or ETA.

They did that with using fancy on your iPhone, find my friends to track where each of the deliveries were, that was enough.

So this was put together literally in 1 afternoon and they were able to launch.

The very genius thing they did is that 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 made them, now you saw how the story played out, the unit economics and the ops was much harder and they 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?

So 1 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.

I mean now, and the other thing is also, it's very easy to build MVPs very quickly by using third-party frameworks and API tools.

And you don't need to do a lot of those work.

For example, authentication, you have things like Auth0, payments, you have Stripe, cross-platform support and rendering, you have things like React Native, cloud infrastructure, you have AWS, GCP, landing pages, you have Webflow, backend, serverless, you have Lambdas or Firebase or hosted database.

In the past, startups would run out of money before even launching because they had to build everything from scratch and ship for metal.

Don't just try to be the kind of cool engineer, just build things from scratch.

But I know CTOs tell me, oh, it's too expensive to use this third party APIs, or it's too slow with this skill to use XYZ.

So what I'm going to say to this, I mean, there's 2 sides of the story with using third party.

I mean, to move quickly, but it doesn't mean this.

This is a great meme that Sean Wong, who's the head of developer experience at AirByte, 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.

Series engineers make fun of the new 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, blah.

And then the middle or average or mid-width engineer is like, OK, I'm going to put my big engineer pants and do what Google would do and build something optimal and scalable and use something for the back end like Kafka, Linker, Rust, IMA, Prometheus, Kubernetes, Envoy, Big Red, or hundreds of microservices.

Another funny thing, you got the Jedi master.

And when you squint, their solutions look the same like the new 1.

But they choose it for different reasons, not because they just learned it, but they recognize this is because they can move a lot quicker.

And what I'm gonna 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.

Like Facebook famously was built on PHP because Mark was very familiar with that.

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 compound C++ so that it would optimize.

And even for JavaScript, there's a V8 engine, which makes it pretty performant.

WayUp was a 2015 company at YC that helps companies hire diverse companies and is a job board for college students.

So JJ, the CTO, although he didn't formally study computer science or engineering at UPenn, he did taught himself how to program and freelance for a couple years before he started WayUp.

And JJ chose, again, as a Jedi Master, chose technology for iteration speed.

He chose Django and Python, although a lot of other peers were telling him to go and use Ruby and Rails.

And I think in 2015, Ruby and Rails were 10 times more popular by Google Trends.

I mean, that was the right choice for them, because you could move quickly and get this out of the door very quickly.

I kept it simple in the backend, Postgres, Python, Heroku, and that worked out well for them.

The only tech choices that matter are the ones tied to your customer promises.

For example, at Escher, we in fact rewrote and threw away a lot of the code multiple times as we scale 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.

Your goal here in the launch stage is to iterate, to get towards product market fit.

So principle Number 1 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.

And don't go overboard with something super complex like Logstash, Prometheus.

These are great for large companies, but not at your stage.

Again, use soft data by keep talking to users after you launch and marry these 2 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 that it never really took off.

So in terms of analytics, they saw some of the features that were launching, like messaging, Nobody cared, nobody used.

And they found out in terms of a lot of the payments, their biggest user was GoFundMe back then.

They talked to GoFundMe, who didn't care for any of this B2C UI stuff.

And 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 1 that actually took off and got them to product market fit.

Principle number 2 in this launch stage is to continuously launch.

Perfect example of this is Segment, who started as a very different product.

Similar story, they struggled with this first idea, didn't really work out until they launched a stripped out version of just their backend, which was actually segment and see the impressive number of launches they did.

Their very first launch was back in December 2012.

And you saw that engagement in 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 5 launches in a span of a month or so.

And they kept adding features and iterating.

When they launched, it only supported Google Analytics, Mixpanel, and Intercom.

And by listening to the users, they added Node, PHP support, and WordPress, and it kept on going.

And it took them to be then a unicorn that eventually had an exit to Twilio for over $3 billion.

Now, the last principle here, what I wanna say for when you launch, There's this funny state where you have tech built.

So you want to balance building versus fixing.

You want to make thoughtful choices between fixing bugs or adding new features or addressing technical debt.

And what I want to say, tech debt is totally fine.

You've got to get comfortable a little bit with that heat of your tech burning.

See all Y Combinator transcripts on Youtube

Tips For Technical Startup Founders | Startup School