Release Management

Releases that are planned, visible and easy to reverse.

We run the process around your releases: what is going out, when, who approved it and how to undo it. Product, engineering and support all see the same calendar, and launches stop being a source of stress.

The problem

Why releases cause trouble.

01

Nobody knows what is shipping

Support learns about a change from customers, and product finds out a feature slipped on launch day.

02

Approvals that slow everything down

Change boards meet weekly and review every change the same way, whether it is a typo or a database migration.

03

Big-bang releases

Weeks of changes go out at once, so when something breaks it is hard to tell which change caused it.

04

Regulated change, handled by hand

Audit evidence for approvals and testing is collected after the fact from emails and chat threads.

What we deliver

A release process people follow.

We match the weight of the process to the risk of the change, and keep the record as we go.

01

Release planning and calendars

A shared calendar of releases, freezes and dependencies across teams, kept current every week.

  • Calendars
  • Freezes
  • Dependencies
02

Change management

Risk-based approvals, so routine changes move quickly and risky ones get the review they need.

  • Change mgmt
  • CAB
  • Risk tiers
03

Feature flags

Flags to separate deploying code from releasing features, with a process for cleaning up old flags.

  • Feature flags
  • Dark launches
  • Clean-up
04

Canary and phased rollouts

Releases that go to a small share of users first, with health checks before they reach everyone.

  • Canary
  • Phased rollout
  • Health checks
05

Release notes and communication

Clear notes for support, sales and customers, written and sent as part of the release, not after it.

  • Release notes
  • Comms
  • Changelogs
06

Audit-ready records

Approvals, test results and deploy history captured automatically for internal and external audits.

  • Audit trail
  • Evidence
  • Traceability

How we deliver

From current process to calm releases.

We start with how releases work today and change the process step by step.

Always included

  • A named service manager and a clear escalation matrix
  • A monthly service review with SLA reporting
  • Runbooks and documentation that you own
  • Access through your SSO with audit trails, and an NDA and DPA as standard

Typical tools

  • Jira
  • ServiceNow
  • LaunchDarkly
  • Unleash
  • ArgoCD
  • Argo Rollouts
  • GitHub Actions
01
Weeks 1 to 2

Assess

We map how changes reach production and who is involved.

  • Release, approval and freeze process review
  • Recent failed or delayed releases examined
  • Audit and regulatory needs confirmed
02
Weeks 2 to 6

Transition

We take over release coordination with your teams.

  • Shared release calendar in your tools
  • Risk tiers and approval rules agreed
  • Release runbooks and rollback steps written
03
Months 2 to 3

Stabilise

Releases become smaller, more frequent and better recorded.

  • Feature flags for higher-risk launches
  • Canary rollouts for critical services
  • Approval and test evidence captured automatically
04
Ongoing

Optimise

We keep reducing the effort and risk of each release.

  • Monthly review of release outcomes
  • Approval steps removed where they add no value
  • Old flags and manual steps cleaned up

FAQ

Questions we hear a lot.

Do you replace our change advisory board?
Not necessarily. We usually keep a board for high-risk changes and move routine, low-risk changes to pre-approved paths. The board then spends its time on the changes that need it.
Can release management work for regulated businesses?
Yes. We set up approvals, testing evidence and deploy history so they are recorded as part of the release, which makes internal and regulatory audits easier to prepare for.
Do we need feature flags?
Not for everything. Flags help most for larger features, gradual rollouts and changes you may need to switch off quickly. We help you decide where they are worth it and how to clean them up.
How do the engagement models work for release management?
Fully managed means we run release coordination end to end. Co-managed means we work alongside your release or engineering managers, often taking the calendar, approvals and communication. On-demand pods suit a one-off project, such as hardening releases before a major launch.
How do you work with our existing tools?
We use your ticketing, CI/CD and communication tools. Where something is missing, such as a feature flag service, we recommend options and set up the one you choose.

Talk to a founder about Release Management.

Tell us where you are. We will come back within one business day with a point of view, not a sales deck.