After the launch is when it really starts

Hosting on servers in Germany, monitoring, backups including a tested restore, and regular updates to the system, its extensions and its dependencies form the basis. On top of that come support with fixed response times and an allowance for small changes, so not every adjustment needs its own quote. Most successful attacks exploit gaps that were fixed long ago – which is why applying updates is the most effective protection.

Yes, and that is often the more sensible moment. We look at the condition: version levels, open security gaps, dependencies, backups, loading time and the question of who is actually responsible in an emergency. From that comes a prioritised list with effort and risk. Small improvements at a steady pace are cheaper and less risky than a relaunch every five years.

Yes. We add to an existing team rather than replacing it: reviews, a second opinion on architecture decisions, covering peaks or topics where the specialist knowledge is missing internally. We define responsibilities in advance, so it is clear who responds when something breaks. On request we train your editorial team so text changes are possible without us.

Yes, after reviewing their condition. We look at the code, the hosting, the updates and the documentation and say openly what has to be done first and what we cannot take responsibility for. With abandoned projects or agencies that can no longer be reached, we first sort out access, backups and operability before we talk about further development.