Written by Albert Friedman
on 

Keep Releases Small: Trunk-Based Development with Feature Flags for Small Teams

Continuous integration and delivery for a small engineering team should feel frictionless, not like a full-time job. One practical approach that scales well for teams of 3–15 engineers is trunk-based development (TBD) combined with runtime feature flags. The pairing keeps the mainline deployable, reduces merge pain, and lets you release on your schedule without long-lived branches or heavy release process overhead.

Why this matters

Trunk-based development in plain terms TBD means developers integrate small, frequent changes into a shared main branch rather than isolating work in long-lived feature branches. The goal is a mainline that is always in a deployable state. Merging small changes often reduces the likelihood of painful, large merge conflicts and supports faster feedback loops. Teams practicing TBD commonly aim to merge at least daily or to merge every commit to main after passing CI checks. (atlassian.com)

How feature flags complete the picture Feature flags (toggles) let you decouple deployment from release. Instead of waiting until a large feature is “complete” to merge, you wrap the new behavior in a flag, merge early and often to main, and control exposure at runtime. This enables gradual rollouts, A/B tests, and instant kill switches when something goes wrong — all valuable for small teams that need to move quickly but stay safe. (docs.getunleash.io)

Core practices for small engineering teams

A simple feature-flag workflow for a small team

  1. Create a feature flag and register an owner and removal date.
  2. Implement the feature behind the flag and push to main with CI passing.
  3. Use progressive rollout (percentage or targeted user segments) to test in production.
  4. When the feature is stable and used, flip the flag on fully and remove the flag code per the scheduled cleanup.

Example: a minimal JavaScript flag check

// simple feature check (pseudocode)
import flags from 'feature-client';

function renderWidget(user) {
  if (flags.isEnabled('newWidget', user)) {
    return renderNewWidget();
  } else {
    return renderOldWidget();
  }
}

Even tiny teams get a lot of mileage from this model: you can hand off part of a feature, test with real users, and revert instantly via configuration instead of code rollbacks.

Testing and CI adjustments that make this safe TBD + flags rely on strong automated testing to keep mainline stable. On a practical level:

Flag hygiene: avoid technical debt Feature flags are powerful but can become tech debt if left unmanaged:

When to use short-lived branches anyway TBD doesn’t forbid branches entirely. Short-lived branches (a day or two) can help when you need an isolated experiment or a refactor that spans multiple commits. The guideline is strict: branches must be short-lived, rebased frequently, and merged back to main quickly. Use flags as your default for user-facing behavior, and reserve branches for the rare cases where isolation is required. (atlassian.com)

Operational tips for small teams

What you’ll get from adopting this approach

A final note Trunk-based development plus feature flags is not a silver bullet, but it’s a pragmatic, low-friction approach that small engineering teams can adopt incrementally. Start with a single feature flag and a CI rule that runs fast unit tests on every push; iterate your workflow from there. The biggest wins come from small, consistent changes and a little discipline around flag lifecycle and automated testing.

References (for the practices above)