Should startups build every feature to work at full scale from day one, or ship for today's customers and refactor later?

Paul Graham · published Mar 2005

The only way to make something customers want is rapid prototyping — get a version 1 in front of users early and refine it — rather than elaborately planning a product before building it.

Initial plans in a startup are almost certain to be wrong, and the only way to find out where is to try implementing them; the 'Hail Mary' approach of a year of planned development yields something no one wants.

Scope: software for a startup, not every program

source How to Start a Startup

Geoff Charles · published Dec 6, 2023

Product building is like distance running: you won't get the first product right, but repetition and consistent daily work compound into great outcomes

Both are long, metrics-oriented, and built out of short cycles (two-week sprints as the equivalent of training runs) that compound over time

46:28 20VC: Ramp's Product Playbook: How To Hire Product Teams, How to Run Sprints, How to Increase Product Velocity, When and How to Go Multi-Product with Geoff Charles, VP Product @ Ramp

Tom Blomfield · published May 13, 2024

The most common mistake founders make in the batch is not launching early enough because they are afraid to ship something and iterate

27:04 20VC: Behind the Scenes at Y Combinator: The Interview Process | What the Best & Worst Do in the Program | Do the Best All Raise Pre-Demo Day & YC's Fundraising Advice to Startups | Why the Value is in Application Layer AI with Tom Blomfield

Harry Stebbings · published May 13, 2024

The argument that scarce consumer attention makes launching an imperfect product a mistake is wrong

He disagreed with the tweet claiming that a user who churns on an imperfect first experience can never be won back

27:10 20VC: Behind the Scenes at Y Combinator: The Interview Process | What the Best & Worst Do in the Program | Do the Best All Raise Pre-Demo Day & YC's Fundraising Advice to Startups | Why the Value is in Application Layer AI with Tom Blomfield

Harry Stebbings · published Aug 14, 2024

Creators should not be afraid to ship v1 even if it's bad, because v2 and v3 will be better.

His own first podcast episodes were terrible and he grew, learned and developed by publishing them.

Scope: drawn from content creation rather than software

5:59 20VC: Lessons from Mark Zuckerberg, Keith Rabois & Tobi Lütke | Why Remote is a Bad Idea for 90% of Companies | The Framework for How Shopify Builds Product Today | What Humans Get Wrong About Marriage and Kids with Kaz Nejatian, COO @ Shopify

Aman Narang · published Aug 21, 2024

Speed matters enormously in business, and people wrongly optimize for getting things exactly right instead

Moving fast lets you iterate and pivot quickly when something doesn't work; Toast wouldn't exist if the first product had taken two years to reach customers

7:58 20VC: Five Lessons Scaling Toast to $14BN Market Cap | The Biggest Mistakes Founders Make in Fundraising, Hiring and Selling with Aman Narang, CEO @ Toast

Matteo Franceschetti · published Nov 20, 2023

Validation timelines collapse if you lower the certainty requirement — 80% certainty in three days beats 100% certainty in a month

Following the Elon algorithm of simplifying and deleting requirements; once the team dropped the demand for full certainty they found a way to validate in days

36:09 20VC: The Ultimate Hiring Playbook: Five Questions to Ask Every New Hire | What Makes Truly Great Leaders and How They Give Feedback | Do VCs Really Add Value; Lessons from Hard Fundraises with Matteo Franceschetti, Co-Founder @ Eight Sleep

Matteo Franceschetti · published Nov 20, 2023

The point of velocity is not speed for its own sake but learning as fast as possible so you can adjust as fast as possible

Because you can't know everything up front, the value of moving fast is compressing the learning loop; long rigid roadmaps defeat this

38:04 20VC: The Ultimate Hiring Playbook: Five Questions to Ask Every New Hire | What Makes Truly Great Leaders and How They Give Feedback | Do VCs Really Add Value; Lessons from Hard Fundraises with Matteo Franceschetti, Co-Founder @ Eight Sleep

Jeff Seibert · published Nov 22, 2023

Speed of product cadence is critical, and companies fatally default to waiting for more data and statistically significant results

At Twitter stat-sig data always took two to three weeks plus analysis time, which is a disaster for progress

6:58 20VC: Why OpenAI Will Become an Infrastructure Play, Why Apple Will Win in an AI World, Why Google is the Most Vulnerable Incumbent, Will LLMs Be Commoditised, Which Startups Are Thin vs Thick Wrappers on Top of LLMs with Jeff Seibert, Founder @ Digits

Stephane Kurgan · published Jul 28, 2023

Companies that take six to ten weeks to ship a minor feature iteration are far too slow; today you need to ship, test and iterate within days

Fast iteration cycles are what let you learn whether something works and move on; month-long cycles are no longer affordable

25:16 20VC: Four Criteria to Assess Great Founders, Why and How the Best Leaders Make the Wrong Decisions 40% of the Time, Lessons Scaling King from 100 Employees to 2,400 and Making $1BN of EBITDA with Stephane Kurgan, Venture Partner @ Index Ventures

Harry Stebbings · published Jun 27, 2026

Companies today have to ship faster than ever before

16:42 20VC: How We Got Fred Wilson, Benchmark and Index to Invest $94M | Why Robinhood's Strategy is Wrong | Why 1-1s are BS and What Every Founder Gets Wrong About Equity | Why Taste Beats AI But How AI Kills Org Charts with Paul Erlanger, CEO @ fomo

Paul Erlanger · published Jun 27, 2026

Shipping speed is now forced: the tooling makes it possible and competitors are already doing it

Because you can, and everyone else is

16:44 20VC: How We Got Fred Wilson, Benchmark and Index to Invest $94M | Why Robinhood's Strategy is Wrong | Why 1-1s are BS and What Every Founder Gets Wrong About Equity | Why Taste Beats AI But How AI Kills Org Charts with Paul Erlanger, CEO @ fomo

Paul Graham · published Mar 2024

A version one of a site like Reddit needs only a couple hundred lines of code, so founders should be able to launch within a week or two.

Graham pushed the Reddits to launch fast on the grounds that such a small build couldn't take longer.

Scope: about version one, not a mature product

source The Reddits

Max Junestrand · published Aug 15, 2025

Founders should go extremely deep on a problem space and then use cheap prototyping to get an early product to a few clients and iterate, rather than building scalable infrastructure first

The cost of building software has fallen so fast that you can prototype quickly; depth in the industry is what tells you what to build

Scope: applies to early-stage engineering founders

72:29 20VC: 15 Term Sheets in 7 Days and Choosing Benchmark | Harvey vs Legora: Who Wins Legal and How to Play When You Have $600M Less Funding | Are AI Models Plateauing Today | Building a 9-9-6 Culture From Stockholm with Max Junestrand

Zach Lloyd · published Oct 17, 2025

In startups, speed is everything, and early-stage engineers over-invest in engineering beauty instead of building something people want to use

Engineers from big-scale environments get anchored on perfecting engineering; if no one cares about the product, a 30% performance gain won't change that

Scope: about the beginning of a company

6:23 20VC: The Startup Adding $1M ARR Every Week | Competing Against OpenAI's Codex and Claude Code: Who Wins | Why Gemini is Failing and GPT-5 Is Winning | Do Margins Matter in a World of AI | The Ugly Truth About AI Coding with Zach Lloyd, Warp

Parker Conrad · published Oct 3, 2022

There is no real trade-off between speed and quality; speed is more often aligned with quality than opposed to it

It's rare to see slow-moving projects nail it at the finish line — usually they're slow and also bad; urgency about fixing underlying issues is a virtue and being lackadaisical about them doesn't produce higher quality

Scope: acknowledges it is possible to do things fast and bad

11:01 20VC: Rippling's Parker Conrad on The Four Main Benefits From Building a Compound Startup | Why There Should Never Be a Trade-Off Between Speed and Quality | How Zenefits Gave Parker a Chip on the Shoulder and Why That is so Important?

Kevin Niparko · published Sep 29, 2023

Speed and quality are not really a trade-off; shipping faster is a key unlock for higher quality

The faster you ship, the faster you learn all the ways you were wrong and how to make it right — reality, customers and procurement teams are unforgiving

6:49 20Product: Why Product Memes Are More Important Than a Product Roadmap, Why Writing is the Essential Skill for Product People, How AI Changes The Role of Product, Big Mistakes Founders Make When Hiring Product Teams with Kevin Niparko, VP Product @ Twilio

Harry Stebbings · published Sep 29, 2023

Products that take a long time are rarely perfect because of the extra time; you learn more by shipping

7:26 20Product: Why Product Memes Are More Important Than a Product Roadmap, Why Writing is the Essential Skill for Product People, How AI Changes The Role of Product, Big Mistakes Founders Make When Hiring Product Teams with Kevin Niparko, VP Product @ Twilio

Fabien Pinckaers · published Feb 12, 2025

Building the entire product suite up front was risky but is the reason Odoo works today

It delayed monetization and salable product, but designing the big picture at once means everything is smooth and integrated rather than a patchwork of separate software

Scope: risk: two years before anything could be sold; judgment made in hindsight

8:01 20VC: The $5BN Company Built from the Belgian Countryside | The Story of Odoo: The Company with No Plans to Sell, IPO & Their Billionaire Founder Who Does Not Care About Money with Fabien Pinckaers, Founder & CEO @ Odoo

Jason James · published Aug 29, 2025

You cannot run an MVP approach on a breadth-first product; a broad, full-life-cycle product requires a full build before going to market

With a dozen surface areas it's very hard to get everything to a sufficient quality level, so shipping an MVP-quality broad product underdelivers

Scope: drawn from building Daisy v1; they should have delayed going to market by six months to raise quality

14:03 20Product: Why Most CPOs are Bad | Why You Do Not Need PMs in a World of AI | Why the Design Stage is Dead and How to Use Vibe Coding to Replace It | The Three Roles All Founders End Up Firing on Repeat with Jason James @ Tezi

Noah Desai Weiss · published Jun 16, 2023

The right way to test a big new product idea is to build a deliberately rough, ugly, unpolished internal prototype first and see if colleagues find it genuinely exciting before investing in refinement, polish, scaling and performance work

It surfaces whether the idea could change how people work before you spend on making it good, and you can then progressively scale it and watch daily/weekly retention and depth of usage

Scope: described as Slack's own playbook

32:52 20Product: Slack CPO Noah Weiss on How to Master Product-Led-Growth, The Biggest Mistakes Founders Make When Scaling Into Enterprise & What Needs to Change with your Product, Team and Processes when Scaling From PLG to Enterprise

Max Levchin · published Feb 5, 2025

The right MVP practice is to ship rough prototypes for signal, then pull the product down and rebuild it properly once the data shows traction

You need cheap customer feedback to learn whether a crazy idea has odds of success, but leaving the rough version live means someone will build a better version if you don't

29:44 20VC: Affirm Max Levchin on Why Grading Talent by Letter (A or B) is Total BS | How to Create a Culture of Post Mortems and Writing | Why You Should Only Study Failure Not Success & The Biggest Surprises Scaling to $18.7BN Market Cap

Alex Bouaziz · published Feb 1, 2023

Global compliance is the one area where you must deliberately go slow to go fast, and doing it carefully is what gave Deel its edge

Compliance isn't just a UI for hiring — you must get onboarding, complaints, termination and overtime right in each country, and countries like France are extremely complicated; once it's figured out you can move fast again

Scope: applies to product and operational infrastructure rollout, not sales

9:21 20VC: From $57M in ARR to $297M in Just 12 Months; Why Speed of Execution is the Most Important Factor to Success, Hiring 2,000 People in 3 Years Remotely & Secondaries; Why, When and How Much To Take Out with Alex Bouaziz, Co-Founder & CEO @ Deel

Kevin Ryan · published Apr 10, 2024

Speed is not the most important determinant of reaching product-market fit; the product has to be genuinely good, which in some categories requires going slower

MongoDB had no revenue after three years because the database had to work, scale and be secure, whereas consumer apps can afford mistakes

Scope: you still need to ship reasonably quickly; varies by category — infrastructure vs consumer

27:04 20VC: Are the Best CEOs the Best Fundraisers, Are the Best Founders Insiders or Outsiders to a Problem, Why Ownership Should Not Be a Focus in VC & The Biggest Lessons Scaling MongoDB to $26BN Market Cap with Kevin Ryan, Founder @ AlleyCorp

Julio Vasconcellos · published Sep 23, 2022

Prefer's core mistake was iterating too fast and not giving each product version enough time; he should have listened more to Scott Belsky's craftsman approach

The move-fast-and-break-things mindset that worked at Facebook and Peixe Urbano landed them too far on the rough side of the spectrum, so tests never got a fair run

18:36 20VC: Why Greed is the #1 Enemy of Venture Returns, Why Not Enough VCs Play to Win and Lessons from Scaling to $100M and 1,200 Employees and Then Cratering with Julio Vasconcellos, Founder @ Atlantico

Matteo Franceschetti · published Nov 20, 2023 · hedged

Moving fast on the subscription launch cost them: with more testing beforehand it could have been more sophisticated and launched a month earlier in better shape

Scope: single example

39:00 20VC: The Ultimate Hiring Playbook: Five Questions to Ask Every New Hire | What Makes Truly Great Leaders and How They Give Feedback | Do VCs Really Add Value; Lessons from Hard Fundraises with Matteo Franceschetti, Co-Founder @ Eight Sleep

Anton Osika · published Aug 18, 2025

Great brand comes from obsessing over details even at the cost of moving slowly, as Apple does, because that is what builds user trust

Apple's detail obsession slows them down but builds trust and a very strong brand; Lovable aims for the same in how it rolls out rapid product changes

9:31 20VC: Lovable CEO Anton Osika on $120M in ARR in 7 Months | The Honest Truth About Defensibility and Unit Economics for AI Startups | The State of Foundation Models: Long Grok, Short OpenAI, Why | Replit vs Lovable vs Bolt: What Happens

Anton Osika · published Aug 18, 2025

Once you have clear product-market fit and a brand to defend, you can't run on short-term patching; you must invest in a high-quality foundation you can build faster upon

With a brand to defend you can't afford failures, so you need to spend time rearranging the organization and the product to maintain quality and enable faster future building

Scope: Short-term sprints to move fast and innovate are still acceptable; Conditional on having clear PMF and a brand to defend

44:52 20VC: Lovable CEO Anton Osika on $120M in ARR in 7 Months | The Honest Truth About Defensibility and Unit Economics for AI Startups | The State of Foundation Models: Long Grok, Short OpenAI, Why | Replit vs Lovable vs Bolt: What Happens

Harry Stebbings · published Oct 3, 2022

In the interviewer's own stated view, speed of execution is the only thing that matters — better to get something 80% done than 99% perfect

10:45 20VC: Rippling's Parker Conrad on The Four Main Benefits From Building a Compound Startup | Why There Should Never Be a Trade-Off Between Speed and Quality | How Zenefits Gave Parker a Chip on the Shoulder and Why That is so Important?

Matteo Franceschetti · published Nov 20, 2023

Speed of execution is as important as everyone says, provided quality is not compromised — and he would take an 80% version today over a 90% version in a week

Quality means clearing a threshold, not perfection; ship at 85% and improve daily to 100%, rather than shipping something shitty that damages the brand

Scope: quality must clear a defined threshold; requires simplifying the requirements

33:33 20VC: The Ultimate Hiring Playbook: Five Questions to Ask Every New Hire | What Makes Truly Great Leaders and How They Give Feedback | Do VCs Really Add Value; Lessons from Hard Fundraises with Matteo Franceschetti, Co-Founder @ Eight Sleep

Cliff Obrecht · published Jan 27, 2023

When accumulated front-end tech debt makes a codebase untenable, a full rewrite can be necessary even at the cost of shipping no features for two years

They analysed rebuilding component by component and it wouldn't work; the team couldn't scale while the user base was scaling massively, and the rewrite ultimately gave them faster product velocity than anyone else

Scope: was planned as one year and took two; described as a death march and a dark time for a shipping-oriented culture

23:32 20VC: Canva Co-Founder, Cliff Obrecht on The Journey From 100 VC Rejections to a $40BN Company, Why Good Enough is Not Good Enough, The Secret to Hiring Non-Obvious Talent and Relationships to Money and Why They Are Giving Away Billions

Zach Lloyd · published Oct 17, 2025

Startup founders should not rewrite their software; rewrites only make sense at extreme scale like a product with 100M+ users

A rewrite is effectively pausing time, and it only pays off when the product is so widely used that perfection matters enough to justify 30-40 engineers for years

Scope: applies to early-stage founders; rewrites justified at 100M+ user scale

4:42 20VC: The Startup Adding $1M ARR Every Week | Competing Against OpenAI's Codex and Claude Code: Who Wins | Why Gemini is Failing and GPT-5 Is Winning | Do Margins Matter in a World of AI | The Ugly Truth About AI Coding with Zach Lloyd, Warp

Zach Lloyd · published Oct 17, 2025

Better advice than rewriting is to pick the right technical foundation at the start, even if it's the harder path

At Warp they built it the hard way initially because they could see that web tech would create performance problems later

Scope: value of good engineering depends on stage of the company

5:25 20VC: The Startup Adding $1M ARR Every Week | Competing Against OpenAI's Codex and Claude Code: Who Wins | Why Gemini is Failing and GPT-5 Is Winning | Do Margins Matter in a World of AI | The Ugly Truth About AI Coding with Zach Lloyd, Warp

Winston Weinberg · published Jan 19, 2026

Most AI application-layer companies are over-hiring front-end engineers and under-investing in infrastructure, which will break them once real usage arrives

Vibe coding works much better for front end than for infra, so teams build pretty UIs and demos that win deals, then can't support hundreds of thousands of users on agentic systems processing tens of millions of documents

Scope: based on scanning their engineers' LinkedIn profiles; Harvey made the same mistake in 2023 and early 2024

32:10 20VC: How Model Performance is Plateauing | Two Key Rules for Effective Deal-Making | Company Building Lessons from Keith Rabois, Brian Halligan and Pat Grady | Why Enterprise AI Adoption is Years Off with Harvey CEO Winston Weinberg

Martin Mignot · published Aug 11, 2025

Dylan Field's years-long delay in launching Figma was a sign of good judgment rather than a red flag, because he understood he needed a minimum feature set to be competitive

It wasn't that he didn't want to launch — he couldn't launch and win without the right feature set, so he kept building for the right reasons

47:13 20VC: Figma, Scale, Wiz: Inside Index's Decacorn Factory | Decision-Making, Investment Process, Biggest Lessons, Biggest Misses | Why Gross Margin is a Fallacy at Seed | Never Turn Down a Deal on Price with Martin Mignot, Partner @ Index Ventures

Max Junestrand · published Aug 15, 2025

Deliberately pausing sales for four months right after raising was the right call, because onboarding top attorneys before the product was ready would have permanently damaged their perception of it

If great attorneys onboard early they'll conclude the product can't meet the standard promised, so it was worth having ice in the stomach and waiting until the product was ready

Scope: required going against investor expectations

35:18 20VC: 15 Term Sheets in 7 Days and Choosing Benchmark | Harvey vs Legora: Who Wins Legal and How to Play When You Have $600M Less Funding | Are AI Models Plateauing Today | Building a 9-9-6 Culture From Stockholm with Max Junestrand

Kaz Nejatian · published Aug 14, 2024

The Lean Startup may have done more unintentional damage to software than any other book, because it is misunderstood by nearly everyone who reads it.

Its misreading has produced a huge amount of bad software shipped into users' hands, which churns people off products; people don't want to be experimented on.

5:04 Lean startup misreading produced a culture of shipping bad software

Kaz Nejatian · published Aug 14, 2024

Shipping a constrained V1 of a real vision is good, but shipping something with zero vision just to see what happens is not how good things get built.

A complete-but-small product can be used and enjoyed, whereas much shipped software today is so incomplete it cannot be used at all; being embarrassed by old work is different from shipping something broken.

6:16 Ship a constrained version of a real vision not a visionless experiment

Jason James · published Aug 29, 2025

Launching a new capability at an A-quality level lets you leave it alone for roughly a year and move on to the next capability, whereas scrappy MVP/beta launches mire the team in fixes and slow down the next needle-moving launch

Time spent repairing half-built features is time not spent building the differentiating next thing

3:37 Invest in a quality launch to avoid repeated rework

Jason James · published Aug 29, 2025

When you already have clarity on what customers want you should just build the full thing in one swing; customer involvement should be inserted mid-development only where you lack certainty

Accumulated customer learning gives varying degrees of clarity, and there are many points in the development journey (design, vibe-coded prototype, limited release) to bring customers in when ambiguity exists

4:35 Build full when clarity exists test with customers only where uncertain

Jason James · published Aug 29, 2025

Whether to build an MVP or a full product should be determined by the thesis you're trying to test and what must be true to validate or invalidate it

Testing whether AI can be a labor capacity addition rather than an efficiency tool for human recruiters requires covering the breadth of a full human role

15:54 Build choice determined by what the thesis must prove

Julio Vasconcellos · published Sep 23, 2022

He now weights product strategy roughly 60/40 toward scrappy iteration over craftsmanship, up from about 90/10, because great design and crafted experiences matter for finding the early nut of product-market fit

The Prefer experience raised his appreciation for the craft side that Scott Belsky always advocated

20:15 Craft and design investment early helps find pmf justifying a balanced speed craft mix

Alex Bouaziz · published Feb 1, 2023

'Deel Speed' means doing things really well really fast, not merely going fast — and most successful people have the instinct to act now rather than defer to tomorrow

That execution instinct helps at every stage: early on it tells you fast whether it's the right product, and later fast turnaround with care creates happy customers who come back and expand

8:11 Speed must be paired with quality not speed for its own sake

Anton Osika · published Aug 18, 2025

Lovable should behave more like a farmer optimizing for the long term than a cowboy, while still striking a balance

44:17 Farmer long term optimization over cowboy short term once mature

Harry Stebbings · published Aug 18, 2025

Relentlessly optimizing for the short term and patching over problems is preferable at this phase of company building

Chinese development teams have an unbelievable psychology around build, optimizing incessantly for the short term and sticky-taping problems, which is often how they ship so much so fast

44:31 Relentless short term patching wins in early phase

Matteo Franceschetti · published Nov 20, 2023

Velocity has to be built deliberately into culture by naming and publicly celebrating fast work, with the goal of doing in half the time what any other company does

34:49 Deliberately celebrate fast work to build a velocity culture

David Meyer · published Nov 1, 2023

Speed of learning is what matters, not speed of shipping — and maximizing the learning curve often feels slow

The key is to know why you're doing the next step before you do it; when you can't reason your way there, ship throwaway work to get the learning without over-architecting

13:28 Speed of learning not speed of shipping is what matters

Christian Kleinerman · published Sep 22, 2023

The right balance between deliberation and fast iteration depends on the technology: core data-integrity subsystems need heavy up-front design, while UI surfaces should ship and iterate

Nobody wants corrupted data or wrong results from a badly built core subsystem, whereas for query-editor suggestions there's no right answer so you learn from users

36:58 Subsystem criticality determines deliberate design versus fast iteration

Christian Kleinerman · published Sep 22, 2023

Shipping faster is not necessarily better when simplicity is what's being traded off; taking longer to make the automatic choice for customers is often the right call

You can ship faster by surfacing all the choices to users, but simplifying for the customer takes longer and is worth it

38:50 Prioritizing simplicity for customers justifies slower shipping

David Lieb · published Sep 21, 2022

The right trade-off between shipping speed and quality depends entirely on context: most startups should ship something rough and learn from a user, while a big company launching to a large audience needs the product quite good first

Google Photos would be tried by many users on day one and was storing people's life memories, so the trust-conveying core had to be fast and reliable in all network conditions; the first version of Bump was embarrassingly designed and that was still the right call

16:53 Shipping speed quality tradeoff depends on company stage and audience scale

Geoff Charles · published Dec 6, 2023

Shipping a product that doesn't work does not carry meaningful brand cost even at Ramp's scale, because you can market to the broad market separately from existing customers

With 15,000 customers the wider market still doesn't know what the product is, so by the time a prospect actually activates the product will be much better; existing customers should already be in beta before the market announcement

26:07 Shipping broken features carries low brand risk when tam is large and unaware

Tom Blomfield · published May 13, 2024

Founders should launch with an extremely narrow feature set polished to a very high quality bar, then broaden, rather than shipping broad functionality at mediocre quality

A narrow product can be built quickly and can get a few hundred people genuinely excited, whereas trying to replicate every feature of an incumbent like Google Docs at mediocre quality leads to a launch nobody likes

27:27 Narrow polished launch beats broad mediocre launch

Paul Erlanger · published Jun 27, 2026

Founders should ship something a specific user base wants rather than hold out for perfection, because most admired companies did not actually ship perfect products

Hindsight is rose-tinted — Apple's lithium-ion batteries exploded and the first iPhone glitched constantly, yet everyone envies them

15:45 Ship imperfect to a specific user base

Harry Stebbings · published Jul 27, 2025

Revolut massively outshipped Monzo on new products despite Monzo having the more beautifully designed product

21:15 Out shipping competitors can beat superior design

Cristóbal Valenzuela · published Aug 28, 2023

When you are building something genuinely new, you should ship early and publicly rather than perfect it in private, because your assumptions about how people will use it are likely wrong

Text-to-video has never been tested before, so years of private assumption-building risks missing real feedback and use cases; the only way to advance creativity+AI is to build alongside the artist and filmmaker community

12:39 Ship early publicly for genuinely new untested capabilities since private assumptions are likely wrong

Raaz Herzberg · published Dec 12, 2025

The right product mindset is binary: if a feature doesn't work at infinite scale, it doesn't work and you shouldn't build it

That was the operating standard at Microsoft, and carrying it into Wiz meant the team built for today's scale from day one and never had to refactor

28:29 Binary rule if it does not work at infinite scale do not build it

Raaz Herzberg · published Dec 12, 2025

Building for infinite scale does not trade off against development velocity; it means earlier decisions are more conscious, which saves time later

It's a mindset rather than a perfectionism requirement, and it prevents technical debt, which accumulates fast and can kill teams

30:09 Scale first is a mindset that costs no velocity and saves time later

Raaz Herzberg · published Dec 12, 2025

The core day-one decision rule for avoiding technical debt is: if you're not sure a solution will work at infinite scale, don't build it now — find a solution that serves this customer and the future

PMs are tempted to build whatever wins the five POCs in front of them, and that creates problems you hit later

31:31 Refuse the poc winning hack find a solution that serves customer and future

Jean-Michel Lemieux · published Mar 20, 2024

The core cultural difference is that Shopify ships on quality while Atlassian ships on speed

Atlassian does many things at once — many products, lots of M&A — while at Shopify they spent far more time doing fewer things and Toby would stop shipments on quality grounds

9:22 Quality first and speed first are both viable company cultures

Jean-Michel Lemieux · published Mar 20, 2024

Teams should not choose between speed and quality but split work monthly — polish roughly half the things to best-on-the-planet standard and rush the other half

That mix is what produces long-term momentum: the polished things are what customers rave about to friends, and the rest wouldn't be talked about anyway

13:25 Split work into a polished half and a rushed half monthly

Jean-Michel Lemieux · published Mar 20, 2024

You get both speed and quality by time-capping work and deciding as a team what must be polished and what must not

Refusing to discuss things that don't matter and forcing either shipping this week or a time-capped direction debate has given his team a huge amount of speed

14:44 Time capping decisions achieves both speed and quality

Jonathan Ross · published Feb 17, 2025

Because AI makes prototypes trivially easy to build, products will have to be highly polished to stand out, and globalized expectations mean everyone must compete at the highest end

Freer communication means people see the best work others do and come to expect it — the average restaurant today is better than high-end restaurants twenty years ago; with 40 people building the same app, polish is the only differentiator

65:25 Ai commoditizes prototypes so polish becomes the differentiator

Cem Kansu · published Jun 20, 2025

Extensive iterative prototyping should sequence core utility first, then engaging design, then polish — validating the core interaction before investing in looks.

You avoid spending months of build time before knowing whether the thing works at all; you validate the core, then do the other steps.

9:24 Sequence core utility before design and polish when prototyping new features

Paul Graham · published Mar 2012

Startups should launch fast.

YC needed to reach students before they made summer plans, so it followed the advice it gives startups.

source Launch as fast as possible to seize time sensitive opportunity windows

Paul Graham · published Sep 2001

Being able to release immediately is a big motivator, and shelving an idea costs not only the delay but all the further ideas implementing it would have generated.

Working to implement one idea gives you more ideas, the way half the ideas in a piece of writing occur while writing it; a full shelf also inhibits thinking of new features.

source Instant release capability prevents the hidden cost of shelving ideas that would spawn further ideas

Paul Graham · published Oct 2005

A startup's initial version exists to be rewritten, so founders should deliberately ignore scalability, internationalization and heavy-duty security at first.

Software in a startup functions primarily as a vehicle for experimenting with its own design; the bigger pain than retrofitting is having a version 1 too big and rigid to evolve into what users want.

source First version is a disposable experiment so ignore scalability security and internationalization