How do you balance new features against bug fixes?
The short answer: bugs that break the core experience for existing users almost always come first, because trust is harder to rebuild than a roadmap is to delay. New features attract users; broken fundamentals drive them away permanently. The real skill is developing a fast, repeatable triage system so this decision never becomes a week-long debate.
Why the question is framed wrong most of the time
Most founders treat features vs. bugs as a resource allocation problem — how many sprints do we give each bucket? That framing assumes both are roughly equivalent in their effect on the business, which they aren't. A bug in a rarely-used edge case and a bug that blocks a paying customer's daily workflow are not the same category of problem, and lumping them together with 'feature work' produces a queue that optimizes for completion rate rather than user outcomes.
The better frame is: what does a user actually experience right now? If they can't complete the core job your product was hired to do, that's not a bug — it's a product failure, and it takes priority over everything except maybe a security breach. If the bug affects an edge case that fewer than 5% of users hit, and you have a new feature that 80% of users have requested, the math is different.
Garry Tan's engineering philosophy, visible across his gstack project, consistently emphasizes tying technical choices to real user outcomes — what the user sees, loses, waits for, or can now do. That's the filter. Apply it to every bug and every feature request before you even think about scheduling.
A triage system you can implement this week
The fastest triage method is a two-axis grid: severity (how badly does this break the user experience?) on one axis, blast radius (how many users does it affect?) on the other. Bugs that score high on both get fixed before any new feature ships. Bugs that score low on both go into a backlog and get batched into a future release. The interesting decisions live in the middle quadrants.
For bugs with high severity but low blast radius — say, a data export failure that only affects enterprise accounts on a specific plan — you need to weigh the user relationship cost. Losing one enterprise customer because of an unfixed bug can cost more revenue than shipping three new features would generate. For bugs with low severity but high blast radius — a cosmetic layout issue that 60% of users see but nobody reports — you can usually batch these into a patch release without blocking feature work.
Versioning discipline matters here too. Garry Tan's gstack versioning approach draws a useful practical distinction: PATCH bumps are for bug fixes, MINOR bumps are for features, and when the diff is large you move up a level. Formalizing this in your own release process forces your team to consciously categorize work rather than letting everything collapse into an undifferentiated sprint.
One concrete practice: hold a 20-minute bug triage every Monday before sprint planning. Go through every open bug report, assign it a severity and blast radius score in under 60 seconds each, and decide right then which ones block the next feature release. This prevents the slow accumulation of 'we'll get to it' technical debt that silently erodes user experience.
The hidden cost of shipping features on a broken foundation
New features are only additive if the foundation they're built on is solid. Ship enough features on top of unresolved bugs and you end up with compounding complexity — new code that has to work around old broken behavior, edge cases that multiply, and a test surface that becomes impossible to reason about. The short-term win of a shiny new feature release turns into a long-term tax on every future release.
There's also a trust dynamic that founders often underestimate. Users who encounter bugs don't just stop using the broken feature — they start questioning everything else. If your export button fails, they wonder whether their data is actually being saved correctly. If your search returns wrong results, they stop relying on the search. Each unfixed bug is a small withdrawal from the trust account you've built with that user. New features make deposits, but only if users trust the product enough to try them.
A practical rule of thumb: if your support queue has more than one critical bug open for more than two weeks, freeze new feature development until it's cleared. Two weeks is long enough to rule out a quick fix; if a bug is still open after two weeks, it's either genuinely complex or it's been deprioritized, and either way it needs a dedicated owner and a deadline before new work starts.
When to intentionally prioritize features over bugs
There are legitimate cases where pushing a new feature ahead of a known bug is the right call. The clearest one: you're pre-product-market-fit and you're trying to learn whether a new surface area changes retention or activation. In that case, shipping the experiment fast and learning from it may be more valuable than fixing a bug that affects a small fraction of users on a product that isn't working yet anyway. You can't polish your way to product-market fit.
Another case: a competitive feature that a key customer has asked for, where the delay of even two weeks means losing the deal. If the existing bug doesn't affect that customer's workflow and the feature closes a six-figure contract, the prioritization math is clear. Make this decision explicitly and document it — 'we are knowingly shipping feature X ahead of bug Y because Z' — rather than letting it happen by default.
What you want to avoid is the pattern where features always win because they're more exciting to build and easier to demo. That's not a strategy, it's a team culture problem. The fix is making bug metrics as visible as feature metrics: track mean time to resolve, track the percentage of support tickets that are bug reports vs. usage questions, and make those numbers part of your weekly review. What gets measured gets prioritized.
“Bugs matter. Edge cases matter. Fix the whole thing, not the demo path.”
— Garry Tan, source
The one thing to do
Run a 20-minute bug triage every Monday before sprint planning, score every open bug by severity and blast radius, and make it a team rule that critical bugs get an owner and a deadline before new feature work is approved to start.
Frequently asked questions
What's the minimum viable bug-triage process for a two-person team?
A shared doc with three columns — critical (blocks core use), moderate (degrades experience), low (cosmetic or edge case) — updated every Monday before planning. Critical bugs don't let new feature work start until they're resolved. That's it.
Should we ever ship a feature we know has a known bug in it?
Yes, if the bug is in a non-critical path and you've documented it internally with an owner and a fix deadline. Shipping with a known, scoped bug is a conscious tradeoff. Shipping without knowing about it is just poor QA.
How do we stop engineers from ignoring bugs because features are more fun to build?
Make bug resolution a visible team metric, rotate 'bug duty' so everyone shares the load, and give public credit for fixes just as you would for feature launches. Culture follows incentives.
When does technical debt become urgent enough to stop feature work entirely?
When bugs are taking longer to fix because the codebase is too tangled to reason about safely — that's the signal. A useful proxy: if a senior engineer estimates a fix but a junior engineer's implementation takes 3x longer due to unexpected interactions, your debt is compounding and it's time to address the root cause.
Sources
- gstack: CLAUDE.md — Garry Tan