Skip to content

Debates

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

9 recorded positions from 5 people, first said Jan 27, 2023. They do not agree — the readings below are what each one actually argued.

Rewrites only justified at extreme scale

Cliff Obrecht · 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 · 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

Infrastructure investment must precede usage front end heavy teams break at scale

Zach Lloyd · 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 · 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

Speed over engineering polish early stage

Max Junestrand · 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 · 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

Also on the record

Raaz Herzberg · 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 · 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 · 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

Your assistant can query this graph directly — 9 positions here, 19,646 across the corpus. Add 996.fm over MCP.