Agile Development & Delivery
Code to production. Multiple times a day. Without drama.
We design engineering practice and delivery mechanics so fast shipping is no longer heroism. Tool-neutral, aligned with your stack, focused on the team that has to work with it.
Book a free introductory call30 minutes. We get to know each other. You decide if it fits.
Current state
You might recognise this.
Releases are rare, risky and manual.
Release day has more drama than a feature launch deserves. Code piles up for weeks because no one knows what's in it anymore. The people involved gather on Friday evening, hoping to still rescue the weekend. What doesn't make it on Friday gets redone on Monday.
Tests are unreliable.
Tests are written more out of duty than out of trust. When a test fails, the first question isn't "what did we break?", but "is the test broken again?". Bugs land in production instead of dying in the sprint.
Dev and ops don't talk.
Development throws tickets over the wall, operations throws them back. "It works on my machine" is the unspoken default answer. Hotfixes are more frequent than planned features, and no one feels responsible for the overall result.
Fast and safe delivery is not luck and not heroism. It comes from engineering practice that goes beyond tools: CI/CD discipline, test trust, ops bridge and architecture that reduces deployment risk. That's exactly where our work starts.
Our approach
Three steps. Pragmatic. As equals.
Understand first what actually happens in engineering daily life. Then design.
Understand
We get to know your engineering practice. Pipelines, test strategy, release process, ops routine, team dynamics. What works, what gets lived badly despite the standard, where the real friction sits. We talk to developers, not just to management.
Day 1 to Week 3
Set practices and pipelines anew
We design the engineering practice that fits your team and stack. CI/CD discipline, test strategy, release strategy, ops bridge. We recommend tools that fit your reality, not our comfort zone.
Week 3 to 10
Accompany and hand over
We support the implementation, mentor engineering leads, review pipelines and practice. When your team can carry it forward, we step back.
From Week 10, as long as you need
You know your release process has more drama than necessary.
Spend 30 minutes with someone who has walked that path themselves.
Areas of focus
Where we focus.
CI/CD and build pipelines
CI/CD is the foundation on which fast and safe delivery stands. We build pipelines fast enough that developers don't bypass them, and robust enough that the team trusts them. Tool-neutral, aligned with your stack.
Test strategy and test automation
Test pyramid instead of ice cream cone, clear accountabilities between unit, integration and end-to-end tests, tests that fail when they should and pass when they should. Trust in the test suite is the precondition for frequent deployment.
DevOps and site reliability
The bridge between development and operations. SLOs instead of vague uptime promises, observability instead of log digging, runbooks instead of heroism. We build the practice in which operations topics flow back into engineering, instead of flooding the pager rota at night.
Release strategies
Blue-green, canary, feature flags, progressive delivery. Which strategy fits which situation depends on risk profile, architecture and team maturity. We choose the approach that fits your context, instead of copying the next conference talk pattern.
Engineering practices
Code review, trunk-based development, pair programming, pull-request discipline, architecture decision records. Practices that lift quality and speed simultaneously, when they fit the team culture instead of being imposed from above.
Developer experience and platform engineering
When developers need half a day to get a local environment running, that's lost engineering time. We design developer experience and internal platforms that reduce friction and accelerate onboarding.
Why DRICH.CONSULTING
Engineering practice that has carried. Not from a conference talk.
Fast delivery doesn't come from tools, it comes from practice. I've worked as a software developer, architect, IT project lead and Chief Data Officer. I've been accountable for production systems where a failed Friday-evening release could cost the weekend, and I've helped turn that into a practice where multiple deployments per day run without drama.
Hands-on engineering practice
I've supported companies in moving from biweekly release drama to multiple deployments per day, without downtime and without Friday-evening ops marathons. That doesn't come from tools, but from engineering practice: CI/CD discipline, test trust, feature flags and architecture that reduces deployment risk.
Tool-neutral, practice-focused
GitHub Actions, GitLab CI, Jenkins, Azure DevOps, AWS-native tools, whatever fits your stack. We don't recommend a tool because we like it, but because it fits your team, your architecture and your roadmap. Tool religion is a luxury engineering teams rarely afford.
Both worlds: startup speed and enterprise compliance
Fast delivery in startup reality looks different from safe delivery in regulated industries. We've supported both worlds and know where compliance requirements change engineering practices without destroying them.
100 percent independent
No tool commissions, no cloud partnerships, no implementation follow-on business. Particularly important in engineering consulting, because tool decisions set cost trajectories and lock-in for years.
20+
years of
engineering practice
★
own accountability for
production systems
100%
independent,
tool-neutral
→
from commit to
happy customer
Frequently asked
What decision-makers ask us.
Tool-focused consultancies often earn through licence or implementation partnerships. We are tool-neutral. We don't recommend the next trend tool, but the engineering practice that fits your team. That changes the recommendations.
Almost everyone has CI/CD. The question is whether it works: do you really deploy often? Are the pipelines fast enough that the team doesn't bypass them? Does the team trust the tests? If not, that's where we start.
It depends on your stack. We work with GitHub Actions, GitLab CI, Jenkins, Azure DevOps, AWS-native tools and many others. We recommend the tool that fits your team, your architecture and your roadmap, not the one we like working with most.
No, and we don't pretend otherwise. 30 minutes are enough to roughly understand your situation and to tell you honestly whether we're the right partner. If we're not, we say so. If we are, we suggest a sensible next step, which isn't automatically a paid engagement.
Initial improvements often in four to eight weeks, because many engineering topics give fast feedback. Deeper changes (test culture, release discipline) take three to six months, because trust takes time. A real engineering maturity transformation rather six to twelve months.
Yes, per mandate. We can take over engineering lead functions on time, accompany critical refactoring initiatives or build platform teams. Permanent placement isn't our model, operational takeover on time works.
Introductory call
Free introductory call
Tell us your situation. We listen, ask questions and tell you honestly whether we're the right partner. If we aren't, that's fine too.
- 30 minutes. No pitch, no presentation.
- You describe the problem. We listen first.
- You get an initial read, with no sales intent.
- No commitment afterwards.
Slots are offered on weekdays between 9am and 6pm (CET).
Release day with too much drama?
Book a free introductory call