Developer experience and delivery
Faster local setup, CI/CD your team trusts, end-to-end tests that catch regressions, and code standards that enforce themselves.
The problem
New engineers need days to get the project running. CI is slow or flaky, so people re-run it until it’s green. Releases are manual, so they happen rarely and they’re scary. None of it is anyone’s fault, and none of it is on the roadmap, so it never gets fixed.
How I approach it
- Local setup in minutes: containerised or tool-managed environments (Docker, mise) and scripts that automate the monorepo chores.
- A pipeline people trust: fast, reproducible CI with one-click or automatic releases.
- Tests where they pay off: end-to-end coverage with Playwright for the flows that matter, ahead of every release.
- Standards in the tooling: pre-commit checks and CI rules, so code review is about design.
What it looks like
Usually a fixed-scope project, or part of a fractional tech lead engagement. I’ve cut new developer setup from days to minutes and turned manual deploys into one-click releases across backend, frontend and Android teams.
Questions
- How do we know it worked?
- We measure before and after: time to set up a new laptop, time from merge to production, how often releases go out, and how often they break something.
- Do we have to change our tools?
- Rarely. Most of the wins come from automating and tightening what you already use, whether that's GitHub Actions, GitLab CI or Jenkins.
- Is this worth it for a small team?
- Especially then. On a team of five, a day lost to a broken local setup or a flaky pipeline is a big part of your week.
Does this sound like your team?
Based in Slovenia. Remote-first, working in EU time zones (CET). On-site visits by arrangement.
Book a call30 minutes, free