Software development life cycle automation

Your releases lose time to manual steps, team handoffs, email approvals, flaky tests, test environments, tribal knowledge or release windows.

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.

  • Release Check: 5 minutes, no call
  • Built in your own repositories and accounts

Where the time goes

A release takes days. The work takes hours.

The rest is waiting, and it builds up in places like these.

  1. 01

    Manual steps

    Someone runs the release from a checklist and watches every step. It takes hours of attention, and one missed step means a failed release.

  2. 02

    Handoffs between teams

    Build, test, approval and deploy sit with different teams. Every handoff is a queue, and nobody owns the whole release.

  3. 03

    The one person who knows how

    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

What changed at Nike and ASML

Read the cases
  • 600+engineering hours a year back at Nike
  • 300+engineering hours a year back at ASML
  • 900+Nike stores on one self-service upgrade pipeline

Nike

Retail · 900+ stores

Store-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

Read the Nike case

ASML

Semiconductors · lithography systems

Hand-run integration became self-service CI

For the Stage Position Measurement domain, where integration speed and test reliability decide delivery.

  • Integration stepsBefore: run by handAfter: one self-service CI pipeline
  • Release readinessBefore: no single place to judge itAfter: one reporting view of production machine test results
  • CI across teamsBefore: not standardizedAfter: standardized CI flows for multiple teams
Read the ASML case
“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.”
Jon V.Mobile Release Engineer Lead, Nike
“It was a pleasure for the team and me to work with Mateusz and I wouldn’t hesitate to hire him again.”
Maikel JansenGroup leader SW Stage Position and Measurement, ASML

Release Bottleneck Review

Two weeks to settle one release decision

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.

  1. What to fix first next year, and what it is worth.

  2. Whether to hire for platform work or remove the work.

  3. Whether to keep, consolidate or replace your CI/CD tooling.

  4. 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 weeks
  • Your numbers for each release flow, measured from your tools: lead time, hands-on hours, waiting time, handoffs, failed releases and recovery time.
  • Ranked fixes, each with hours a year, cost a year, effort and owner.
  • A two-page decision memo you can forward to your CEO or CFO.
  • A Build blueprint with scope, acceptance criteria and a fixed price. Use it with us, with your own team, or with anyone else.
Price
From €3,500, one release flow
How you pay
Half at signing, half on acceptance

From 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 Review

How to start

Estimate. Measure. Automate.

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.

Every step in detail
  1. Estimate

    Release Check

    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 Check
  2. Measure

    Release Bottleneck Review

    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 Review
  3. Automate

    Self-Service Release Build

    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 Build
  4. Keep it running

    Release Care

    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 Care

Paid on green

The second half of a Build is due when every acceptance criterion passes in your environment. If one fails, we keep working at no extra cost until it passes.

  • Review fees come off the price of a Build signed within 60 days of the decision meeting.
  • Prices exclude VAT.

Inside a Build

One pipeline per release flow, started by your team

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.

  1. Rollback tested

Smoke checks24s

8 of 8 smoke checks passed
Live in production
Illustration: one release flow after a Self-Service Release Build. Click a stage to see its log.
  • Build and tests

    Every change is built and tested the same way, with the slower checks running in parallel.

  • Staging that mirrors production

    The release goes to an environment that mirrors production first, and every stage checks its own result.

  • Approval inside the pipeline

    The people your policy names approve in the pipeline, and the change record is written as they do.

  • Production, with a tested way back

    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
}
Shortened examples. Every Build is written in the tool your team already runs.

Built to be checked

What your change board, security and finance can check

Every Build leaves evidence your organization can inspect without asking us.

  • Criteria signed first

    You sign the acceptance criteria before the build starts. For example: rollback to the previous version in under Y minutes, tested.

  • Approvals in the pipeline

    The approvals your policy requires run inside the pipeline, not in a meeting or a chat thread.

  • A change record per release

    Approval, author, commit and deploy for every production release, retrievable in one place.

  • Signed artifacts and an SBOM

    Signed artifacts and a software bill of materials for every release, plus an audit export.

  • No lock-in

    Built in your repositories and accounts, in tools you already run. No ES.nl software and no license.

  • A team that can change it

    A runbook, training, and a pipeline your team has already changed on its own. Or hand the upkeep to Release Care.

Illustration: one status message per release, updated by the pipeline.

Questions

What engineering leaders ask first

Short answers here. Every step has its own page with the details.

How the four steps work

What is a release flow?

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.

Can we start without a Review?

Yes. The Build’s first week measures your release flows and sets the acceptance criteria. You sign them before the build work starts.

Do we have to buy the Build from you?

No. The Review’s blueprint is yours. Use it with us, with your own team, or with anyone else.

What if a criterion fails?

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.

Our CI tool isn’t Jenkins.

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.

Is our data safe?

Read-only access or exports, under NDA. Exports are deleted after the decision meeting.

Who does the work?

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

Start with your last release

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

Talk to the engineer

Book 30 minutes and bring your last release, or send a message. You talk with Mateusz directly.

Mateusz UlasFounder and platform engineer

    Send us a message

    Leave a message and we'll get back to you.

    Read how we handle your details in our privacy notice.