5 guests 5 episodes 4,207 words

Strategic Tech Debt: Startup Superpower or Slow-Motion Suicide?

Is taking on technical debt a startup superpower, or a slow-motion suicide?

Gaurav Misra has a mortgage metaphor ready before you can finish the question. Technical debt, he argues, is literally a startup's job — the one structural advantage a small team has over an incumbent that can't, by virtue of its size, defer anything. Julia Schottenstein has a rallying cry for the engineers at dbt Labs who are embarrassed by the naive for-loop they shipped as a scheduler: tech debt is a champagne problem. If you have it, celebrate, because someone is using the product hard enough to break it. In their telling, refusing to take on debt is a kind of unforced error — an act of perfectionism disguised as virtue.

Ryan Singer has spent the last several years consulting with engineering orgs where that argument has metastasized into its opposite. Nothing ships. Refactoring fills every sprint. The engineers and product team have built a wall between themselves and started calling the silence "infrastructure work." Simon Willison, watching AI coding agents churn out ten thousand lines of code in the time it used to take him to write a hundred, worries that debt in 2026 is no longer even a choice — it's the default, accumulating invisibly under a rising tide of plausible-looking slop. And Camille Fournier, who has watched rewrites fail at Rent the Runway, Goldman, JPMorgan, and Two Sigma, thinks most of the people invoking either extreme are about to sign up for a migration they drastically underestimate.

You are leading a small team with too much to do and too little time. Do you treat technical debt as strategic leverage — the way a startup buys speed it couldn't otherwise afford — or as a slow-building liability that will eventually grind your company to a halt? And once the debt is on the books, do you pay it down in a heroic rewrite, evolve it piece by piece, or leave it alone until it actually hurts?

The 3 Positions

1 / 3

Debt Is the Job — Leverage You Can't Get Any Other Way

Gaurav Misra · Julia Schottenstein

Gaurav Misra — Co-founder and CEO of Captions; formerly led design engineering at Snap; engineer at Microsoft. Runs one of the fastest-shipping AI consumer startups in the space — every engineer at Captions ships a marketable product every week — and watched Snap pay down startup-era debt at scale from the inside.

Misra has the most fully-articulated version of the debt-as-feature thesis in the archive, and it starts from a structural observation about incumbents. Big companies don't take on technical debt because they can't: they either pay it off immediately or spend their time paying back debt from when they were a startup. That asymmetry is the exploitable edge. If a small team voluntarily gives up the one lever available only to small teams, it's forfeiting its single structural advantage over the incumbent it's trying to displace.

"I actually think there's a unique thing to think here about technical debt in general. And as a startup, your job is to take on technical debt because that is how you operate faster than a bigger company. Bigger companies don't take on technical debt, they pay it usually right away. Or they're paying back technical debt from the days when they were a startup, and they took on a lot of it."
Gaurav Misra
▶ 00:20:48

The Captions operating model is what this looks like in practice. Every engineer is expected to ship a marketable feature every week — a cadence that is literally impossible without deferring architectural work. Misra's reframe is to drop the moral vocabulary altogether and replace it with a financial one. Debt is leverage. A mortgage lets you buy a house you couldn't afford with cash. Strategic tech debt lets you build products a small team couldn't otherwise build.

"We think about it as like, well, is this a problem we need to solve today or is this a problem that the 50th engineer or the hundredth engineer or the 500th engineer can solve? And if it is a problem that a future engineer can solve, we should use that future engineer now. Essentially, that's what we're doing. And we're saying we're going to push this to somebody in the future. And by the way, if the company fails, that engineer will never be hired and all this won't matter anyways. So it's like financial debt in many ways. Financial debt is taken on to create leverage."
Gaurav Misra
▶ 00:21:19

"You can create products that you wouldn't be able to build with a small team that you have by taking on strategic technical debt. It's very positive actually."
Gaurav Misra
▶ 00:22:04

The piece most people miss — and the piece that distinguishes Misra from the caricature — is that he gives an explicit interest-rate model. Debt is not free money. It's a runway that runs out. Every piece you take on costs you something, every day, until you either pay it down or hire somebody to pay it down for you.

"Every piece of debt that you take on you have to pay interest on. So if there is debt that you've taken on, there's 1% or 2% of your time that is going to be taken away every day in maintaining bugs and issues and restarts and crashes and things that are happening with that. Because you did it the fast way, something's going to go wrong with it. Every day. 1% of your time will be taken away. If you take on enough debt, you'll be paying 80 or 90% interest and you'll not have any time to do anything new. You'll just be paying interest."
Gaurav Misra
▶ 00:22:50

The rest of Captions' operating model falls out of that model. Q4 is deliberately named "infrastructure quarter" — a predictable, dedicated debt-paydown cycle rather than a continuous tax. One-way doors (irreversible architectural decisions) get real thought. Two-way doors get taken on debt. Quality where the user touches the product is non-negotiable; debt lives behind that line, invisible to the user until it doesn't.

Julia Schottenstein — Head of Product at dbt Labs; previously investor and investment banker. Joined dbt Labs as head of product after an investing career, and has overseen the scheduler's multiple rewrites from naive for-loop to 10M runs per month infrastructure.

Schottenstein's compressed version of the same thesis is a two-mantra system she repeats like a battle cry: worse is better, and tech debt is a champagne problem. The phrases are explicitly calibrated as interventions against the perfectionism impulse in engineering orgs — the failure mode where the cleanup that precedes product-market fit gets mistaken for engineering virtue.

"I'm not a big framework person, but there's two sayings that I find myself repeating or I either to myself or to others. And it's worse is better and tech debt is a champagne problem. And what do I mean by that? It's really to help me combat this perfectionism because perfect doesn't exist and you should instead go with good enough because when you ship, that's the moment when you get to learn a lot from your users and you just can't anticipate it."
Julia Schottenstein
▶ 00:52:10

The war story that anchors the framework is the dbt Cloud scheduler. At launch, the engineering team was embarrassed: the scheduler was a naive for-loop over a jobs table. Iterate over rows, check if each one was due, run it, move on. No distributed workers, no RabbitMQ, nothing that looked like infrastructure a data tooling company was supposed to have. But at launch there was nothing to schedule — they had no users. Building a distributed scheduler at day zero would have been building for a scale that did not exist.

"It was a big old for loop over a big old jobs table. So we would look like is it time for this job to run? Okay. Yes, run this job... And it would just loop over and it's extremely naive and very simple, but it got the job done. And I try to remind the engineers, we would be so lucky to have tech debt because that means people are using the product."
Julia Schottenstein
▶ 00:53:02

The scheduler has since been rewritten multiple times. dbt now runs ten million jobs a month for eight thousand companies, and each rewrite was a real cost. Schottenstein's point is that those rewrites were only costs the company got to pay because the embarrassing for-loop did its job — it shipped, it taught them what scale problems actually looked like, and it bought them the users who created the pressure to rebuild.

"What we didn't need at launch was a distributed scheduler with coworkers and RabbitMQ. We just didn't need it because we had no users. So these two sayings that worse is better and tech debt is a champagne problem, just really reminds people like, let's ship, let's get it out into the user's hands and then we'll learn and iterate and it'll be a better experience for them."
Julia Schottenstein
▶ 00:53:30

The "champagne problem" framing is also a deliberate morale move. It converts what engineers experience as shame — look at this crap we built — into evidence of success. Shame-driven engineering orgs over-rotate on cleanup. Cleanup that precedes product-market fit is waste.

When This Applies

when your org has been running for years but "nothing is getting out the door," when refactoring has filled every sprint, and when product and engineering have stopped negotiating. Singer's consulting case: mature scrum orgs that "still remember what it was like to be fast and don't like being slow."

Debt Is a Failure Mode Dressed Up as Virtue

Ryan Singer · Simon Willison

Ryan Singer — Creator of Shape Up; 17+ years at 37signals/Basecamp; now consults with engineering orgs on product process. Lived inside Basecamp's protected six-week cycles for nearly two decades, and now spends his consulting time almost exclusively with mature orgs stuck in the refactoring trap.

Singer's critique is not of debt itself but of the endemic middle-age failure mode he sees in engineering orgs that started well and then got stuck. He describes a very specific pattern: a company has been running scrum for years, revenue is coming in, sales is doing its job, but nothing is getting out the door. There is an entrenched engineering team separated by a wall from an entrenched product team, and the two sides have stopped having real trade-off conversations. In that environment, "tech debt" and "refactoring" become the default work — because they require no cross-functional agreement. Engineers can unilaterally decide the system needs to be cleaner, and nobody on the product side can credibly push back because they don't read the code.

"There are a lot of engineering orgs that have been standing around for a while and it's all refactoring all day and tech debt and stuff like that. And there's reasons why all those things got there, but there comes a point where we have to figure out how to cut through it and make some hard choices so that we can carve out time to build the stuff that's actually going to be needle moving again and not just sustaining us where we are to run in place."
Ryan Singer
▶ 01:22:56

Basecamp, in Singer's telling, was the counter-example by construction. Six-week cycles meant engineering capacity was predictably "blank" and could be spent on whatever the team had agreed was most important. Because the unicorn founders handled go-to-market, engineering was never captured by internal sales politics. It never became a cost center looking for work.

"Keeping that engineering capacity focused on readiness for product and totally leaning into what's exciting to do to build for the product. And not getting lost in all this refactoring and new infrastructure and technical debt and stuff like that."
Ryan Singer
▶ 01:31:16

The contrast illuminates the real problem. In orgs that have lost that clarity, refactoring is what engineers do when nobody is asking them to build anything compelling. Singer's prescription is not to shame the engineers — it's to force the hard conversation at the executive level, because nobody below the exec line has the authority to change it.

"We can't just have endless refactorings and infrastructure projects, but we need to be actually building things that we can sell again."
Ryan Singer
▶ 01:22:19

The polite version of Singer's argument is that shipping has to become needle-moving again. The impolite version is that endless paydown is a disguised form of stagnation, and calling it "tech debt" is the vocabulary that makes it invisible.

Simon Willison — Independent engineer; co-creator of Django; widely cited voice on AI engineering practices; coined "prompt injection" and popularized the term "AI slop." Has been a working engineer for 20+ years and is one of the few senior engineers publicly documenting daily AI coding practice in real time on his blog.

Willison's contribution is the AI-era update that neither camp fully anticipated. Before LLMs, taking on technical debt was a deliberate act: you chose to cut a corner because you knew you were doing it. Willison's observation is that coding agents have made debt a passive default. He can now produce ten thousand lines of code in the time it used to take him to write a hundred. That sounds like pure upside — prototyping is "almost free," the superpower of showing up to meetings with working demos has been democratized — but the volume of code is now decoupled from the engineer's understanding of it.

"As an individual programmer, you have to start thinking, okay, I can churn out 10,000 lines of code now in the time that it would take me to write 100. How do I make that code good? How do I make sure that I'm not just churning out total slop that adds up to technical debt that slows me down? How do I take the fact that code is now cheap and use that to produce better code? Because I don't just want cheap code. I want really good code that does what I need it to do that I can extend in the future that's got all of those characteristics of code that's useful and can be used in production."
Simon Willison
▶ 00:45:45

"Prototyping is almost free, I think. And that really impacts me because throughout my entire career, my superpower has been prototyping. I've been very quick at knocking out working prototypes of things."
Simon Willison
▶ 00:46:45

The phrase "adds up to" is the key move. It is not one bad decision. It is an accumulation that happens beneath your notice because the individual outputs look plausible. Willison's prediction about AI systems in general applies directly to the debt question:

"Lots of people knew that those little O-rings were unreliable, but every single time you get away with launching a space shuttle without the O-rings failing, you institutionally feel more confident in what you're doing. We've been using these systems in increasingly unsafe ways, this is going to catch up with us. My prediction is that we're going to see a challenger disaster."
Simon Willison
▶ 00:01:08

Every time an agent ships code that works, the team feels more confident letting the agent write more. Which means more unreviewed surface area. Willison is not anti-AI — he uses coding agents constantly. His prescription is to treat the cheapness of code as a constraint to be spent on quality rather than as permission to produce more. In the AI era, the question is no longer whether to take on debt. It's whether you can maintain the judgment to notice when you already have.

When This Applies

when you are pre-PMF, small, and shipping speed is your only edge against larger competitors. Captions (weekly feature cadence against incumbents), most AI consumer startups, and early-stage dev tools. Price every piece, budget a paydown cycle (Q4 at Captions), and protect one-way doors from debt.

The Rewrite Is the Trap — Evolve, Don't Declare Bankruptcy

Camille Fournier

Camille Fournier — Independent; formerly CTO of Rent the Runway; head of platform engineering at Two Sigma; senior engineering roles at JPMorgan Chase and Goldman Sachs; author of The Manager's Path and Platform Engineering. Has held senior engineering leadership roles from hypergrowth startup through trillion-dollar bank, and has seen both the "refused to take on debt" and "rewrote it all" failure modes up close.

Fournier sits between the extremes and her specific contribution is about what engineering leaders should actually do once debt has accumulated. She doesn't dismiss debt as a champagne problem, and she doesn't romanticize the clean rewrite as a solution. Her argument is that most major rewrites dramatically underestimate how much the old system does. Legacy systems are full of undocumented business logic, weird edge cases, and data formats that the team has forgotten were important. Declaring the old system bankrupt and starting over looks like solving a technical problem, but it actually means signing up to re-derive years of implicit business rules under time pressure with a team that has never seen them before.

"When people try to do rewrites, particularly again if it's something that you're really trying to just move to a new language for example or sort of modernize in a certain way, a lot of times people really underestimate what the old system does and how well they know what the old system does. There's so much logic buried in legacy systems, it tends to be undocumented, it tends to be weird. You haven't thought through all the business rules, you haven't thought through the data formatting."
Camille Fournier
▶ 00:18:45

Her prescription is evolutionary. Take pieces of the old system, uplift them, make them more scalable, clean up the debt in that specific section, and move on. Infrastructure as gardening rather than infrastructure as construction.

"When you're struggling making an evolution plan, take pieces potentially of the old system, uplift them, make them more scalable, make them easier to work with, clean up the tech debt, but trying to say we're going to just go away. We're going to rewrite, we're going to build something brand new and it's going to solve all our problems, it just very rarely works."
Camille Fournier
▶ 00:19:14

Fournier's sharpest heuristic is the one most engineers never apply: she asks whether the debt needs to be paid down at all. A system that works, that nobody touches, that isn't hurting the business — maybe the right move is to leave it alone.

"If I could go away and not touch this and not do anything to it for a long period of time without it really harming my business, is it worthwhile to change it at all? Does it matter, and there's some questions there."
Camille Fournier
▶ 00:17:52

Her broader platform engineering work extends this into organizational design. Platform teams exist precisely to pay down debt in structured, incremental ways across the org rather than through heroic one-off rewrites. The middle path — continuous evolution — is harder to execute than either extreme, but is almost always the right one.

When This Applies

when your first shipped version is embarrassing but your users are real. dbt Labs' original scheduler (for-loop to 10M runs/month), early infrastructure products, dev tools with technical audiences forgiving of rough edges. The rewrites are the price of having users at all.

Evidence from the Archive

Captions

Every piece of tech debt costs 1-2% of daily engineering time in bugs and restarts — accumulate enough and you pay 80-90% interest just to keep the lights on

Gaurav Misra dedicates Q4 as 'infrastructure quarter' every year and treats debt as startup leverage, but gives a precise interest-rate model to know when you're broke

Gaurav Misra · CEO and co-founder of Captions ▶ 00:22:50

dbt Labs

dbt Cloud's original scheduler was a naive for-loop over a jobs table — they've since rewritten it multiple times to handle 10M jobs/month for 8,000 companies

Julia Schottenstein's mantra: 'worse is better and tech debt is a champagne problem' — the rewrite cost was real but they only got to incur it because the embarrassing version shipped

Julia Schottenstein · Head of Product at dbt Labs ▶ 00:53:02

Basecamp / Shape Up

Ryan Singer sees mature engineering orgs trapped in 'all refactoring all day' — a sign that product and engineering have lost the conversation about what to build

His diagnosis: refactoring becomes the default work when there's no cross-functional agreement, because engineers can unilaterally decide the system needs cleaning

Ryan Singer · Creator of Shape Up; spent 17+ years at 37signals/Basecamp ▶ 01:22:56

Independent / Datasette

Simon Willison can now produce 10,000 lines of code in the time it used to take to write 100 — but the AI-era risk is debt that accumulates as passive default, not deliberate choice

The co-creator of Django predicts a 'Challenger disaster of AI' where institutional confidence builds with each successful shipment until compounding invisible risk blows up

Simon Willison · Independent engineer; co-creator of Django; coined 'prompt injection' and 'AI slop'

Two Sigma

Camille Fournier's rule: ask 'if I left this alone, would my business hurt?' — most accumulated debt fails this test and should just be left alone

Drawing on engineering leadership at Goldman, JPMorgan, Rent the Runway, and Two Sigma, Fournier argues evolutionary paydown beats both hoarding debt and heroic rewrites

Camille Fournier · Engineering executive at Two Sigma; author of Platform Engineering ▶ 00:17:52

The Synthesis

The debt-as-feature and debt-as-bug camps look like they are disagreeing about tech debt. They are actually disagreeing about what phase the company is in. Misra and Schottenstein are talking about pre-PMF and early growth — the stage where shipping is the only reliable source of learning and the scale designs built without users are fiction. Singer and Fournier are talking about mature orgs where engineering has decoupled from product outcomes and the vocabulary of "debt" has become a way to look busy. Willison is describing a third regime — the AI era — where the old debate's assumption that taking on debt was a deliberate act no longer holds.

Debt as the Exploitable Edge

Are you using the one lever only small teams have?

The Interest Rate Model

What's your debt actually costing you every day?

Champagne Problem

Is this embarrassment actually evidence of success?

Refactoring as Stagnation Disguise

Is tech debt the vocabulary hiding your real problem?

Invisible Default

Are you still choosing your debt, or is it choosing you?

Gaurav Misra's structural observation: big companies can't take on debt because they're already paying back their startup-era debt. That asymmetry is the exploitable edge. A small team that voluntarily refuses debt forfeits its single structural advantage over the incumbent it's trying to displace — perfectionism disguised as virtue.

Misra's explicit pricing: every piece of debt costs roughly 1-2% of your time per day in bugs and restarts. Take on enough and you'll be paying 80-90% interest — all maintenance, no new work. Debt is leverage, but leverage with a runway. The failure mode isn't taking on debt; it's not knowing what it costs.

Julia Schottenstein's dbt scheduler launched as a naive for-loop over a jobs table. It was embarrassing. It also got rewritten multiple times — costs the company only got to pay because the embarrassing version shipped and bought users. Shame-driven engineering orgs over-rotate on cleanup that precedes product-market fit. Cleanup before PMF is waste.

Ryan Singer's consulting pattern: mature orgs where nothing ships, engineering and product have walled themselves off, and 'refactoring' fills every sprint because it's the only work that requires no cross-functional agreement. Endless paydown is stagnation wearing the vocabulary of virtue — and the fix is an exec-level conversation, not a better backlog.

Simon Willison's Challenger analogy: every time an AI agent ships plausible code that works, the team feels more confident letting it write more. In the AI era, debt is no longer a deliberate choice — it's the passive default, accumulating invisibly under a rising tide of slop. The question isn't whether to take on debt; it's whether you still know when you have.

Which Approach Fits You?

Answer 3 questions about your situation. We'll match you to the right approach.

Question 1

What stage is your company in?

Question 2

How do you currently price technical debt?

Question 3

What is the root cause of your current pain?

Notable Absences

The Bottom Line

The real failure mode is not taking on too much debt or too little. It's letting debt become implicit — something that happens to you rather than something you choose. Misra chooses it and prices it. Schottenstein chooses it and celebrates when the price comes due. Fournier refuses to pay prices she hasn't audited. Singer rings the alarm when orgs pay prices they never agreed to. Willison worries that in the AI era, the prices are being charged before anyone notices the transaction.

The best newsletter frameworks in Lenny's archive are the ones that hard-code that pricing into the operating model. Perplexity, per "How Perplexity builds product," runs a dual roadmap — product work on one track and technical debt on another — and only prioritizes debt paydown when it unblocks a product improvement. That is the Misra heuristic institutionalized: debt pays itself off when the cost of not paying it exceeds the product value you can ship instead. Miro's answer, documented in "How Miro builds product," is even more structural: a 60/20/20 split across product innovation, run-the-business work, and technical innovation, flexed by team maturity. That is the Singer critique made impossible to ignore — you cannot quietly drift into 100% refactoring when 60% of your capacity is pre-allocated to shipping product. And the swim-lane scrapbook model from "Product manager is an unfair role" treats technical debt as one of several ongoing PM swim lanes rather than an engineering-only concern — the cross-functional answer to Fournier's "platform teams as paydown mechanism" model.

Sources

Gaurav Misra — "How to win in the AI era: Ship a feature every week, embrace technical debt, ruthlessly cut scope, and create magic your competitors can't copy | Gaurav Misra (CEO and co-founder of Captions)" — Lenny's Podcast, March 27, 2025
Julia Schottenstein — "M&A, competition, pricing, and investing | Julia Schottenstein (dbt Labs)" — Lenny's Podcast, July 13, 2023
Ryan Singer — "A better way to plan, build, and ship products | Ryan Singer (creator of “Shape Up,” early employee at 37signals)" — Lenny's Podcast, March 30, 2025
Camille Fournier — "The things engineers are desperate for PMs to understand | Camille Fournier (author of “The Manager’s Path,” ex-CTO at Rent the Runway)" — Lenny's Podcast, September 15, 2024