A Success Guide for Technical Founders

This video is a detailed guide on how technical founders can build products and succeed in the early stages of a startup. It provides practical advice on the various challenges technical founders face--from ideation to minimum viable product (MVP) development, launch, and finding product-market fit--including technology selection, technical debt management, and team building. Drawing on the experience of Y Combinator (YC) group partner Diana Hu and case studies from various YC alumni startups, it emphasizes the importance of 'fast execution' and being 'user-centric.'

1. What Does a Technical Founder Do?

Diana Hu, a YC group partner and co-founder/CTO of the augmented reality SDK startup 'Escher Reality' (acquired by Niantic), explains the role of a technical founder based on her experience. She has diverse experience ranging from the idea stage to prototyping, MVP launch, and scaling systems for millions of users. This talk covers three key stages: first, the role of a technical founder and who they are; second, how to develop products at each startup stage (ideation, MVP building, finding product-market fit post-launch); and third, how the technical founder's role changes after product-market fit.

A technical founder is not simply a developer who builds apps--they are an essential partner in the startup journey. Leading product development and constantly communicating with users to gain product insights is critical. In the early stages, you essentially act as the lead developer, handling all technical aspects. You may need to personally manage frontend, backend, DevOps, website, UX, and even IT tasks. For hardware startups, you may need to become familiar with everything from electrical circuits to mechanical components.

The most important thing is to pursue 'good enough' architecture. While perfect architecture may be highly valued at large companies, fast execution and rapid decision-making are far more important at startups.

"At a startup, you should pursue 'good enough' architecture, not perfect architecture. You need to make decisions quickly and move fast, even with incomplete information."

This means being willing to accept technical debt, inefficient processes, and even ugly code. All of this demonstrates a willingness to do whatever it takes for the company's success. The mindset of "that's not my job" does not work at startups.

2. How Should You Build a Product?

2.1. Ideation Stage: Rapid Prototyping

The goal at the idea stage is to build a prototype as quickly as possible and show it to users for demonstration. It does not even need to work perfectly. The CEO co-founder should focus on finding users to show the prototype to. The core principle is to build it extremely quickly, 'within days.'

"Building a prototype in days might seem impossible, but it becomes possible by leveraging prototyping software and drastically simplifying features."

Software companies: Use tools like Figma or Invision to create clickable prototypes.
Developer tool companies: A simple script written in an afternoon and run in a terminal is sufficient.
Hardware companies: Use 3D renderings to show a product's potential. Remora, for example, captured user interest with 3D renderings of a carbon-capture device attached to trucks.

Optimizely applied to YC with a completely different idea, but after realizing it had failed, they built a visual editor prototype in just days. It was a simple JavaScript file on S3 that ran A/B tests manually. Only the founders could use it, but it was enough to show marketers the product's potential. Diana's startup Escher Reality built a prototype running computer vision algorithms on a phone within weeks for an AR technology demo. Demonstration was far more effective than verbal explanation.

Common mistakes:

Over-building: Do not try to build a complete MVP at this stage. Many waste time trying to build too much out of fear that "users won't see our full vision."
Insufficient communication with users: Even if uncomfortable, show users the prototype quickly and listen to feedback.
Attachment to the idea: Be willing to abandon an idea if user feedback is poor.

2.2. MVP Building Stage: Launching a Working Product

Once you have captured user interest with a prototype, it is time to build and launch an actual working MVP. The goal is again to launch very quickly--ideally 'within weeks.' Hardware and deep-tech companies may take longer as an exception. The objective at this stage is to get users to commit to using the product, and ideally, to pay for it.

Should you hire people at this stage? Hiring team members at the early stage can actually slow down your launch. It can take over a month to find good developers, and recruiting is difficult during the uncertain early stages. Moreover, if founders do not build the product themselves, they miss critical insights about the product.

"Hiring people at the early stage can slow down your launch speed and cause you to miss important learning opportunities about the product."

Just like Justin TV and Twitch, the initial MVP was built entirely by the four founders themselves, each serving as a software engineer responsible for their own area. They divided responsibilities across video streaming, databases, and web development to launch quickly. After launch, they did hire good engineers, but they sought out 'outsiders' rather than polished resumes, and these people delivered remarkable results.

Principles for building an MVP:

Do things that don't scale: As Paul Graham's famous essay states, launch quickly using clever methods.
- Avoid: Automated onboarding, scalable backends, automated scripts (needed later, but not now).
- Key hacks: Manually onboarding users, directly editing the database, founders personally handling customer support.
- Stripe's early version provided an API for developers to send payments, but behind the scenes the founders manually processed every request and filled out bank forms to handle payments. This was enough for a quick launch.
Build a 90/10 solution: A term coined by YC partner and Gmail developer Paul Buchheit, meaning you don't need to be perfect from the start. Code will likely be rewritten later, and that is fine. Defer as many features as possible until after launch.
- This does not mean building a buggy product, but rather constraining the product to work within a limited scope (e.g., specific use cases, data types, features, user types, device counts, geographic locations).
- DoorDash's initial version was built in an afternoon--a static HTML/CSS website with just PDF menus and one founder's phone number. The backend used Google Forms and Google Docs to coordinate orders, and driver tracking used the 'Find My Friends' app. Since the founders were Stanford students, limiting service to the Palo Alto area was key. This allowed them to accurately understand delivery and unit economics before scaling up significantly. By contrast, competitor GrubHub started in major cities and found operations more difficult.

2.3. Technology Stack Selection: Iteration Speed Is Key

When choosing a technology stack, you should balance product characteristics with founder expertise and choose what enables the fastest launch. Do not choose a 'cool' new programming language just to learn it. What matters is choosing something familiar that enables rapid development.

"The key to tech stack selection is iteration speed. Choose the technology that lets you build products most quickly and efficiently right now."

Today, leveraging various third-party frameworks and API tools makes it possible to build MVPs very quickly.

Authentication: Auth0
Payments: Stripe
Cross-platform: React Native
Cloud infrastructure: AWS, GCP
Landing pages: Webflow
Backend serverless: Lambda, Firebase
Hosted databases

In the past, many companies ran out of funding before launch because they built everything from scratch. That is no longer necessary. Arguments that "third-party APIs are too expensive or slow" are not relevant at the early startup stage.

As a fun meme shared by Sean Wang illustrates, choosing 'everyone uses it' technologies like PHP or JavaScript can be the wise choice. Mid-level developers try to build complex, scalable systems like Google with Kafka, Kubernetes, and hundreds of microservices, but average startups fail doing that. In contrast, 'Jedi Master' developers deliberately choose simple tech stacks for rapid development and iteration speed.

"If your company succeeds and gains users, it won't matter much which tech stack you chose. Problems can be solved later."

Facebook was built with PHP, which Mark Zuckerberg was familiar with. Despite PHP's reputation for limited scalability and performance, when Facebook grew to massive scale, they built HipHop, a custom transpiler that compiled PHP to C++ for performance optimization. WayUp's CTO JJ had no formal computer science education but chose Django and Python for rapid development. While Ruby on Rails was more popular in 2015, Django and Python were the right choice for his iteration speed, and this did not hinder the company's success at all.

In conclusion, technology choices only matter for parts directly connected to customer commitments. For Escher Reality, API-level compatibility with Unity and game engines was maintained, but most other code was rewritten and discarded multiple times during scaling. What mattered was delivering core customer value.

3. Launch Stage: Iterating Toward Product-Market Fit

Once you have built and launched the MVP, the goal is to iteratively improve to find product-market fit.

3.1. Rapid Iteration Using Hard Data and Soft Data

Hard data: As a technical founder, you need to build dashboards and analytics systems tracking core KPIs. Start quickly with simple analytics tools like Google Analytics, Amplitude, or Mixpanel. Complex systems like Logstash and Prometheus are suited for large companies and are excessive for early-stage startups.
Soft data: You must continue talking to users even after launch. Combine hard data and soft data to understand why users stay or churn, and discover new pain points to improve the product.

WePay initially launched as a B2C payment product but failed. Analytics data revealed that most users were GoFundMe, and nobody used features like messaging. Through conversations with GoFundMe, they learned that GoFundMe had no interest in the B2C UI and only needed a payment API, so they pivoted to a B2B API. Applying the do-things-that-don't-scale principle, they launched the first API version in collaboration with GoFundMe without even having technical documentation, and this became the catalyst for finding product-market fit.

3.2. Continuous Launching

Segment initially started with a completely different product--classroom analytics--but failed. They extracted just the backend functionality and relaunched as 'Segment,' which received enormous response. The initial launch post generated extremely high engagement on Hacker News, hinting at product-market fit. Excited, they focused on this idea and continuously launched by adding new features weekly. Initially supporting only Google Analytics, Mixpanel, and Intercom, they listened to users and added Node, PHP, and WordPress support, among other improvements. As a result, Segment grew into a unicorn company, acquired by Twilio for over $3 billion.

3.3. Balancing Building vs. Fixing

During the launch stage, you need to maintain a wise balance between adding new features and fixing bugs or addressing technical debt.

"Tech debt is completely fine. You need to get comfortable with the discomfort of your technology being on fire. What matters is moving toward product-market fit."

Small rendering bugs may not need immediate fixing. Early products are often very unstable. Pokemon Go had severe login issues at its 2016 launch, but this was not fatal to the company. In fact, within a month of launch, it achieved the active user count that Twitter took 10 years to reach, and it generated billions of dollars in revenue the following year. The technical issues at the time were caused by unexpectedly massive user traffic.

Common post-launch mistakes:

Building like "What would Google do?": This is a trap. Do not try to build like a large corporation.
Hiring for speed: Hiring in the early stage can actually slow things down.
Too much refactoring and bug fixing: Do not focus on refactoring over feature development for product-market fit.
Ignoring user insights: Technical founders must continue communicating with users post-launch to understand why users adopt or abandon the product.
Focusing only on product features: Technology development for growth is also important. Engineers should collaborate with non-technical sales and growth teams to create growth hacks.

4. How the Technical Founder's Role Changes After Product-Market Fit

Once you have achieved product-market fit, it is finally time to deploy 'real' engineering capabilities.

Technology will start 'breaking' from excessive demand. This is a good sign, and as with Pokemon Go, it is okay.
Only now can you decide and execute on which parts of the tech stack to rework and refactor. Do not do this before achieving product-market fit.
You can begin building an engineering culture.
Hiring ramps up during this period. Initially, you hire through personal networks, gradually lead a small engineering team, and then hire more people.
Your role changes dramatically. Initially, you spend 70%+ on coding, but as the team grows to 5-10 people, coding drops below 50%, and with 10+ people, you have almost no time to code. At this point, you must decide whether to maintain an architect role or take on a leadership role (VP of Engineering, etc.).

Conclusion

Success as a technical founder depends on fast execution and iteration. In the idea stage, build a prototype in days; in the MVP stage, launch a working product within weeks. Throughout this process, do things that don't scale, build 90/10 solutions, and choose a tech stack that prioritizes iteration speed. After launch, combine hard data and soft data to relentlessly improve in pursuit of product-market fit, embrace technical debt without fear, and maintain a balance between building and fixing. Ultimately, the core of a startup is 'moving fast.'