DevOps Engineering
Most of these projects start the same way: releases done by hand after hours, environments nobody can rebuild, deployment knowledge locked in one head. They end with a repeatable process — CI/CD pipelines, infrastructure described in code and monitoring that reports problems before users do — and with releases nobody holds their breath for.
- Client
- A range of organisations, from small product teams to projects delivered in enterprise environments
Project context
This is not the story of a single product but a cross-section of similar problems that recur from organisation to organisation: deployments done by hand by one person, a server nobody dares to touch, and environments no one can rebuild. This page collects selected engagements from that area.
One approach connects them: the path from commit to production gets automated, the infrastructure is described in code, and monitoring answers the question of what is going on before a customer asks it. Instead of heroics at every release, there is a boring, repeatable process that simply works.
Some of these practices come from enterprise projects — the firm's founder shaped them in environments at PwC, Roche and E.ON — and here they run at a scale that fits smaller teams, without the corporate overhead.
Business challenge
The typical starting point looks alike everywhere: releases are rare and stressful, configuration has drifted apart between environments, the classic works-on-my-machine problem is routine, and defects are discovered by users instead of by the system. Knowledge of how to deploy the application lives in one person's head — which is a business risk, not just an inconvenience.
The real challenge is not the tooling but changing the process without stopping delivery. Automation has to be introduced into a live project, in stages, without freezing development for weeks — and in a way that leaves the team able to run the process on their own after the engagement ends.
Scope of delivery
An engagement of this kind covers designing the solution and putting it into operation: CI/CD pipelines, infrastructure definitions in code, environment configuration and monitoring. We work directly with the developers and the system owners, with no layer of intermediaries and without taking anyone's work away — automation goes into a live project in stages.
The scope also includes what remains after the engagement ends: documentation, transparent definitions in the repository and knowledge-transfer sessions. The process is meant to belong to the client's team — if deployment needs one specific person again once we step away, the work was not finished.
Founder's role
The design and implementation work is carried out personally by the firm's founder, Jakub Zając — pipelines, infrastructure definitions, environment configuration and monitoring — working directly with the client's developers and system owners.
Capabilities involved
- Product and technical analysis
- Turning a wish list into a scope that can be priced and built.
- Solution architecture
- The decisions that are expensive to reverse a year into production.
- Quality engineering
- Knowing what is covered by tests — and what deliberately is not.
- Cloud and DevOps
- Repeatable deployments and environments you can rebuild.
The disciplines this delivery required — a list of disciplines, not of job titles.
Solution
CI/CD pipelines in GitHub Actions
Every code change automatically goes through build, tests and quality checks, and deploying to an environment comes down to an approval. Pipeline definitions live in the repository next to the code, so they go through review and carry a full change history.
Containerisation with Docker
Applications are packaged as Docker images, so the same artefact travels from the developer's machine through testing all the way to production. The works-on-my-machine problem disappears, because exactly the same image runs everywhere.
Infrastructure as code with Terraform
Cloud resources on AWS are described in Terraform: networks, services, permissions and configuration come from code, not from clicking through a console. A new environment can be stood up from the same modules, and every infrastructure change goes through review like ordinary code.
Environments, configuration and secrets
The split between development, staging and production is put in order, with per-environment configuration and secrets kept in dedicated stores rather than in files and chat messages. It becomes clear what runs where, and with which settings.
Monitoring and alerting
Systems get metrics, log collection and alerts, built on Amazon CloudWatch among other tools — configured so a notification reaches the right person with guidance on what to do. The goal is to learn about problems from monitoring, not from customers.
Release and rollback process
Releases become small, frequent and versioned, with a clearly described procedure for returning to the previous version. When rolling back takes minutes and no nerves, the team stops fearing deployments — and, paradoxically, makes fewer mistakes.
Technology stack
CI/CD and automation
- GitHub Actions
- Docker
- Bash
Cloud and infrastructure as code
- AWS
- Terraform
Monitoring and observability
- Amazon CloudWatch
Everyday tooling
- Git
- GitHub
Technical approach
- 01
All automation lives in the repository next to the code — no configuration clicked together in web panels that nobody can later reproduce or audit.
- 02
Terraform from day one, even for small infrastructure. Describing three resources in code costs hours; importing them after a year of manual changes costs weeks.
- 03
An artefact is built once and promoted through the environments — production receives exactly what passed the tests, not the same thing rebuilt one more time.
- 04
Proven, well-documented services win over fashionable novelties. The client's team has to run this process long after the handover, so the barrier to entry matters.
- 05
Alerts are designed for action: each one has an owner and a documented first response step. An alarm that only makes noise teaches the team to ignore alarms.
Quality and reliability
- Permissions follow least privilege: pipelines and services receive exactly the AWS permissions they need — no shared administrator keys.
- Secrets never land in the repository. They live in dedicated secret stores and can be rotated without code changes.
- Environments are isolated from one another — production does not share resources or data with test environments for convenience.
- Infrastructure changes go through code review, which leaves a full audit trail of who changed what, and why.
Outcome
Deployment stops being an event. Releases become routine: small, reversible and doable by any authorised person on the team, not just the one admin.
Environments can be recreated from code — standing up a new environment or rebuilding after a failure is a procedure, not archaeology through hand-configured servers.
The client's team understands and independently maintains the whole process, because it arrives with documentation and knowledge transfer, not as a black box — a system any future team can take over.
Gallery
A GitHub Actions pipeline run (anonymised)
1920×1080 px, AVIF/WebP
Terraform module structure in a repository (anonymised)
1600×1000 px, AVIF/WebP
Monitoring dashboard with metrics and alerts (anonymised)
1920×1080 px, AVIF/WebP
Related services
The scope this project drew on, described in more depth on the service pages.
CI/CD, Docker, Terraform and AWS, so releases become a single click and you hear about failures before your customers do.
We replace copying data between systems, manual reports and retyping documents with scripts and integrations that run on their own.
More work
01Loyalty app and admin platform
IZAPzoo
IZAP, a brick-and-mortar retail chain, wanted its own loyalty programme on customers' phones instead of plastic cards. We designed and built the whole thing — Android and iOS apps, a cloud backend and an admin platform — and store staff now run points, rewards and promotions themselves.
Read the case study
02Private opportunity-discovery tool with AI-assisted analysis
ThomasSeekerAI
A private trader was combing OLX, Otomoto, Allegro and a handful of smaller sites by hand, every day, for things worth reselling. We built an internal tool that takes that work over: searches described in a plain sentence run on a schedule in the background, the noise is filtered out, and what is left is ranked by how good the opportunity looks — hours of manual browsing turned into an automated job.
Read the case study
Let's talk about your project
Happy to walk you through how a similar approach would work in your case — and what we would avoid.