Nike
Retail · 900+ storesStore-server upgrades became one self-service pipeline
Upgrades ran by hand across five teams, two servers at a time.
Upgrade time per server
Servers upgraded safely at the same time
Software development life cycle automation
We find where the time goes, put a yearly cost on it, and automate the flows that cost the most. In your tools and your repositories, handed to your team.
Where the time goes
The rest is waiting, and it builds up in places like these.
Someone runs the release from a checklist and watches every step. It takes hours of attention, and one missed step means a failed release.
Build, test, approval and deploy sit with different teams. Every handoff is a queue, and nobody owns the whole release.
The full procedure lives with one or two people. When they are busy or on leave, the release waits for them.
Where releases wait in your industry
Results
Nike
Retail · 900+ storesUpgrades ran by hand across five teams, two servers at a time.
Upgrade time per server
Servers upgraded safely at the same time
ASML
Semiconductors · lithography systemsFor the Stage Position Measurement domain, where integration speed and test reliability decide delivery.
“Previously, moving CI workflows between Dev, Staging, and Prod required manual, uncommitted code changes. Mateusz implemented a solution that reduced this to a single line of code, streamlining the process and enabling faster iteration for both developers and our team.”
“It was a pleasure for the team and me to work with Mateusz and I wouldn’t hesitate to hire him again.”
Release Bottleneck Review
In a Release Bottleneck Review, you pick the decision at the kickoff. We measure your release flows from your tools and the people who run them, and put a yearly cost on every option.
What to fix first next year, and what it is worth.
Whether to hire for platform work or remove the work.
Whether to keep, consolidate or replace your CI/CD tooling.
What to change now that AI tools send more changes into the same review and release process.
Why the last one matters now: in a 2025 study of more than 10,000 developers, Faros AI found that teams with high AI adoption merged 98% more pull requests, while review time rose 91% and company-level delivery did not improve.
What you leave with
Two weeksFrom your team: read-only access or exports, 4 to 8 conversations of 30 to 45 minutes, and a sponsor at the kickoff and the decision meeting.
See the ReviewHow to start
Start free, then pay for a measured decision, then for the build. Every price is published, and half of every project fee is paid on acceptance.
Estimate
What your last release cost a year, where the time went, and three fixes. From your own answers.
Free · 5 minutes
11 questions, no call
Take the Release CheckMeasure
The same numbers measured from your systems, and a decision with its cost.
From €3,500 · Two weeks
Read-only access and 4 to 8 short conversations
See the ReviewAutomate
Pipelines your team starts and rolls back, accepted against criteria you sign before the work starts.
From €14,500 · 4 to 8 weeks
An owner per release flow, and 3 to 4 hours a week from one engineer
See the BuildKeep it running
Upgrades, patches and dependency updates, with a monthly report and review.
From €2,500 a month
Optional. First three months fixed, then monthly.
See Release CareInside a Build
A Self-Service Release Build turns every manual step into a stage that checks its own result. The pipeline is written in the tool you already run and lives in your repository. Any engineer on the team can start a release and roll it back.
checkout-service release 2.14
Run #418 · main · started by a developer
RunningWaiting for approvalLive in productionRolled back to 2.13
Try it: start a release, approve it as the change board, or make the smoke checks fail and watch the rollback.
Smoke checks24s
8 of 8 smoke checks passed
Live in production
Every change is built and tested the same way, with the slower checks running in parallel.
The release goes to an environment that mirrors production first, and every stage checks its own result.
The people your policy names approve in the pipeline, and the change record is written as they do.
Checks run after every deploy, and rollback to the previous version is tested before go-live.
Jenkinsfile
pipeline {
agent any
stages {
stage('Build') {
steps { sh 'make build' }
}
stage('Tests') {
parallel {
stage('Unit tests') {
steps { sh 'make test' }
}
stage('Security scan') {
steps { sh 'make scan' }
}
}
}
stage('Deploy to staging') {
steps { sh './deploy.sh staging' }
}
stage('Approval') {
steps {
input message: 'Go to production?',
submitter: 'change-board'
}
}
stage('Deploy to production') {
steps { sh './deploy.sh production' }
}
}
post { always { sh './change-record.sh' } }
}
.github/workflows/release.yml
name: release
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: make build test scan
staging:
needs: build
runs-on: ubuntu-latest
environment: staging
steps:
- uses: actions/checkout@v4
- run: ./deploy.sh staging
production:
needs: staging
runs-on: ubuntu-latest
# required reviewers: change board
environment: production
steps:
- uses: actions/checkout@v4
- run: ./deploy.sh production
- run: ./change-record.sh
environments.tf
# One module for staging and production,
# so staging mirrors production.
module "staging" {
source = "./modules/service"
name = "checkout-service"
environment = "staging"
instance_type = "t3.medium"
min_size = 2
}
module "production" {
source = "./modules/service"
name = "checkout-service"
environment = "production"
instance_type = "t3.medium"
min_size = 4
}
Built to be checked
Every Build leaves evidence your organization can inspect without asking us.
You sign the acceptance criteria before the build starts. For example: rollback to the previous version in under Y minutes, tested.
The approvals your policy requires run inside the pipeline, not in a meeting or a chat thread.
Approval, author, commit and deploy for every production release, retrievable in one place.
Signed artifacts and a software bill of materials for every release, plus an audit export.
Built in your repositories and accounts, in tools you already run. No ES.nl software and no license.
A runbook, training, and a pipeline your team has already changed on its own. Or hand the upkeep to Release Care.
releasesone message per release
Release pipeline09:42edited 10:01
checkout-service 2.14, started by a developer
RunningWaiting for approvalLiveRollback testedChange record CHG-2041
Questions
Short answers here. Every step has its own page with the details.
One path from merge to production: one pipeline and one way of deploying. Services that ship through the same pipeline count as one flow. A web app and its API deployed together are one flow; an iOS app shipped through the App Store is another.
Yes. The Build’s first week measures your release flows and sets the acceptance criteria. You sign them before the build work starts.
No. The Review’s blueprint is yours. Use it with us, with your own team, or with anyone else.
We keep working at no extra cost until it passes. The second half of the Build fee is due only when every criterion passes in your environment.
Pipelines are built in the tool you run. Where a tool is outside our hands-on stack, a partner engineer who uses it daily builds that flow, and we review every change.
Read-only access or exports, under NDA. Exports are deleted after the decision meeting.
We design it, build the core and review every change. Partner engineers work under the same NDA. You work directly with Mateusz, the engineer who delivered the Nike and ASML results.
Where to start
The free Release Check shows where your last release spent its time and what that costs a year, in under 5 minutes and without a call.
Contact
Book 30 minutes and bring your last release, or send a message. You talk with Mateusz directly.