Feature freeze and code freeze in app development: essence, differences and role

What is a feature freeze?

Feature freeze is a temporary ban on adding new functionality to the codebase, introduced before a planned release. The team stops merging features and switches to fixing bugs, optimizing, and polishing existing code. Developers finalize incomplete features only within the scope of bug fixes, without expanding the scope.

Feature freeze solves the problem of work-in-progress features that don't make it to the release but are already partially merged into the main branch. If new features continue to be merged, the risk of regression grows: each new integration requires retesting already finished modules. Feature freeze fixes the release scope, turning it from a moving target into a stable set of functionality.

An important clarification: feature freeze ≠ code freeze. During a feature freeze, bug fixes, refactoring, dependency updates, and documentation are allowed. Only new user-facing features are prohibited — any code that changes the application's behavior from the user's perspective. Code review check: if a PR adds a new screen, button, or API method — it is rejected until the freeze is lifted.

What is a code freeze and how is it different from a feature freeze

Code freeze is a stricter practice in which all code changes are completely prohibited. Even bug fixes are not allowed unless they are critical. Code freeze is introduced for a short period (usually 24-48 hours) and guarantees that the release build is assembled from a fixed set of commits.

The difference between feature freeze and code freeze lies in the level of control. Feature freeze manages scope: what exactly will be included in the release. Code freeze manages quality: it eliminates the risk of introducing a new bug the day before release. In practice, many teams use a two-stage model: 1-2 weeks before release — feature freeze, 24-48 hours before — code freeze. Code freeze is particularly relevant for mobile apps, where the build needs to be uploaded to the store several days before the planned release date.

The exception to code freeze is security fixes for critical vulnerabilities (CVE with a score of 9+). Such changes go through an emergency process with mandatory fast-track code review and team notification. All other changes are postponed until the next release cycle.

Feature freeze vs code freeze: comparison

The choice between feature freeze and code freeze depends on the team's maturity and release frequency. Teams with CI/CD and feature flags may only need a 24-hour code freeze, while teams with monthly releases more often use both freezes sequentially.

Types of freezes: full, partial and BAU-freeze

In addition to full feature freeze and code freeze, there are more flexible options. Partial feature freeze blocks new functionality only in certain modules — for example, in the payment module or authorization module, leaving other components open to changes.

BAU-freeze (business as usual freeze) is a compromise option where only large features with a change volume exceeding a certain threshold (e.g., 500 lines of code) are prohibited. Minor improvements, UI tweaks, and bug fixes continue to be merged. BAU-freeze is convenient for projects with continuous delivery, where a full week-long development halt is economically unviable.

There is also the concept of deployment freeze — a complete stop of deployments to production, typical for holiday season (Christmas holidays, Black Friday). During this period, even hotfixes are blocked unless they are security-related. Deployment freeze usually lasts 1-2 weeks and is coordinated at the company level.

When to introduce a freeze and how long it lasts

The optimal time to introduce a feature freeze is after code complete, when all planned features are merged and undergoing QA. The exact timing depends on the release cycle: for a two-week sprint, feature freeze is introduced 3-4 days before the release date; for a monthly release, 7-10 days before. Code freeze is introduced 24-48 hours before the planned release build time.

The duration of the freeze should be the minimum sufficient to stabilize the code. A freeze that is too long (more than 2 weeks) demotivates the team and creates an accumulation of unmerged features, each of which increases the risk of conflicts after the freeze is lifted. A freeze that is too short (less than 24 hours for a feature freeze) does not allow enough time for thorough testing and fixes.

The recommended practice is to set the freeze not by calendar date but by codebase state. Feature freeze is introduced when the number of open bugs for the release exceeds a threshold (e.g., 10 critical bugs). Code freeze — when the build successfully passes smoke tests and regression suite. Time-based freeze (fixed date) remains the standard for regulated industries (fintech, medtech) where the release date is approved by a regulator.

Automating freezes via CI/CD and Git

Manual freeze control is a source of errors: a developer might accidentally merge a PR that should wait until the freeze is lifted. Automation solves this through Git branch protection rules and CI/CD pipelines. In the Git provider (GitHub, GitLab, Bitbucket), rules are configured to block merges into the release branch without a special tag or approval from the release manager.

CI/CD pipeline checks the freeze status before building the build. In Jenkins, GitLab CI, or GitHub Actions, a step is added that reads a configuration file with the freeze schedule and rejects builds if the current date falls within the freeze period. An alternative is a feature flag in the admin panel that blocks deployment to production.

# .github/workflows/check-freeze.yml
name: Check Freeze Status
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-freeze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check freeze status
        run: node .github/scripts/freeze-check.js
      - name: Block PR if frozen
        if: failure()
        run: echo "Feature freeze is active. PR blocked." && exit 1

The example freeze-check.js script reads a JSON with the freeze schedule from the repository root. If the current date falls within the interval between start_date and end_date for the specified branch, the pipeline fails with a freeze status message. Git branch protection adds a second barrier: even if the pipeline didn't trigger, the rule won't allow merging the PR without approval.

Common mistakes when implementing freezes

The first mistake is a freeze without clear lift criteria. The team freezes the code but doesn't define what conditions must be met for unfreezing: zero critical bugs, regression suite passed, product manager approval. Without criteria, the freeze can drag on for weeks. The definition of done for the freeze should be documented and known to every developer.

The second mistake is too many exceptions to the freeze. Each exception (“this PR is not a feature, it's tech debt”) blurs the freeze boundary. If exceptions exceed 20% of the normal PR flow, the freeze doesn't work. The team simply renames features as bug fixes to bypass the block.

The third mistake is ignoring release candidates. If the team doesn't build release candidate builds and deploys directly to production after code freeze, the purpose of the freeze is lost: bugs are discovered by users. Release candidate should be built before code freeze, tested by QA and on staging, and only after quality confirmation is code freeze introduced.

The fourth mistake is the human factor in manual control. A developer might forget to check the freeze status before merging, a release manager might miss a notification. The only reliable solution is automatic blocking at the Git provider or CI/CD level, eliminating human error.