Everyone comes across it sooner or later, whether you work with an in-house IT team or an external partner: you want to develop a new tool or adapt an existing digital environment. You spend time on a clear briefing, align everything thoroughly, and development gets underway.
There's coding, programming, testing… and eventually, hopefully within budget and timeline, the release to the test environment follows. Yes! It works…
Go Live – And Then?
Next comes the exciting phase: going live in the production environment. Everything seems fine, until the first feedback comes in. Colleagues, customers, or suppliers report that something is going wrong:
- Data isn't coming through correctly.
- Functionalities aren't working the way they used to.
- Design elements have been unintentionally altered.
In other words: despite a successful testing phase, something still goes wrong after the release. Hopefully it's not a business-critical issue — but what if it is?
Fix First, Then Point Fingers?
If the working relationship is solid, the focus is first on solving the problem. In the worst case, the release is rolled back; in the best case, a patch follows quickly. But meanwhile, damage has been done: lost time, costs, reputational harm. And then comes the inevitable question:
Who is responsible?
- Was there insufficient testing?
- Was the impact of the change underestimated?
- Could it have been avoided?
Responsibilities: A Realistic View
As CEO, product owner, or digital manager, you're the one who gives the final 'go.' But can you really oversee every impact? Is it realistic, as the client, to test the entire platform every single time?
The answer is: no. And it doesn't have to be that way. What you can expect is that your technical partner takes responsibility for:
- robust code;
- a sound architecture;
- regression testing;
- and a testing process that safeguards stability.
They are responsible for the technical quality. Your role is to set clear requirements and organize processes so that errors can be prevented.
Practical Guidelines for Fewer Bugs
Below are some concrete guidelines that significantly reduce the risk of bugs after release:
- Start with an airtight briefing Describe what you want, why you want it, and what impact it has on existing processes. Involve stakeholders in any changes.
- Identify business-critical processes Make sure these are tested with every release, no matter how small.
- Work with separate environments Development, staging/test, and production must be strictly separated.
- Use clear release notes Version control and documentation help to spot regressions faster.
- Plan releases thoughtfully Avoid going live right before weekends or holidays.
- Lock agreements down contractually Clear SLAs ensure swift action and clear responsibilities.
- Set up monitoring and alerts Use tools to automatically detect error messages and downtime.
- Automate testing wherever possible
- Unit tests for small components
- Integration tests for interaction between modules
- End-to-end tests for the full user flow
Automation makes regression testing faster, cheaper, and more consistent.
- Conduct peer reviews or code reviews Have developers review each other's work. This raises code quality and catches errors early on.
- Use feature toggles (feature flags) Only activate new functionality once you're sure of it. This also allows you to quickly disable features in case of problems without having to roll back the entire release.
- Implement rollback mechanisms Provide a technical path to quickly revert to a previous version. Use CI/CD pipelines for automated deployments and rollbacks.
- Run load testing and performance testing Make sure your platform not only works but also performs well under pressure. Spikes in traffic shouldn't deliver any surprises.
- Use a bug tracking system Structurally following up on bugs helps you recognize patterns and prevent recurrence. Analyze the cause and impact of every incident.
- Gather structured feedback after releases Short internal or external feedback rounds after going live surface invisible issues that would otherwise quietly fester.
So… Who Is Responsible?
If all precautions have been taken, and something still goes wrong? Then the responsibility lies with the technical party. Not because errors are unthinkable, but because they're often avoidable — with the right approach, tooling, and quality standards.
