← Back to principles

UI

Ship Small, Iterate Fast

Statement

Feature flags, incremental rollouts, and tight feedback loops beat big bang releases. Enable teams to ship safely and learn quickly.

What this means in practice

Work is broken into the smallest useful increments and shipped behind feature flags or progressive rollouts. The team learns from real usage as early as possible rather than batching changes into large, high-risk releases.

  • Features are developed behind feature flags so they can be merged to main continuously without exposing incomplete work to users.

  • Releases are incremental: new functionality is rolled out to a small percentage of users first, then expanded as confidence grows.

  • Feedback loops are short — analytics, error monitoring, and user feedback are reviewed within hours or days of a release, not weeks.

  • Rollbacks are fast and low-risk because each change is small and independently deployable.

  • Teams favour shipping a thin, working slice of a feature over waiting for the complete vision to be ready.

  • Trunk-based development or short-lived branches keep integration pain low and deployment frequency high.

Why this matters

Big bang releases are high-risk, high-stress, and slow to deliver value.

  • Large releases bundle many changes together, making it difficult to isolate the cause when something goes wrong.

  • Long-lived feature branches diverge from main, leading to painful merges and integration bugs.

  • Delayed releases delay learning — assumptions go untested and problems compound.

  • Small, frequent releases reduce the blast radius of any single change and make rollback trivial.

  • Teams that ship incrementally build confidence in their deployment pipeline and spend less time in "release hardening" phases.

  • Feature flags decouple deployment from release, giving product and engineering independent control over what users see and when.

Practices that meet this principle

  • Use feature flags to control visibility of in-progress or experimental features, and clean up stale flags regularly.

  • Deploy to production frequently (daily or more) with small, well-scoped changesets.

  • Use percentage-based or cohort-based rollouts to validate changes with a subset of users before full release.

  • Monitor key metrics (error rates, performance, user engagement) immediately after each rollout step.

  • Define rollback criteria before shipping: know what signals trigger a revert and ensure reverting is a one-step action.

  • Keep pull requests small and focused — a PR should represent a single logical change.

  • Use trunk-based development or short-lived branches (merged within 1–2 days) to minimise integration risk.

  • Run automated tests and checks on every commit to maintain confidence in continuous deployment.

  • Conduct lightweight post-release reviews to capture what was learned and feed it into the next iteration.

Validation

A project meets this principle when:

  • Features are shipped behind flags and rolled out incrementally rather than in large batches.

  • Deployment frequency is high (daily or more) and each deployment is small in scope.

  • The team can roll back any release quickly and with minimal disruption.

  • Feedback from real users (metrics, errors, qualitative input) is reviewed shortly after each release.

  • Long-lived feature branches are rare; most branches are merged within a couple of days.

  • Stale feature flags are identified and removed on a regular cadence.

  • The team is comfortable shipping incomplete features behind flags rather than waiting for full completion.

Potential blockers

  • Lack of feature flag infrastructure or tooling.

  • Environments or deployment pipelines that do not support frequent, independent releases.

  • Organisational culture that expects fully complete features before anything reaches production.

  • Manual QA gates that create bottlenecks and discourage small, frequent releases.

  • Shared release trains across multiple teams that force batching.