Shipping fast without tech debt

The Real Cost of "Moving Fast"

"Move fast and break things" was a mantra for a reason — it works. Until it doesn't. The problem isn't speed. The problem is that most teams conflate speed with skipping steps. They skip tests, skip reviews, skip documentation, and skip architectural conversations. Each skip feels small in isolation. Together, they compound into a system that resists change.

We've seen the pattern dozens of times with client projects that come to us for rescue:

• Month 1-3: Rapid feature development, everything feels great
• Month 4-6: Bug fix time doubles, new features take longer than estimated
• Month 7-9: Refactoring becomes the primary activity, feature work stalls
• Month 10-12: Team morale drops, senior engineers leave, rewrite discussions begin

The irony is that the "fast" approach ends up being the slow one. Teams that invest in sustainable practices from day one ship more features over a 12-month horizon than teams that cut corners.

Our Engineering Principles

These aren't aspirational values on a wall. They're concrete practices embedded in our workflow, enforced by tooling, and measured by outcomes.

1. Trunk-Based Development

We merge to main multiple times per day. Feature branches live for hours, not weeks. This forces small, incremental changes that are easy to review, easy to test, and easy to revert if something goes wrong.

The key discipline: every merge to main must be deployable. Not "deployable after we fix the follow-up issues." Actually deployable. This means:

• Feature flags for incomplete work — code ships behind a flag, enabled gradually
• Automated gates: lint, type-check, unit tests, integration tests — all must pass
• No "temporary" workarounds that bypass the pipeline

2. The 80/20 Test Rule

We don't aim for 100% code coverage. We aim for the right 80%. The distribution matters more than the number:

• 50% unit tests — Fast, focused, covering business logic and edge cases
• 20% integration tests — Verifying component interactions, API contracts, database queries
• 10% end-to-end tests — Critical user journeys only: signup, checkout, core workflows

The remaining 20% of code — configuration, boilerplate, generated code — doesn't need test coverage. Writing tests for generated code is waste.

3. Code Review as Knowledge Transfer

Every PR gets reviewed. Not as a gatekeeping exercise, but as a knowledge-sharing opportunity. Our review guidelines:

• Review within 4 hours during business days — no PR sits idle
• Focus on design and logic, not style (linting handles style)
• Ask questions instead of making demands: "What happens if X is null?" not "Fix this"
• Approve with suggestions, not blockers, for non-critical issues

The goal: by the time a PR is merged, at least two people understand the change.

Technical Debt Management

Tech debt isn't evil. It's a tool. The problem is unmanaged debt — debt you don't track, don't prioritize, and don't pay down. We treat tech debt like financial debt: deliberate, tracked, and serviced.

The Debt Ledger

Every shortcut gets a ticket. Not a vague "clean up later" note — a concrete ticket with a title, description, and impact assessment. The format:

## Debt Item: [Short descriptive title]

**Introduced:** [Date/PR reference]
**Category:** [Architecture | Testing | Dependencies | Performance | Security]
**Impact:** [What breaks or degrades because of this debt]
**Effort to fix:** [S | M | L | XL]
**Interest rate:** [How fast this gets worse over time]

**Acceptance criteria for resolution:**
- [ ] Specific, measurable outcome
- [ ] Test coverage for the fixed code
- [ ] Documentation updated

The 20% Rule

Every sprint, 20% of engineering capacity goes to debt reduction. This isn't optional — it's baked into our sprint planning. When a client asks "why can't you do more features this sprint?" the answer is: because we're investing in the ability to do more features next sprint.

This allocation is non-negotiable. It's the equivalent of a company contributing to its pension fund — you can skip it, but you'll regret it later.

Deprecation Over Replacement

When we identify a problematic pattern, we don't rewrite the entire system. We deprecate gradually:

1. Mark as deprecated — Add deprecation warnings, document the preferred alternative
2. Block new usage — Linting rules prevent new code from using the deprecated pattern
3. Migrate incrementally — Each touch-point gets migrated as part of normal feature work
4. Remove — Once no callers remain, delete the deprecated code

This "strangler fig" approach means we never pause feature development for a big-bang rewrite.

Automation as Acceleration

The best way to ship fast without creating debt is to make the right thing the easy thing. Automation enforces quality without slowing anyone down.

CI Pipeline

Our CI pipeline runs in under 3 minutes for most changes. That speed is intentional — if the pipeline takes 20 minutes, people will find ways to skip it.

# Pipeline stages (parallel where possible)
┌─────────────┐  ┌──────────────┐  ┌──────────────┐
│   Lint +     │  │   Type      │  │   Unit      │
│   Format    │  │   Check     │  │   Tests     │
└──────┬──────┘  └──────┬───────┘  └──────┬──────┘
       │                │                 │
       └────────────────┼─────────────────┘
                        ▼
              ┌──────────────────┐
              │   Integration   │
              │     Tests       │
              └────────┬────────┘
                       ▼
              ┌──────────────────┐
              │   Security      │
              │   Scan (Snyk)   │
              └────────┬────────┘
                       ▼
              ┌──────────────────┐
              │   Build +       │
              │   Preview       │
              └──────────────────┘

Automated Code Quality

Beyond testing, we automate quality enforcement at multiple levels:

• ESLint + Prettier — Style and lint rules auto-applied on save, enforced in CI
• TypeScript strict mode — No any types, strict null checks, exhaustive switch cases
• Dependency auditing — Automated PRs for security patches, reviewed weekly
• Bundle size budgets — CI fails if JS bundle exceeds threshold (currently 250KB gzipped)
• Lighthouse CI — Performance, accessibility, and SEO scores checked on every PR

Infrastructure as Code

Every infrastructure change goes through the same pipeline as application code. No manual console changes, no "quick fix in production." Terraform plans are reviewed, approved, and applied via CI. This eliminates configuration drift — the silent killer of deployment reliability.

The Feedback Loop

Speed comes from fast feedback. The sooner you know something is wrong, the cheaper it is to fix. We optimize every feedback loop in the development cycle.

Development Feedback

• Hot module replacement — Code changes reflect in the browser instantly, no page reload
• Type errors in the editor — TypeScript catches type mismatches before you save
• Lint errors on save — No waiting for CI to catch style issues
• Test watch mode — Affected tests re-run automatically on file change

Deployment Feedback

• Preview environments — Every PR gets a live URL for manual testing
• Automated smoke tests — Critical paths verified on every deploy
• Error tracking — Sentry catches runtime errors within seconds of deploy
• Performance monitoring — Core Web Vitals tracked in production, alerts on regression

User Feedback

• Feature flags — Roll out to 5% of users, monitor metrics, expand gradually
• A/B testing — Data-driven decisions, not opinions
• Session replay — Understand real user behavior, not assumed behavior
• Direct feedback channels — In-app feedback widget, weekly user interviews

Conclusion

Shipping fast without tech debt isn't about being disciplined in the face of pressure. It's about building systems where discipline is the default — where the right thing is the easy thing, and the wrong thing requires effort.

The practices we've outlined — trunk-based development, targeted testing, managed debt, automation, fast feedback loops — aren't revolutionary. They're the boring fundamentals that work. The difference is that we enforce them consistently, measure their impact, and never treat them as optional.

Speed and quality aren't opposites. They're multiplicands. Teams that invest in quality compound their speed over time. Teams that skip it pay an ever-growing interest rate on their shortcuts.

The fastest teams we've worked with aren't the ones that cut corners. They're the ones that built machines for making the right thing the easy thing.