How do you ship fast without breaking quality?

Shipping fast and maintaining quality feel like a tradeoff, but the best early-stage teams treat them as a system, not a dial. The secret is that most quality failures aren't caused by speed—they're caused by poor issue structure, skipped root cause analysis, and no rollback plan. Fix those three things and you can move faster with fewer incidents, not slower.

Speed kills quality only when you skip the thinking, not the time

The mistake most early founders make is conflating speed with shortcuts. They move fast by skipping the step where they clearly define what they're actually building and why. This produces fast garbage: code that ships quickly, breaks quietly, and costs three times as long to fix as it would have taken to specify correctly.

The real bottleneck isn't writing code—it's rework. Every hour you spend writing a clear description of the current state, the proposed change, and the specific files involved saves two to four hours of debugging ambiguous requirements later. Before a single line of code is written, a founder or engineer should be able to answer: what does the system do today, who is affected by the gap, and what exactly changes? If you can't answer those in three sentences each, you're not ready to build.

This discipline doesn't slow you down. It eliminates the fake-fast cycle of writing something, discovering it missed the spec, and rewriting it—often across multiple engineers who each have to re-context-switch into the problem.

Root cause first, fix second—every single time

One of the highest-leverage habits an engineering team can build is the discipline of explaining why a bug exists before proposing a fix. Garry Tan's gstack spec makes this explicit: the implementer needs the root cause to validate the solution and avoid introducing the same class of bug elsewhere. This isn't bureaucratic—it's the fastest path to not fixing the same bug twice.

In practice this looks like this: before opening a pull request for a bug fix, write one paragraph that explains the causal chain. Not 'null pointer exception on line 47,' but 'the user object can be null here because we allow unauthenticated API calls in staging but not production, and the test suite doesn't cover that path.' That paragraph is worth more than the fix itself, because it tells every future engineer who reads the commit exactly what class of problem to watch for.

When teams skip this step under time pressure, they accumulate a specific kind of technical debt that's invisible in the codebase: institutional ignorance. No one knows why things work, only that they do. When something breaks under load or an edge case appears, the team has no mental model to reason from. Root cause discipline is how you build that model incrementally without formal documentation overhead.

Effort estimation that enables decisions, not just planning

Vague estimates like '~two days' are worse than no estimate because they create false confidence without enabling real decisions. Useful estimates break effort down per component—schema changes, service logic, tests, frontend—so that a founder can look at the breakdown and make an informed call about what to include, defer, or cut before anyone writes a line of code.

This matters especially for speed: the fastest way to ship something is to ship less of it. But you can only make that call intelligently if you know where the time actually goes. A feature that looks like 'two days' might be 20 minutes of logic and 14 hours of test coverage and migration scripts. If you know that, you can make a deliberate choice to ship the logic behind a feature flag and defer the migration. If you don't know that, you either ship it all (slow) or skip tests (fragile).

For founders managing small teams, per-component estimates also reveal dependencies. If the schema change blocks everything else, it needs to go first. If the frontend and the service can be built in parallel, you can actually use your team's capacity. This is where estimation transforms from an administrative chore into a genuine engineering tool.

Rollback strategy is not optional, it's a speed multiplier

Teams that ship fast sustainably aren't reckless—they're reversible. Every change that touches data, shared infrastructure, or state that other systems depend on needs a rollback plan defined before the change goes out. This doesn't require elaborate infrastructure; sometimes 'revert the PR and run the down migration' is the entire plan. The point is that it's written down and understood before the deploy, not improvised at 2am during an incident.

Rollback planning forces a kind of clarity that also improves the forward design. When you ask 'how do we undo this?' you often discover that the proposed change is harder to reverse than expected, which usually means it's also harder to reason about in production. Noticing that before deployment—not after—is the difference between a five-minute revert and a multi-hour data reconstruction.

For early-stage teams, the practical minimum is: one person knows how to undo every deploy that went out in the last two weeks. Not a runbook, not a doc, just one human with the knowledge and the access. As you grow, you formalize it. But the habit has to exist from the start, because the cost of establishing it after your first major incident is much higher than establishing it on day one.

Paul Graham's point on execution vs. strategy applies to engineering too

Paul Graham has written that poor execution—not competitors—is what kills most startups. This principle applies directly to how you think about shipping. The startups that lose to execution failures aren't usually the ones that moved too slowly. They're the ones that moved in the wrong direction, shipped things users couldn't rely on, or accumulated so much internal chaos that the team's cognitive overhead ate the product velocity.

Quality, in the early stage, is mostly about reliability and trust. If your users can't trust that what you shipped yesterday still works today, they disengage. That erosion is silent and fast. The fix isn't to slow down—it's to build a minimal system of practices that makes each ship trustworthy: clear specs, root cause discipline, per-component estimates, and explicit rollback plans.

The founders who figure this out early discover something counterintuitive: the system actually makes them faster, because they stop paying the tax of rework, confusion, and incident response. Speed without that system is borrowing velocity from your future self at a very high interest rate.

“Poor execution does [kill startups]. But you should know who your competitors are.”

— Paul Graham, source

The one thing to do

Before your next deploy, write one sentence explaining why any bug you fixed exists—not what it was, why—and define exactly how you'd revert if it goes wrong.

Frequently asked questions

What's the minimum quality process for a two-person founding team?

Three non-negotiables: write down what you're changing and why before you build it, explain the root cause of every bug before you fix it, and know how to revert every deploy. Everything else can wait.

Doesn't writing specs and doing root cause analysis slow you down?

Only in the very short term. The time you spend specifying upfront is returned two to four times over in avoided rework and faster debugging. Teams that skip this step don't move faster—they just move faster toward the wrong thing.

How do you decide what to cut when you're behind schedule?

Per-component effort estimates make this tractable. When you know which parts of a feature are cheap and which are expensive, you can make deliberate scope cuts—ship the logic behind a flag, defer the migration—instead of either shipping everything or cutting blindly.

When should a small team invest in more formal quality infrastructure like CI or staging environments?

When the cost of a single bad deploy exceeds the cost of building the infrastructure. For most teams that's when you have paying users who churn after incidents, or when your rollback window starts measuring in hours instead of minutes.

Sources

More playbook answers · Growth Prophet home