Der beste Livegang ist unspektakulär – wie wir Risiken durch Vorbereitung und kleine Schritte reduzieren
Artikel 3 von 4 aus der Serie „Arbeiten mit punkt.de“
Bei einem Livegang treffen wir uns meistens zu einem festgelegten Zeitpunkt in einem digitalen Raum. Der oder die Product Owner:in geht mit dem Team die Checkliste durch. Wir ändern Konfigurationen, schalten eine Domain um und beobachten das System.
Dann warten wir.
Manche Kund:innen sind überrascht, dass wir nicht aufgeregt durcheinanderlaufen. Für sie ist der Livegang der große Moment, auf den das Projekt lange hingearbeitet hat. Für uns sollte das, was technisch passiert, zu diesem Zeitpunkt schon ziemlich gewöhnlich sein.
Wir freuen uns trotzdem jedes Mal und im besten Fall ist die Livegang-Party auch schon geplant und Kuchen und Sekt stehen bereit.
Lieber früh live als lange fast fertig
Wir versuchen, einen ersten Livegang so früh wie sinnvoll anzusetzen. Diese Haltung ist bei punkt.de nicht neu: Bereits 2015 haben wir über die Vorteile eines Continuous Relaunchs geschrieben. Auch unser damaliger Beitrag in der Computerwoche stellte die Frage, warum der Big-Bang-Relaunch Geschichte sein sollte.
Der Gedanke dahinter ist einfach: Ein neues System muss nicht mit seinem vollständigen, für die nächsten Jahre geplanten Funktionsumfang starten. Es kann mit einem sinnvollen Kern live gehen, echtes Feedback sammeln und sich anschließend weiterentwickeln.
Technisch klingt das logisch. Im Unternehmen ist es oft schwierig.
Wenn ein altes System über Jahre gewachsen ist, besitzt fast jede Abteilung Funktionen, die sie schützen möchte. Mit weniger live zu gehen, fühlt sich dann wie ein Rückschritt an – selbst wenn die vorhandenen Funktionen deutlich besser funktionieren als vorher. Aus vielen nachvollziehbaren Einzelinteressen entsteht schnell wieder ein großer Gesamtumfang.
Wir beraten an dieser Stelle, zeigen Abhängigkeiten und schlagen Ausbaustufen vor. Die Entscheidung bleibt beim Kunden. Nach unserer Erfahrung hatten allerdings gerade diejenigen Kund:innen besonders gute Livegänge, die den Mut zu einem kleineren ersten Schritt aufgebracht haben.
Weniger Funktionen bedeuten nicht automatisch weniger Wert. Wenn die richtigen Funktionen besser sind, können sie früher Nutzen bringen.
Was am Livegang passieren muss, sollte vorher Routine sein
Ein früher Livegang darf kein leichtfertiger Livegang sein. Je kleiner wir den Schritt machen, desto zuverlässiger müssen die notwendigen Abläufe funktionieren.
Unser Ziel ist deshalb, möglichst viel von dem, was am Livegang-Tag passieren muss, in Code zu gießen. Datenmigrationen, Konfigurationen und Deployments sollen reproduzierbar sein. Automatisierte Tests und CI/CD-Prozesse helfen uns dabei, Änderungen kontinuierlich zu prüfen und auszuliefern. Warum das für uns mehr als ein Werkzeugthema ist, beschreiben wir ausführlicher in CI/CD als Kultur.
Ein besonders anschauliches Beispiel war der Relaunch eines Kundenportals mit mehr als 200.000 Angeboten. Diese Daten mussten zuverlässig in das neue System importiert werden. Ein halbes Jahr vor dem Livegang begannen wir deshalb, jede Nacht alle Angebote zu importieren.
Nacht für Nacht lief derselbe Prozess. Wir beobachteten ihn, fanden Engpässe und optimierten den Importer. Dadurch war die entscheidende Datenmigration am Livegang-Tag kein einmaliges Experiment mehr. Es lief einfach noch einmal der Importer – nur diesmal für das Produktivsystem.
Genau diese Art von Langeweile wollen wir beim Livegang erreichen.
Eine Checkliste macht aus vielen Gewerken einen Ablauf
Trotz Automatisierung bleibt ein Livegang eine gemeinsame organisatorische Aufgabe. Die Gesamtverantwortung liegt bei unserem oder unserer Product Owner:in. Dort laufen die einzelnen Aufgaben, Zuständigkeiten und Zeitpunkte zusammen.
Eine reale Checkliste für einen Website-Livegang enthielt beispielsweise:
- Redirects einpflegen,
- Inhalte und Termine in das Produktivsystem übertragen,
- Datenschutzerklärung und Impressum prüfen,
- Serverkonfiguration und Cronjobs umstellen,
- zu einem festgelegten Zeitpunkt die Domain umschalten,
- direkt danach Kontaktformular und Suche testen,
- den Suchindex neu aufbauen,
- den Eingang von Matomo-Daten prüfen,
- SEO, Performance, Web Vitals und Barrierefreiheit kontrollieren.
Die Liste zeigt, warum ein Livegang keine rein technische Angelegenheit ist. Infrastruktur und Anwendung gehören ebenso dazu wie Inhalte, Datenschutz, Analytics, Auffindbarkeit und Nutzererlebnis.
Der oder die Product Owner:in hält den Ablauf zusammen. Zu einem vereinbarten Zeitpunkt treffen sich die Beteiligten in einem digitalen Raum, arbeiten die relevanten Schritte ab und teilen ihren Status. Viele Handgriffe bestehen dann tatsächlich darin, vorbereitete Konfigurationen zu aktivieren – und anschließend aufmerksam zu beobachten.
Ruhe am Livegang-Tag ist kein Zeichen dafür, dass wenig passiert. Sie ist das Ergebnis erfolgreicher Arbeit im Vorfeld!
Nach dem Umschalten beginnt das echte Feedback
Auch ein gründlich getestetes System trifft erst nach dem Livegang auf seinen vollständigen Alltag. Dann arbeiten echte Nutzer:innen mit echten Daten, Gewohnheiten und Erwartungen. Dass dabei neue Themen sichtbar werden, ist normal.
Kritische technische Fehler sollten uns nicht zuerst von Nutzer:innen gemeldet werden. Dafür investieren wir in Testing und Monitoring. Wenn ein wichtiger Dienst ausfällt oder sich ein technisches Problem abzeichnet, soll unser Team es selbst erkennen und reagieren.
Bei Nutzerfeedback ist die Lage weniger eindeutig. In manchen Projekten bauen wir einen Feedback-Button ein, über den Rückmeldungen direkt bei uns landen. In anderen unterstützen wir die Ansprechpartner:innen des Kunden dabei, Hinweise aus verschiedenen Kanälen zu sammeln und zu strukturieren.
In den ersten Tagen und Wochen müssen der Kunde und unser Product Owner:in diese Rückmeldungen gemeinsam einordnen:
- Ist das ein Fehler, der schnell behoben werden muss?
- Ist die Bedienung tatsächlich unklar?
- Ist die Reaktion Teil der normalen Gewöhnung an ein neues System?
- Ist es eine gute Idee für eine spätere Ausbaustufe?
Nicht jede Irritation sollte sofort eine Änderung auslösen. Aber „Die Nutzer:innen müssen sich nur daran gewöhnen“ darf auch keine Ausrede sein, berechtigtes Feedback zu ignorieren. Diese Unterscheidung braucht Erfahrung, Gespräch und manchmal etwas Zeit.
Nach dem Projekt ist vor der dauerhaften Entwicklung
Nach der intensiveren Livegang-Phase geht das System in die dauerhafte Betreuung über. Diese besteht bei uns meist aus drei Bausteinen.
1. Wartung und Pflege
Wir halten Infrastruktur, Software und angebundene Systeme aktuell. Updates, Upgrades, Sicherheitsmaßnahmen und technisches Monitoring sorgen dafür, dass die Anwendung stabil und betreibbar bleibt.
2. Support und Hilfe
Wir unterstützen dort, wo das System im Alltag auf Menschen und Organisation trifft: beim Redaktionssupport, bei kleineren Bedienungsproblemen oder auch bei der technischen Begleitung einer Kampagne. Nicht jedes Anliegen ist ein Entwicklungsprojekt. Es braucht trotzdem jemanden, der das System kennt und helfen kann.
3. Weiterentwicklung
Größere Ausbaustufen planen und budgetieren wir häufig als eigene Vorhaben. Zusätzlich benötigt eine Anwendung ein gewisses Budgetgrundrauschen. Es ermöglicht dem Product Owner:in und den festen Ansprechpartner:innen, kleinere Verbesserungen umzusetzen, Feedback aufzunehmen und die Entwicklung des Systems im Blick zu behalten.
Keine Software, die man heutzutage baut, ist fertig.
Ohne dieses kontinuierliche Budget veraltet sie erstaunlich schnell. Oft bleiben schon kleine Verbesserungen im Ablauf liegen. Für sich genommen wirken sie vielleicht nicht kritisch. In der Summe werden sie zu täglicher Reibung. Die Zufriedenheit sinkt – bei den Nutzer:innen, beim Kunden und irgendwann auch im Projektteam.
Wer Weiterentwicklung lange genug aufschiebt, landet schließlich wieder bei einem großen Relaunch. Genau bei dem Zustand also, den ein Continuous Relaunch vermeiden soll.
Livegang ist ein Übergang, kein Endpunkt
Ein guter Livegang verbindet drei Dinge: eine bewusst begrenzte erste Version, technisch wiederholbare Abläufe und ein Team, das auch danach verantwortlich bleibt.
Manchmal gibt es vor dem Termin trotzdem stressige Phasen. Wir möchten das nicht romantisieren. Komplexe Systeme, viele Beteiligte und feste Termine lassen sich nicht immer vollständig entspannen. Aber Crunch-Time ist für uns kein Qualitätsmerkmal. Wenn am Livegang-Tag alle hektisch improvisieren müssen, ist vorher etwas schiefgelaufen.
Unser Ideal sieht anders aus: Wir schalten um, prüfen, beobachten – und freuen uns gemeinsam. Am nächsten Tag arbeiten wir weiter.
Weiterlesen: Im (noch unveröffentlichten) vierten Teil dieser Serie geht es um Projekte mit besonderen Rahmenbedingungen und darum, wie wir bei unseren Spezialistenprojekten unsere Kompetenzen, Partner und Erfahrungen zusammenbringen.
Vorher lesen: Im zweiten Teil dieser Serie ging es darum, wie die Zusammenarbeit im laufenden Projekt konkret aussieht: wie wir unsere Projektumgebung aufbauen, gemeinsam priorisieren, Aufgaben übergeben und für Budgettransparenz sorgen.
punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de
Geschäftsführer
Telefon: +49 (721) 9109-124
E-Mail: stein@punkt.de
Keine Blackbox: Warum das Projekt unseren Kund:innen gehört
Artikel 2 von 4 aus der Serie „Arbeiten mit punkt.de“
Ich finde, eine faire Agenturbeziehung erkennt man an einer unangenehmen Frage: Was passiert, wenn der Kunde morgen sagt, dass er das Projekt beenden möchte?
Bei uns kann er alles mitnehmen, was bis dahin entstanden ist: Code, Tickets, Dokumentation, Entscheidungen und den aktuellen Arbeitsstand. Viele unserer Kund:innen haben deshalb nicht nur Zugriff auf Jira und Confluence, sondern auch direkt auf GitLab. Sie können verfolgen, wie sich der Code entwickelt – und sind nicht darauf angewiesen, dass wir ihnen den Stand des Projekts erklären.
Natürlich beginnen wir kein Projekt mit dem Ziel, es vorzeitig zu beenden. Viele unserer Kunden arbeiten über Jahre mit demselben punkt.de-Team zusammen. Aber genau diese Freiheit gehört für uns zu einer vertrauensvollen Partnerschaft: Das Projekt gehört dem Kunden, nicht der Agentur.
Im ersten Teil dieser Serie ging es darum, wie wir über den Punktlandungsworkshop und das Strategiepapier zu einem gemeinsamen Projektverständnis kommen. Jetzt wird daraus tägliche Zusammenarbeit.
Vom Strategiepapier zu einem steuerbaren Projekt
Nach der Beauftragung übersetzen unsere Product Owner:innen das Strategiepapier in zwei Strukturen: Epics für die inhaltliche Arbeit und Budgettöpfe für das Controlling.
Vorher findet ein interner Workshop mit dem zukünftigen Projektteam und den beteiligten Berater:innen statt. Dort werden nicht einfach Dokumente übergeben. Es geht um die Informationen zwischen den Zeilen:
- Welches Ziel ist für den Kunden entscheidend?
- Welches Feature muss besonders intelligent gelöst werden?
- Wo genügt ein pragmatischer erster Schritt?
- Wer entscheidet auf Kundenseite – und welche Vorgeschichte sollte das Team kennen?
Aus diesem Wissen schneiden der oder die Product Owner:in und das Team die ersten Epics und legen sie in Jira an. Der Kunde hat über den initialen Workshop bereits an ihrer Grundlage mitgearbeitet und sieht anschließend die konkrete Struktur. Korrekturen sind möglich, große Neuschnitte aber selten nötig.
Wir konzipieren zu diesem Zeitpunkt bewusst nicht jedes Detail bis zum Projektende. Die Epics geben Richtung und Zusammenhang. Die konkrete Ausarbeitung erfolgt dann, wenn ein Bereich tatsächlich näher an die Umsetzung rückt. So planen wir nicht monatelang an Erkenntnissen vorbei, die erst während der Arbeit entstehen.
Budgettöpfe sind ein Frühwarnsystem, kein Dogma
Auch Budgettransparenz braucht den richtigen Detailgrad. Ein einziger Topf für das Gesamtprojekt ist zu grob: Man erkennt erst spät, wo etwas aus dem Plan läuft. Dutzende kleine Positionen sind nicht automatisch besser. Im schlimmsten Fall verschwindet das eigentliche Problem in einer großen Datenmenge.
Deshalb teilen wir das angebotene Budget in wenige aussagekräftige Töpfe. Ab dem ersten Monat sieht der Kunde regelmäßig, wie viel in jedem Bereich vorgesehen und wie viel bereits verbraucht ist.
Diese Aufteilung ist ein Controlling-Instrument, kein Korsett. Läuft ein Topf schneller leer, betrachten wir zunächst die anderen. Vielleicht gleicht sich die Entwicklung im Gesamtprojekt aus. Wenn mehrere Töpfe deutlich schneller Budget verbrauchen, muss das Team reagieren. Dafür gibt es drei Stellschrauben:
- Wir verändern den Scope.
- Wir verbessern oder verändern Prozesse.
- Wir sprechen über zusätzliches Budget.
Keine davon ist automatisch angenehm. Aber alle drei sind besser, als eine Abweichung erst kurz vor Projektende zu entdecken.
Dieselben Tickets. Dieselbe Dokumentation. Derselbe Code.
Der Kunde erhält Zugriff auf das Jira-Board, auf dem auch wir arbeiten. Dort liegen operative und technische Tickets – nicht nur eine aufbereitete Auswahl für den nächsten Statusbericht.
Dasselbe gilt für Confluence: Protokolle, Entscheidungen und Dokumentation entstehen in einem gemeinsamen Projektraum. In vielen Projekten kommt GitLab hinzu. Der Kunde kann sehen, woran entwickelt wird, welche Änderungen in den Code einfließen und was bis zu diesem Zeitpunkt tatsächlich entstanden ist.
Niemand muss jedes Ticket lesen oder jeden Commit prüfen. Manche Kund:innen möchten tief einsteigen, andere konzentrieren sich auf fachliche Entscheidungen. Beides ist möglich. Der Grad der Mitarbeit ist verschiebbar, der Zugang zu den Informationen nicht.
Das hat einen sehr praktischen Effekt: Wenn Ansprechpartner:innen wechseln, Wissen übergeben werden muss oder die Zusammenarbeit endet, fängt der Kunde nicht bei null an. Der Projektstand steckt nicht nur in den Köpfen unserer Entwickler:innen und auch nicht in einem internen System, das wir allein kontrollieren.
Für uns ist das gelebte digitale Souveränität: nicht als abstraktes Versprechen, sondern als konkrete Möglichkeit, informiert zu entscheiden und handlungsfähig zu bleiben.
Ein Projektmanifest macht Prioritäten entscheidbar
Tickets sagen, was zu tun ist. Sie beantworten aber nicht automatisch, woran sich eine gute Entscheidung orientiert. Deshalb entwickeln wir mit dem Projektteam möglichst früh ein Projektmanifest.
Darin halten wir wenige Leitsätze fest, die die gemeinsame Richtung beschreiben. Bei einer späteren Entscheidung können wir fragen: Passt sie zu unserem Manifest?
Wenn nicht, gibt es zwei legitime Möglichkeiten. Wir verändern die Entscheidung. Oder wir passen das Manifest an, weil sich die Rahmenbedingungen oder unsere Erkenntnisse verändert haben. Wichtig ist, dass der Widerspruch sichtbar wird und die Kursänderung bewusst erfolgt.
Unsere Kolleg:innen von made in zeigen ausführlich, wie ein Projektmanifest gemeinsam entwickelt wird. Für uns ist es kein feierliches Dokument für die Ablage. Es ist eine Abkürzung für die schwierigen Diskussionen im Projektalltag.
Zusammenarbeit hat einen Rhythmus
Ein gemeinsames Board allein schafft noch keine gute Kommunikation. Ab Projektbeginn sprechen wir deshalb mindestens alle zwei Wochen in einem Jour fixe mit dem Kunden. In großen Projekten wird die Zusammenarbeit enger: Dann nehmen Kund:innen auch an Scrum-Events teil, in intensiven Phasen teilweise sogar an Dailys.
Dazwischen nutzen wir, was für die Situation sinnvoll ist. Kurze Rückfragen laufen häufig per Chat zwischen Product Owner:in und Kunde. Konkrete Aufgaben gehören ins Ticket. Komplexe oder dringende Fragen klären wir am Telefon oder im Videocall.
Entscheidend ist nicht, jeden Austausch in einen Prozess zu zwingen. Entscheidend ist, dass Fragen schnell bei den richtigen Menschen landen und relevante Ergebnisse anschließend für das Team nachvollziehbar sind.
Funktion für Funktion statt Überraschung am Ende
Neue Funktionalitäten übergeben wir einzeln auf einem Staging-System und bitten den Kunden um Abnahme. Vor dem ersten Livegang existiert meist zunächst nur diese geschützte Umgebung; später stehen Staging und Produktivsystem nebeneinander.
Die einzelne Abnahme verkürzt die Feedbackschleife. Wenn eine Funktion anders verstanden wurde oder sich in der Benutzung nicht richtig anfühlt, merken wir das früh. Wir entwickeln nicht über Monate ein großes Bündel und stellen dann fest, dass wir gemeinsam in die falsche Richtung gelaufen sind.
Das erfordert Mitarbeit auf Kundenseite. Nicht jede technische Entscheidung muss dort getroffen werden. Aber fachliches Feedback können wir nicht durch Agenturwissen ersetzen.
Probleme gehören auf den Tisch
Auch mit Budgettöpfen, Jour fixes und kurzen Abnahmeschleifen läuft ein komplexes Projekt nicht immer wie geplant. Der Unterschied ist: Abweichungen entstehen normalerweise nicht über Nacht. Beide Seiten können sehen, wie sie sich entwickeln.
Das operative Team versucht zunächst, gemeinsam nachzusteuern. Reicht diese Ebene nicht aus, gibt es in vielen Projekten ein Steering Board. Dann schauen wir mit der Managementseite des Kunden auf die Situation und entscheiden über Scope, Prozesse, Zusammenarbeit oder Budget.
Manchmal komme auch ich als zusätzliche Eskalationsstufe dazu. Nicht, um die Verantwortung des Teams zu übernehmen, sondern um eine festgefahrene Situation aus einer anderen Perspektive zu betrachten und gemeinsam mit dem Kundenmanagement wieder entscheidungsfähig zu werden.
Das gehört für mich zu dem Anspruch, den wir in unserem Loveletter formulieren: erfrischend direkt, ehrlich und bodenständig. Ehrlichkeit beweist sich nicht, solange alles grün ist. Sondern dann, wenn man eine schwierige Entwicklung früh anspricht.
Freiheit schafft Vertrauen
Unsere Kund:innen sollen wissen, woran wir arbeiten, wie sich das Budget entwickelt und welche Entscheidungen anstehen. Sie sollen sich beteiligen können, ohne jedes technische Detail selbst steuern zu müssen. Und sie sollen jederzeit auf das zugreifen können, was in ihrem Auftrag entstanden ist.
Das klingt zunächst wie eine Absicherung für das Ende einer Zusammenarbeit. In der Praxis ist es für uns eine Grundlage für lange Partnerschaften. Wer bleiben muss, weil Wissen, Code oder Dokumentation bei einer Agentur eingeschlossen sind, vertraut ihr nicht. Wer jederzeit gehen könnte und trotzdem bleibt, schon eher.
Im dritten Teil dieser Serie geht es um den Weg zum Livegang – und darum, warum ein Launch für uns kein einzelner großer Moment sein muss.
punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de
Geschäftsführer
Telefon: +49 (721) 9109-124
E-Mail: stein@punkt.de
Ein gutes Angebot beginnt mit Verstehen – wie Projekte bei punkt.de starten
Wann beginnt ein Softwareprojekt? Mit dem unterschriebenen Angebot? Beim Kick-off? Oder mit dem ersten Ticket?
Für uns beginnt es früher: in dem Moment, in dem wir versuchen, die Herausforderung hinter einer Anfrage wirklich zu verstehen.
Wer bei uns anfragt, hat intern meistens längst entschieden, dass etwas passieren muss: Eine neue Website wird gebraucht, ein Extranet soll abgelöst oder eine individuelle Anwendung entwickelt werden. Manche Teams denken darüber erst seit wenigen Wochen nach, andere begleitet das Thema seit Jahren.
Was viele von ihnen zunächst gemeinsam haben:
Sie möchten ein Angebot. Eine Zahl. Möglichst schnell.
Das ist verständlich. Budgets müssen geplant und Anbieter verglichen werden. Trotzdem geben wir nur selten direkt ein Angebot für das eigentliche Projekt ab. Denn eine schnelle Zahl wäre zu diesem Zeitpunkt häufig vor allem eines: geraten.
Die eigentliche Herausforderung steht selten vollständig in der Anfrage
„Wir benötigen ein neues Extranet“ klingt zunächst eindeutig. Doch welche Aufgabe erfüllt das bestehende System? Wer arbeitet damit? Welche Funktionen sind unverzichtbar – und welche gibt es nur noch, weil es sie schon immer gab? Welche Prozesse und Schnittstellen hängen daran? Woran erkennen die Beteiligten später, dass das Projekt erfolgreich war?
Schon im ersten Termin stoßen wir meistens auf zwei oder drei Fragen, die sich nicht mal eben beantworten lassen. Das ist kein schlechtes Zeichen. Es zeigt, dass wir an den entscheidenden Stellen angekommen sind.
Natürlich könnten wir trotzdem einen Preis aus Annahmen ableiten. Wenn diese Annahmen nicht gemeinsam überprüft wurden, verlagert man die Unsicherheit jedoch nur in das Projekt. Später wird dann über Erwartungen, Verantwortlichkeiten und Nachträge diskutiert.
Das halten wir nicht für sinnvoll.
Unser Punktlandungsworkshop: erst den Kopf aufmachen, dann konkret werden
Um diese Unsicherheit früh zu bearbeiten, haben wir vor mehr als zehn Jahren ein Format entwickelt, das wir seitdem kontinuierlich weiterentwickeln: unseren Punktlandungsworkshop.
Der Name beschreibt den Ablauf ziemlich gut. Zunächst gewinnen wir Höhe und erweitern den Blick. Danach setzen wir zur Landung an.
Begleitet wird er in der Regel von unseren Berater:innen – häufig von Marco oder mir. Je nach Thema kommen Product Owner:innen, Designer:innen oder UX-Strateg:innen hinzu. Kein Workshop ist exakt wie der andere.
Der Vormittag gehört dem Verstehen. Wir lernen das Unternehmen, seine Ziele und die Geschichte des Projekts kennen. Wir betrachten Zielgruppen, Prozesse, technische Rahmenbedingungen und mögliche Entwicklungen. Dabei fragen wir auch nach Dingen, die zunächst außerhalb des geplanten Projekts liegen. Nicht, um es größer zu machen, sondern um wichtige Zusammenhänge nicht zu übersehen.
Am Nachmittag verdichten wir die Ergebnisse: Wir sortieren Funktionen, besprechen Ausbaustufen und setzen erste Prioritäten. Was gehört in eine erste Version? Was kann später folgen? Wo brauchen wir noch Konzeption?
Wenn die Aufgabe kleiner ist als gedacht und nach vier Stunden Klarheit besteht, sind wir früher fertig. Bei einem über Jahre gewachsenen System benötigen wir vielleicht länger.
Entscheidend ist nicht die Dauer. Entscheidend ist, dass beide Seiten anschließend dasselbe Projekt vor Augen haben.
Ein Strategiepapier statt eines isolierten Preisblatts
Nach dem Workshop erstellt die verantwortliche Person gemeinsam mit einem passenden Scrum-Team das Strategiepapier. Wir verlassen uns hier nicht auf KI sondern prüfen die Erkenntnisse durch Menschen, die das Projekt später umsetzen könnten.
Das Strategiepapier verbindet typischerweise vier Bereiche:
- kommunikative Herausforderungen und passende Lösungsansätze
- operative Herausforderungen und passende Lösungsansätze
- einen Vorschlag für den Projektplan
- einen Budgetvorschlag beziehungsweise das konkrete Angebot
Das Angebot ist also kein separates Preisschild, sondern Teil einer nachvollziehbaren Empfehlung. Dieses Papier präsentieren wir und entwickeln es mit dem Kunden weiter. Meist empfehlen wir eine klare Route. Grundlegend unterschiedliche Varianten zeigen wir nur, wenn sie für die Entscheidung wirklich relevant sind.
Auch darin zeigt sich unsere spätere Arbeitsweise: Wir verschwinden nicht mit den Anforderungen und kommen mit einem unveränderlichen Ergebnis zurück. Wir machen unseren Vorschlag sichtbar, holen Rückmeldung ein und schärfen ihn gemeinsam.
FEGIME: Ein gewachsenes Extranet wirklich verstehen
Wie tief wir dabei in die Welt eines Kunden eintauchen, zeigt unsere Zusammenarbeit mit der FEGIME Deutschland. Ihr individuell entwickeltes Extranet war über 15 Jahre gewachsen. Einige Funktionen wurden nicht mehr benötigt, andere waren für die Marktgemeinschaft unverzichtbar. Das System bildete nicht nur Technik ab, sondern auch Abläufe, Wissen und zahlreiche frühere Entscheidungen.
In einem zweitägigen Workshop haben wir das Vorhaben gemeinsam mit dem langjährigen IT-Ansprechpartner auseinandergenommen. Sein tiefes Wissen über Organisation, Nutzer:innen und Prozesse traf auf unsere Außenperspektive und Erfahrung mit komplexen Digitalprojekten. So konnten wir entscheiden, was bewahrt, entfernt oder neu gedacht werden sollte.
Das ist für uns Einarbeitung: nicht nur eine Funktionsliste aufnehmen, sondern das Unternehmen hinter dem System kennenlernen. Wie daraus ein MVP und ein schrittweiser Continuous Relaunch entstanden, zeigt unsere Case Study zum FEGIME-Extranet.
Wenn aus einem Vorschlag gemeinsame Verantwortung wird
Nimmt ein Kunde unseren Vorschlag an, passiert etwas, das ich gern ein Stück punkt.de-Magie nenne: Ein Team übernimmt Verantwortung für den Kunden – häufig über viele Jahre.
Das Wissen aus Kennenlernen, Workshop, Strategiepapier und Angebot fließt über standardisierte interne Prozesse in dieses Team. Der oder die Product Owner:in wird meist zur ersten operativen Ansprechperson. Aber der PO ist keine Trennwand zur Entwicklung. Wir planen bewusst ein Kennenlernen zwischen den Ansprechpartner:innen auf Kundenseite und den Entwickler:innen ein – meist remote, beim Kick-off je nach Projekt auch vor Ort.
Gemeinsam klären wir dann, was bereits zu Projektbeginn strategisch ausgearbeitet werden muss und welche Konzepte erst sinnvoll sind, wenn ihre Umsetzung ansteht. Unser Ziel: genug Klarheit für die Richtung und genug Beweglichkeit für das, was wir unterwegs lernen.
Zusammenarbeit lässt sich nicht vollständig abgeben
Unser Vorgehen hat eine Voraussetzung: Der Kunde muss Lust auf das Projekt und auf echte Zusammenarbeit haben.
Wir können viel abnehmen. Wie tief ein Kunde fachlich oder technisch mitdenkt, lässt sich je nach Projekt und Kapazität gestalten. Ein Modell funktioniert jedoch nicht: uns eine PDF zu übergeben und ein Jahr später eine fertige Lösung abzuholen.
Wir brauchen Wissen aus dem Unternehmen, Entscheidungen und iteratives Feedback. Kund:innen müssen dafür nicht jede technische Frage beantworten. Aber beide Seiten müssen Verantwortung für das Ergebnis übernehmen. Diese Erwartung sprechen wir lieber früh aus.
„Die verstehen, was wir sagen“
Viele vergleichbare Agenturen bringen die notwendigen technischen Fähigkeiten mit. Die Entscheidung fällt deshalb selten allein anhand einer Programmiersprache, eines CMS oder einer Featureliste. Sie fällt auch nach dem Gefühl, das in den ersten Gesprächen entsteht.
Das schönste Feedback, das wir nach einem Punktlandungsworkshop oder der Präsentation eines Strategiepapiers bekommen können, lautet sinngemäß: „Die verstehen, was wir sagen.“
Genau darum geht es uns. Wir möchten nicht nur Anforderungen protokollieren, sondern verstehen, warum sie existieren und wie sie zusammenhängen. Erst dann können wir einen Vorschlag machen, hinter dem wir als zukünftiges Projektteam stehen.
Ein gutes Angebot ist deshalb für uns nicht der Anfang einer Verhandlung über eine Zahl. Es ist das Ergebnis eines gemeinsamen Verständnisses – und der erste Schritt in eine Zusammenarbeit auf Augenhöhe.
Im zweiten Teil dieser Serie geht es darum, wie diese Zusammenarbeit im laufenden Projekt konkret aussieht: wie wir unsere Projektumgebung aufbauen, gemeinsam priorisieren, Aufgaben übergeben und für Budgettransparenz sorgen.
punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de
Geschäftsführer
Telefon: +49 (721) 9109-124
E-Mail: stein@punkt.de
Girls’Day 2026 bei der punkt.de: Erste Program-miererfahrungen mit Micro:bit
Der Girls’Day ist ein bundesweiter Aktionstag, der Mädchen Einblicke in Berufe und Studienfelder gibt, in denen Frauen noch unterrepräsentiert sind, unter anderem in IT und Softwareentwicklung. Genau deshalb unterstützen wir den Girls’Day seit vielen Jahren: Weil frühe, positive Erfahrungen oft den Unterschied machen, ob aus Interesse später echte Perspektive wird.
Warum uns der Girls’Day wichtig ist
Digitale Berufe prägen unsere Zukunft. Umso wichtiger ist es, dass junge Menschen unabhängig von Rollenbildern Zugang dazu bekommen. Beim Girls’Day geht es für uns nicht um ein einmaliges Event, sondern um Orientierung, Selbstvertrauen und darum zu zeigen: Programmieren ist lernbar, kreativ und macht Spaß.
Als Unternehmen mit langjähriger Erfahrung in Entwicklung und Open Source sehen wir es als Teil unserer Verantwortung, Nachwuchs zu fördern und Technik verständlich zu vermitteln – praxisnah, offen und auf Augenhöhe.
So lief der Tag bei punkt.de ab
Die acht ausgeschriebenen Plätze waren schnell belegt. Um 10:00 Uhr ging es mit einer kurzen Vorstellungsrunde los, danach konnten die Teilnehmerinnen direkt starten, alles war vorbereitet: Rechner, Programmablauf, Aufgaben und natürlich Snacks.
Mit Micro:bit haben die Mädchen spielerisch erste Programmierschritte gemacht, begleitet von erfahrenen Entwicklerinnen und Entwicklern aus unserem Team. Nach dem gemeinsamen Mittagessen und einer kleinen Büroführung wurde weitergearbeitet – dann auch an etwas komplexeren Übungen, zum Beispiel kleinen Spielen. Um 16:00 Uhr endete die Veranstaltung.
Stimmen der Teilnehmerinnen
"Ihr wart sehr freundlich und konntet gut helfen."
"Ich fand die freie Zeit zum Programmieren toll."
"Ich fand die freie Zeit voll gut, das es alles gut erklärt war."
"Es war cool dass wir so viel selber ausprobieren konnten und das wir auch das was wir gemacht haben behalten dürfen."
"Es hat sehr viel Spaß gemacht. Alle waren sehr freundlich und ich habe viel gelernt."
Unser Fazit
Der Girls’Day 2026 hat wieder gezeigt, wie viel Potenzial in praktischen Formaten steckt: selbst ausprobieren, Fragen stellen, Unterstützung bekommen und mit einem Erfolgserlebnis nach Hause gehen. Genau deshalb bleiben wir dabei – und freuen uns schon auf den nächsten Girls’Day bei punkt.de!
punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de
Geschäftsführer
Telefon: +49 (721) 9109-124
E-Mail: stein@punkt.de
Europäische Hyperscaler und andere Alternativen
In meinem Artikel „Warum Infrastruktur Haltung ist“ habe ich beschrieben, warum ich europäische Infrastrukturlösungen für relevant halte. In diesem Beitrag geht es um den nächsten Schritt: Europäische Optionen sind nicht nur eine Vernunftentscheidung, sondern in vielen Fällen wirkliche Alternativen – je nach Anforderung auch ohne ideologische Scheuklappen.
1) Grundsatzfrage: Brauche ich wirklich Cloud?
Die Frage „Cloud oder eigenes Blech?“ hat sich seit Mitte der 2010er stark verändert. Virtualisierung ist leichter geworden, Hardware stabiler, und die Grenzen zwischen Cloud und On-Prem sind zunehmend fließend.
Das sehen wir auch bei unserem proServer-Produkt: Es läuft immer häufiger selbst in kleinen HA-Setups bereits ab 150 € / Monat.
Und ganz pragmatisch: In den letzten 12 Monaten waren Systeme in der Praxis öfter betroffen, weil Vorschalt-Dienste ausgefallen sind (z. B. CDN/WAF), als weil „ein Server einfach steht“. Hochverfügbarkeit ist wichtig – aber sie entsteht nicht nur durch „mehr Cloud“, sondern durch Architekturentscheidungen.
Trotzdem gibt es gute Gründe für Cloud:
- Skalierbarkeit (Lastspitzen, schnelles Wachstum)
- Resilienz (wenn richtig designt)
- und oft der wichtigste Punkt für IT-Entscheider: Services und Ökosystem Im Zweifel kauft man nicht „Server woanders“, sondern fertige Bausteine, die in die Tool-Landschaft passen (Identity, Logging, Monitoring, Data Services usw.).
Wenn ich also entschieden habe, dass ein Teil meiner IT in die Cloud soll, ist die nächste Frage: Welche Optionen gibt es – auch in Europa?
2) Hyperscaler vs. Cloud: Was ist der Unterschied?
Cloud ist der Oberbegriff für die Bereitstellung von IT-Ressourcen (Server, Speicher, Anwendungen) über das Internet. Sie kann öffentlich (Public Cloud), privat (Private Cloud) oder hybrid sein – und wird von Anbietern jeder Größe angeboten.
Private Cloud kann – je nach Schutzbedarf – auch als Air‑Gapped Cloud umgesetzt werden (physisch/logisch getrennt, ohne direkte Internet-Anbindung), z. B. für Verteidigungs-, Finanz- oder Gesundheitsanwendungen.
Hyperscaler sind eine spezielle Kategorie von Cloud-Anbietern mit globaler Infrastruktur, extremen Skaleneffekten und einem breiten, oft proprietären Service-Portfolio (z. B. AWS, Microsoft Azure, Google Cloud).
Der Kernunterschied
Cloud (allgemein)
Skalierung: flexibel, aber begrenzt
Infrastruktur: gemietet oder selbst betrieben
Ökosystem: je nach Anbieter
Anbieter: viele (klein bis groß)
Hyperscaler
Skalierung: global, sehr schnell, „nahtlos“
Infrastruktur: stark optimiert, häufig eigene Hardware/Software
Ökosystem: sehr breit (von IAM bis KI/Serverless)
Anbieter: wenige globale Player
Warum das wichtig ist: Für viele KMU reicht eine „klassische“ Cloud völlig aus. Hyperscaler spielen ihre Stärke aus, wenn globale Reichweite, extreme Skalierung oder sehr integrierte Plattformdienste wirklich benötigt werden.
3) Europäische Landschaft: viele Alternativen – aber nicht überall „Hyperscale“
Im Cloud-Markt gibt es in Europa viele gute Alternativen: z. B. Hetzner (oft unser Standard für Infrastruktur), Mittwald und weitere Anbieter. Das sind stabile, praxistaugliche Lösungen, die wir selbst gern einsetzen.
Wenn es jedoch um „echte Hyperscale“ (im Sinne von sehr breitem Plattform-Ökosystem und globaler Skalierung) geht, wird die Auswahl kleiner.
4) Gaia‑X: Souveränität durch Regeln statt durch einen „Super-Hyperscaler“
Ein sehr europäischer Ansatz war (und ist) Gaia‑X. Das Projekt ist kein klassischer Cloud-Anbieter, sondern ein föderiertes Modell: viele Anbieter, gemeinsame Prinzipien und Standards (Identität, Compliance, Transparenz, Datenhoheit), sodass sich das Ökosystem für Nutzer konsistenter anfühlt. Gaia-X setzt auf Interoperabilität statt Insellösungen und nachweisbare Regeln/Zertifizierungen statt „Trust me“ – weniger struktureller Lock-in, mehr Steuerbarkeit.
Aktuell kommt wieder Bewegung rein: 2026 sollen erste operative Datenräume live gehen, z. B. für Luftfahrt, Raumfahrt und Gesundheitswesen. Auch internationale Partner (Japan, Kanada) zeigen Interesse. Gaia-X ist damit kein „totes“ Projekt, sondern entwickelt sich weiter – auch wenn die Umsetzung komplex ist und Zeit braucht.
5) Die „neuen alten Player“: europäische Anbieter mit Ambition
Neben dem föderierten Ansatz gibt es auch Anbieter, die deutlich in Richtung „Hyperscale“ wachsen – mit Fokus auf DSGVO, Datensouveränität und planbare Betriebsmodelle.
6) Europäische Hyperscaler & Alternativen (Auswahl)
Europäische Cloud-Anbieter im Überblick
Deutsche Telekom (T Cloud Public)
Die Deutsche Telekom positioniert ihre T Cloud Public als europäische Alternative zu US-Hyperscalern, insbesondere für regulierte Branchen und den öffentlichen Sektor. Zentrale Argumente sind Datenstandort, regulatorische Kontrolle und Vertragsgestaltung nach europäischen Standards. Die Plattform basiert auf OpenStack und soll laut Telekom bis Ende 2026 die Lücke zu US-Anbietern bei zentralen Core-Features deutlich verkleinern. Bei Souveränitäts- und Standortfragen ist zu beachten, dass sich Aussagen je nach konkretem Angebot innerhalb des breiteren T-Cloud-Portfolios unterscheiden können.
STACKIT (Schwarz Gruppe)
STACKIT entwickelt sich zunehmend zu einer souveränen europäischen Cloud-Alternative mit klarem Fokus auf Datenschutz und regulatorische Anforderungen. Die Plattform betreibt eigene Rechenzentren in Deutschland und Österreich und erfüllt unter anderem Anforderungen wie BSI C5 sowie ISAE 3000 (SOC 2) und ISAE 3402. Parallel wird die Infrastruktur massiv ausgebaut, unter anderem mit einem neuen Großrechenzentrum in Lübbenau, das bis 2027 realisiert werden soll. Im Vergleich zu AWS, Azure und GCP besteht weiterhin ein deutlicher Abstand bei globaler Reichweite und Plattformbreite.
IONOS
IONOS ist ein etablierter europäischer Anbieter für Hosting- und Cloud-Lösungen, der insbesondere für kleine und mittelständische Unternehmen attraktiv ist. Das Unternehmen setzt auf transparente Preisstrukturen und europäische Datenschutzstandards. Zudem engagiert sich IONOS in Initiativen zur digitalen Souveränität in Europa, darunter Gaia-X.
OVHcloud
OVHcloud zählt zu den größten europäischen Cloud-Anbietern und bietet ein breites Portfolio von Public Cloud über Hosted Private Cloud bis hin zu Bare-Metal- und Dedicated-Servern. Das Unternehmen verfolgt konsequent ein „EU-first“-Narrativ mit Fokus auf Datensouveränität, offenen Standards wie OpenStack sowie eigenen Technologien für Kühlung und Energieeffizienz. OVHcloud betreibt mehrere Dutzend Rechenzentren weltweit.
Scaleway
Scaleway richtet sich stark an Entwicklerteams und bietet einen pragmatischen Einstieg in Cloud-Infrastrukturen ohne unmittelbare Bindung an US-Hyperscaler-Ökosysteme. Das Portfolio umfasst unter anderem ARM-basierte Instanzen, Serverless-Angebote und Managed Kubernetes. Die Services werden aus europäischen Regionen wie Paris, Amsterdam und Warschau bereitgestellt.
evroc
evroc ist ein vergleichsweise neuer europäischer Cloud-Anbieter mit Fokus auf Nachhaltigkeit und digitale Souveränität. Seit 2025 sind erste Cloud- und AI-Services verfügbar. Aufgrund des frühen Entwicklungsstadiums sollten Leistungsumfang, verfügbare Regionen und Service-Level je nach Anwendungsfall im Detail geprüft werden.
7) Fazit: Haltung + Flexibilität schließen sich nicht aus
Für uns heißt das: Wir wollen nicht dogmatisch sein. Wir wollen saubere Architekturentscheidungen treffen:
- Was muss wirklich Hyperscaler sein?
- Was kann europäisch, souverän und trotzdem wirtschaftlich laufen?
- Wie vermeiden wir Lock-in – technisch und vertraglich?
Wer heute Infrastruktur plant, sollte Optionen kennen. Wir beschäftigen uns bewusst mit dem Markt, behalten unsere Haltung zu Souveränität im Blick – und bleiben dort flexibel, wo es sinnvoll ist.
Quellen & Weiterführendes
- Gaia-X: Aktueller Stand und Perspektiven
- T Cloud Public: Europäische Hyperscaler-Alternative
- STACKIT: Souveräne Cloud für Unternehmen
- OVHcloud: Europäische Infrastruktur
- Scaleway: Entwicklerfokus & Nachhaltigkeit
- Grüne Rechenzentren: EU-Strategie
- Partnerschaft BWI/Google: „eigene Cloud“ (Air-Gapped/abgetrennte Cloud im Verteidigungsumfeld)
- Schwarz Digits Datacenter Lübbenau (11‑Mrd.-Investition)
punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de
Geschäftsführer
Telefon: +49 (721) 9109-124
E-Mail: stein@punkt.de
Die 5 Gründe, auf die Hannover Messe zu gehen
Damit ihr wisst, was euch dort erwartet, haben wir hier unseren persönlichen Blick auf die Messe zusammengefasst – basierend auf unseren Erfahrungen der letzten Jahre.
Grund 1:
Zukunft erleben
Wer auf der Hannover Messe unterwegs ist, erlebt ein außergewöhnlich breites Spektrum: von klassischer Industrie über Automatisierung bis hin zu neuen, teils sehr futuristischen Technologien.
Man bekommt ein gutes Gefühl dafür, was heute bereits möglich ist – und welche Entwicklungen in den kommenden Jahren relevant werden können.
Grund 2:
Networking und Überblick
Ich selbst bin seit über 15 Jahren in diesem Umfeld tätig und bin trotzdem jedes Jahr aufs Neue überrascht, welche Unternehmen dort vertreten sind und wie international die Messe aufgestellt ist.
Die Hannover Messe bringt Unternehmen, Expert:innen und Entscheider:innen aus zahlreichen Ländern zusammen und bietet damit einen einzigartigen Überblick über Märkte, Lösungen und Trends.
Grund 3:
Echter Know-how-Austausch
Neben klassischen Sales-Pitches trifft man auf der Hannover Messe immer wieder Menschen, die ihre Industrie wirklich tief verstehen.
Dieser fachliche Austausch auf Augenhöhe – oft spontan und ungeplant – ist einer der größten Mehrwerte der Messe und macht sie weit mehr als nur zu einer Produktausstellung.
Grund 4:
Innovationen verstehen
Wie in jedem Markt gilt auch hier: Nicht jeder Trend wird sich durchsetzen.
Auf der Hannover Messe kann man sich selbst ein Bild davon machen, welche Technologien Substanz haben, was möglicherweise nur ein kurzfristiger Hype ist und welche Nischen zwar klein, aber dennoch strategisch spannend sein können.
Grund 5:
Optimismus spüren
Die wirtschaftlichen und gesellschaftlichen Herausforderungen sind groß – das ist kein Geheimnis.
Und natürlich ist auch auf der Hannover Messe nicht alles eitel Sonnenschein. Aber die Vielzahl an innovativen Ideen, engagierten Unternehmen und kreativen Lösungsansätzen sorgt bei mir jedes Jahr dafür, die Messe optimistischer zu verlassen, als ich sie betreten habe.
Und was macht jetzt die punkt.de dort?
Seit über 30 Jahren digitalisieren wir den deutschen Mittelstand – konsequent Open Source, datensensibel und mit echter Datensouveränität. Dieses Jahr sind wir nicht nur als Besucher:innen auf der Hannover Messe, sondern erstmals auch aktiv vor Ort vertreten.
Als Teil des Gemeinschaftsstands Baden-Württemberg (THE LÄND) – der offiziellen Standortinitiative des Landes – sind wir auf der Messe präsent. Wir freuen uns darauf, mit vielen Unternehmen aus dem deutschen Mittelstand ins Gespräch zu kommen und gemeinsam an einem unabhängigen, digitalen Wirtschaftsstandort Deutschland zu arbeiten.
Wenn ihr noch Tickets für die Hannover Messe benötigt, meldet euch gerne bei uns.
Die punkt.de ist vom 20. bis 24. April auf der Hannovermesse.
Gemeinschaftsstand „THE LÄND“, Halle 14, Stand: J40
punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de
Digital Consultant
Telefon: +49 (721) 91090
E-Mail: info@punkt.de
CI/CD als Kultur – wie wir durch automatisierte Qualität skalieren
Gerade weil CI/CD kein Trendthema mehr ist, halten wir es für umso wichtiger, darüber zu sprechen, wie man es im Projektalltag wirklich lebt. Technologien ändern sich, Anforderungen an Betrieb und Sicherheit steigen, Systeme werden komplexer. CI/CD ist deshalb kein einmal gelöstes Problem, sondern ein kontinuierlicher Prozess, der gepflegt, weiterentwickelt und immer wieder hinterfragt werden muss.
CI/CD als Kultur, nicht als Setup
Für uns ist CI/CD kein Toolset und kein Architektur-Baustein, den man am Projektanfang definiert und dann abhakt. CI/CD ist eine Grundentscheidung darüber, wie Software gebaut, ausgeliefert und betrieben wird. Es geht nicht darum, dass es eine Pipeline gibt, sondern darum, welche Verantwortung diese Pipeline übernimmt.
Wenn CI/CD richtig gelebt wird, sorgt es dafür, dass Qualität nicht von einzelnen Personen abhängt, sondern systemisch abgesichert ist. Automatisierung ist dabei kein Komfortgewinn, sondern die Grundlage für Verlässlichkeit.
Automatisierte Qualität als Voraussetzung für Skalierung
Qualität entsteht für uns nicht durch manuelle Abnahmen oder einzelne Quality Gates am Ende eines Prozesses. Qualität entsteht durch konsequente Automatisierung entlang des gesamten CI/CD-Flows. Automatisierte Qualität bedeutet, dass jede Änderung überprüfbar, reproduzierbar und bewertbar ist – ohne Sonderwege.
Wenn ein Change nicht automatisiert gebaut, getestet und ausgeliefert werden kann, ist er nicht fertig. Diese Konsequenz ist unbequem, besonders in frühen Projektphasen. Sie ist aber entscheidend, um Qualität mit wachsender Codebasis, mehr Beteiligten und höherem Änderungsdruck überhaupt skalieren zu können.
CI/CD erzeugt Geschwindigkeit – wenn Qualität automatisiert ist
CI/CD wird oft mit Geschwindigkeit gleichgesetzt. Für uns ist Geschwindigkeit ein Ergebnis, kein Ziel. Sie entsteht dann, wenn automatisierte Qualität Vertrauen schafft. Vertrauen darin, dass Änderungen klein bleiben, dass Fehler früh sichtbar werden und dass Deployments keine Überraschungen enthalten.
Wenn ein Deployment Angst macht, ist das kein Teamproblem, sondern ein CI/CD-Problem. In solchen Fällen fehlt fast immer automatisierte Qualität – sei es in Tests, in der Infrastruktur oder im Monitoring.
CI/CD endet nicht bei der Pipeline
CI/CD funktioniert nur dann nachhaltig, wenn Infrastruktur Teil des Systems ist. Deployment-Logik, Laufzeitumgebung, Observability sowie Backup- und Recovery-Strategien sind integraler Bestandteil automatisierter Qualität. Eine Anwendung, die zwar getestet ist, deren Betrieb aber nicht automatisiert und beobachtbar ist, bleibt ein Risiko.
CI/CD ist deshalb immer auch ein Infrastruktur- und Betriebsthema. Und weil sich Technologien, Plattformen und Anforderungen ändern, muss auch CI/CD kontinuierlich weiterentwickelt werden.
Warum CI/CD ohne Konsequenz nicht funktioniert
Viele Teams haben CI/CD. Wenige Teams verlassen sich wirklich darauf. Der Unterschied liegt nicht im Tooling, sondern im Anspruch. Wird die CI/CD-Pipeline umgangen, wenn sie nervt? Gibt es manuelle Ausnahmen für „wichtige“ Releases? Oder ist automatisierte Qualität so fest verankert, dass Abkürzungen unnötig werden?
Unser Ziel ist immer Letzteres. CI/CD soll Verantwortung aus einzelnen Köpfen in Systeme überführen – nicht zusätzliche Abhängigkeiten schaffen.
CI/CD für technische Entscheider:innen
Für technische Entscheider:innen ist CI/CD vor allem ein Mittel zur Risikominimierung. Automatisierte Qualität sorgt dafür, dass Projekte nicht an einzelnen Personen hängen, dass Betrieb von Anfang an mitgedacht wird und dass Anwendungen auch nach dem Go-live stabil weiterentwickelt werden können.
CI/CD ist in diesem Kontext keine technische Spielerei, sondern eine Investition in Planbarkeit und Zukunftsfähigkeit.
CI/CD und automatisierte Qualität für bestehende Entwicklungsteams
Gleichzeitig richten wir uns an technische Anwendungsverantwortliche, die bereits Entwicklungsteams haben, aber Unterstützung beim Aufbau und Betrieb von CI/CD-Strukturen benötigen. Wir integrieren uns in bestehende Setups und schaffen CI/CD-Prozesse, die automatisierte Qualität und verlässlichen Betrieb ermöglichen – unabhängig davon, wo entwickelt wird.
Fazit
CI/CD ist kein Setup, kein Sprint-Ziel und keine Tool-Entscheidung. CI/CD ist eine kulturelle Entscheidung. Eine Entscheidung dafür, Qualität nicht zu verhandeln, sondern durch Automatisierung abzusichern. Automatisierte Qualität ist dabei der Schlüssel, um Softwareprojekte auch bei wachsender Komplexität beherrschbar zu halten.
Gerade weil CI/CD kein Hype mehr ist, bleibt es relevant. Wer kontinuierlich daran arbeitet, bleibt handlungsfähig. Wer stehen bleibt, merkt es meist erst, wenn es weh tut.
punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de
Geschäftsführer
Telefon: +49 (721) 9109-124
E-Mail: stein@punkt.de
Hannovermesse 2026 / THE LÄND – Wir sind dabei!
Wir freuen uns sehr, dieses Jahr Teil der Initiative „THE LÄND“ des Landes Baden-Württemberg zu sein und unser Bundesland im Ausstellungsbereich „Industrie-Software“ in Sachen Digitalisierung zu vertreten.
Wir bringen unsere Expertise aus den letzten 30 Jahren in den Bereichen Entwicklung und Hosting aus Karlsruhe nach Hannover, um vor Ort mit der produzierenden Industrie über sinnvolle Digitalisierung mit Open Source zu sprechen.
Wenn dich oder dein Unternehmen folgende Themen beschäftigen:
- Digitale Souveränität
- Anwendungsentwicklung mit Open Source
- Sicheres Hosting & Managed Services
- Digitalisierung mit Open Source
Dann kontaktiere uns oder komm uns besuchen am "THE LÄND" -Stand:
Gemeinschaftsstand "THE LÄND"
Halle 14
Stand: J40
In den kommenden Wochen werden wir weitere Informationen auf unserem Blog sowie auf unseren Social-Media-Kanälen bereitstellen!
punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de
Geschäftsführer
Telefon: +49 (721) 9109-124
E-Mail: stein@punkt.de
Unsere Open Source Learnings 2025
Open Source befindet sich 2025 in einem Zustand tiefgreifender Veränderung. Viele Selbstverständlichkeiten der vergangenen zwei Jahrzehnte – klare Lizenzmodelle, Community-getriebene Weiterentwicklung, ein schwarz-weißes Verständnis von „frei“ versus „proprietär“ – lösen sich auf oder werden neu definiert. Gleichzeitig steigt die Bedeutung digitaler Souveränität rapide an.
Unternehmen, Behörden und öffentliche Institutionen müssen sich damit auseinandersetzen, wo ihre Daten liegen, wie unabhängig ihre Technologieentscheidungen wirklich sind und welche Rolle Open Source dabei spielt. Genau an dieser Schnittstelle bewegen wir uns als punkt.de seit vielen Jahren. Und selten war die Dynamik so spürbar wie 2025.
Vom Klassentreffen zur strategischen Bühne:
TYPO3 im Aufwind
Wer seit vielen Jahren in der TYPO3-Community unterwegs ist, erinnert sich noch gut an die Zeit vor 2015–2020: Die T3CON war ein Klassentreffen. Familiär, fachlich tief, aber klein. 2025 ist das Bild ein anderes. Auf der Konferenz waren Akteure zu sehen, die noch vor wenigen Jahren keinerlei Berührungspunkte mit TYPO3 hatten. Karim Marucchi, CEO von Crowd Favorite, tief in der WordPress-Welt verankert, sprach über digitale Souveränität und Open-Source-Governance. Dass sich Persönlichkeiten aus ganz anderen Ökosystemen plötzlich ernsthaft für TYPO3 interessieren, zeigt: Unser CMS ist nicht mehr nur Werkzeug – sondern Infrastruktur.
Das ITZBund, Materna und andere große Player waren ebenfalls an allen Tagen präsent. Das ist ein qualitativer Sprung. TYPO3 wird strategisch gedacht. Nicht als Alternative, sondern als Grundlage. Der Government Site Builder (GSB) setzt in seiner neuen Version auf TYPO3. Die Relevanz von Open Source „made in Germany“ wächst – und wir sind Teil eines Ökosystems, das 2025 erwachsener ist als je zuvor.
Der Government Site Builder 11 wird vom ITZBund offiziell als Standardlösung des Bundes geführt und basiert ab Version 11 auf dem Open-Source-CMS TYPO3 – ein klares Bekenntnis der Bundesverwaltung zu offener Infrastruktur.
Wer das vertiefen möchte, findet im TYPO3-Umfeld und in unserer Zusammenarbeit mit anderen Agenturen rund um GSB und öffentliche Projekte weitere Einblicke, z. B. im Beitrag „1_Forge: Drei Agenturen, ein Schulterschluss – für starke TYPO3-Projekte auf Augenhöhe“.
Automatisierung wird souverän: Unser Weg mit n8n und CIB seven
2025 war für uns ein Jahr der konsequenten Automatisierung – allerdings mit einem klaren Anspruch: Wir automatisieren nur dort, wo wir die Datenhoheit behalten können. Damit unterscheiden wir uns bewusst vom aktuellen Trend, überall Make, Zapier oder andere SaaS-Integratoren einzusetzen. Nicht weil diese Tools schlecht wären – sie sind im Gegenteil oft großartig. Aber sie erfordern, dass Unternehmensprozesse, Zugangsdaten und interne Datensysteme in einer fremden Cloud liegen.
Als Kunden zunehmend Make nutzten, standen wir vor der Frage: Wie können wir dieselbe Flexibilität bieten, ohne Souveränität einzubüßen? Die Antwort war für uns eine Kombination aus Werkzeugen: n8n als zentrale Automatisierungsplattform und CIB seven als Möglichkeit, komplexere Prozesse auf einer souveränen Workflow-Engine abzubilden. Beide Tools hosten wir selbst – und das verändert das Spiel.
Ein Beispiel: Unsere Pressearbeit läuft inzwischen weitgehend automatisiert. Einmal pro Woche wird aus unseren internen Quellen ein aktueller Artikelbestand an Dienste wie die PresseBox übermittelt – fehlerfrei, nachvollziehbar und komplett auf unseren Servern verarbeitet. Klein, aber symbolträchtig: Wir sparen Zeit, gewinnen Qualität und behalten alle Daten im eigenen Haus.
Diese Haltung – Automatisierung ja, aber nur mit Datenhoheit – haben wir in unserem Blog einmal so zusammengefasst: „Automatisierung funktioniert nur dann nachhaltig, wenn die Hoheit über die Daten beim Unternehmen bleibt.“
Dabei mussten wir unser eigenes Verständnis von Open Source erweitern. Denn n8n ist eben nicht „klassisch Open Source“. Die Sustainable Use License beschränkt bestimmte Nutzungsarten – insbesondere das Betreiben als kommerziellen SaaS-Dienst. Anfangs war ich skeptisch. Open Source ist für mich mehr als ein Lizenztext. Doch das Modell von n8n hat mich überzeugt: Es schützt vor Ausbeutung durch Cloud-Giganten, lässt aber alle Freiheitsgrade, die man für echte Souveränität braucht. Dieses hybride Denken ist ein wichtiger Baustein für die Zukunft – und ein persönliches Learning von 2025.
Jan Oberhauser, der Gründer von n8n, bringt es im Kontext der Fair-Code-Bewegung so auf den Punkt: Man müsse Modelle finden, „in denen alle gewinnen – Nutzer, Community und Unternehmen“. Die Sustainable Use License ist genau so ein Versuch: Der Quellcode bleibt einsehbar und erweiterbar, aber die rein kommerzielle Weitervermarktung ohne Rückfluss an das Projekt wird begrenzt.
Bewegung in den Communities: WordPress, Akeneo, Pimcore
Kaum ein Jahr hat so deutlich gezeigt, wie fragil Open-Source-Governance sein kann. Der Konflikt zwischen Matt Mullenweg (Automattic) und WP Engine hat viele Kunden zutiefst verunsichert. Der endgültige Bruch eskalierte Ende 2024, doch die Auswirkungen rollten 2025 durch den Markt: die Drohung, Markenrechte zu entziehen, das zeitweise Entfernen von WP-Engine-Kunden aus Update-Kanälen, der öffentliche Schlagabtausch. Egal wie man die Details bewertet – ein solches Machtgefälle wäre in vielen anderen Open-Source-Projekten schlicht nicht möglich. TYPO3 & Co. haben hier einen klaren Vorteil: Governance ist verteilt. Kein einzelner Akteur kann komplette Nutzergruppen aussperren.
Doch WordPress ist nur ein Beispiel. Akeneo hat seine Community Edition de facto eingefroren und konzentriert sich zunehmend auf sein SaaS- und Enterprise-Modell. In der Praxis bedeutet das: Neue Features landen zuerst (oder ausschließlich) in den gehosteten Varianten und in der Enterprise-Edition, während die Community Edition in weiten Teilen im Wartungsmodus verharrt und der Fokus klar auf den „Serenity“-SaaS-Ansatz wandert.
Pimcore hat in diesem Jahr auf die eigene POCL-Lizenz umgestellt – ein Move, der für viele nach einem Abschied von echtem Open Source klingt, aber gleichzeitig die rechtlichen Risiken klassischer Copyleft-Lizenzen minimieren soll. Ab Version 2025.1 steht die Community Edition nicht mehr unter GPLv3, sondern unter der Pimcore Open Core License (POCL), die zwar vollständige Quellcode-Einsicht und Anpassbarkeit verspricht, aber klar zwischen Community-Nutzung und kommerzieller Nutzung unterscheidet.
Und jetzt kommt der unbequeme Teil:
Es wäre zu einfach, diese Projekte zu kritisieren. Fakt ist: Die Anforderungen an moderne digitale Produkte sind enorm gestiegen. Architektur, Security, Skalierbarkeit, Compliance – das alles kostet Geld. Und ehrlicherweise: Die Open-Source-Community trägt nur selten ausreichend dazu bei, dass große Projekte finanziell solide weiterentwickelt werden können.
Wer jetzt protestiert, sollte sich fragen, ob er in den letzten Jahren genügend beigetragen hat, um Kommerzialisierung zu verhindern. Ich selbst schaue mit Stolz auf TYPO3 und die Gründung der TYPO3 GmbH im Jahr 2016. Das war Weitblick. Es war die Antwort der Community auf die Frage:
Wie sichern wir die Zukunft unseres Projekts, ohne uns zu verkaufen?
Diese Governance-Strukturen tragen heute – und andere Systeme werden nachziehen müssen.
Für 2026 wünsche ich mir klare Preisstrukturen und transparente Onboarding-Modelle. Wir verstehen, dass Systeme Kosten verursachen müssen, aber die Willkommenskultur der „alten Open-Source“-Welt muss erhalten bleiben. In diesem Jahr haben wir versucht, mit einigen langjährigen Open-Source-Systemen, wie Sylius, Elastic und n8n, in die Enterprise-Welt einzusteigen.
Es war ein absoluter Tarif-Dschungel. Nach fünf Telefonaten, Gesprächen und Unterlagen hatten wir immer noch keinen Preis und kein Gefühl der Willkommenskultur – nur Unsicherheit.
Gerade Agenturen brauchen die Möglichkeit, neue Tools auszuprobieren, ohne sofort im Enterprise-Lock-in zu landen. Andernfalls wird Europa diese Tools nicht breit adaptieren.
Ein Beispiel, dass es auch anders geht, sieht man im TYPO3-Ökosystem: Durch die Mischung aus Association, GmbH und einem breiten Agentur-Netzwerk ist klar, wer wofür bezahlt – und trotzdem bleibt der Kern des Systems offen und Community-getrieben.
Europa reguliert – und das ist gut so
Regulierung ist in der Tech-Branche ein Reizwort. Viele Unternehmen sehen in NIS2, CRA, dem Barrierefreiheitsgesetz oder DSGVO-Nachschärfungen vor allem Aufwand. Wir erleben das täglich: Die ersten Reaktionen auf EU-Gesetze klingen oft nach Überforderung oder „Brüssel-Bürokratismus“. Doch je tiefer ich mich professionell mit diesen Themen beschäftige, desto klarer sehe ich: Europa hat hier einen strategischen Vorteil, den wir viel selbstbewusster kommunizieren sollten.
Ich habe in diesem Jahr einige Gespräche mit amerikanischen Expert:innen geführt. Das Bild ist eindeutig: Die USA beneiden uns um die europäische Regulierung. Nicht weil sie bequem wäre – sondern weil sie Schutz, Klarheit und Souveränität schafft. Während in den USA Datenhandel, Profiling und Plattformmacht weitgehend unreguliert sind, bietet Europa verlässliche Leitplanken, die Vertrauen schaffen.
NIS2 zwingt Unternehmen, sich ernsthaft mit ihrer eigenen IT-Sicherheit auseinanderzusetzen. Die Richtlinie schafft einen einheitlichen Rahmen für Cybersecurity in zahlreichen kritischen Sektoren und erweitert den Geltungsbereich deutlich – auch auf viele mittelständische Unternehmen. Der Cyber Resilience Act sorgt dafür, dass Software – egal ob Open Source oder proprietär – endlich Mindeststandards erfüllen muss, etwa Security-by-Design, regelmäßige Updates und klare Verantwortlichkeiten. Der Accessibility Act hebt Barrierefreiheit aus dem „Nice-to-have“ in den Status eines Qualitätsmerkmals. Und über allem steht das europäische Selbstverständnis, digitale Souveränität als Standortfaktor zu begreifen.
Viele betrachten das als Belastung. Ich sehe es als Chance.
Auch, weil wir uns als punkt.de auf den Weg gemacht haben, selbst die ISO 27001 zu erfüllen. Nicht, weil ein Kunde es verlangt hätte, sondern weil wir zeigen wollen: Wir meinen Sicherheit und Souveränität ernst. Für uns ist das Regulierungsthema kein Klotz am Bein – es ist ein Zukunftstreiber.
Wer sich tiefer einlesen möchte, findet in unserem Blog regelmäßig Einordnungen zu Regulierung, Souveränität und Praxisbeispielen – vom Mittelstand bis zur öffentlichen Hand.
Eine ausführlichere Einordnung, warum wir digitale Souveränität nicht als Verzicht, sondern als bewusste Entscheidung verstehen, habe ich in unserem Blogartikel „Digitale Souveränität: bewusste Entscheidungen statt Dogma“ festgehalten.
Mein Ausblick: 2026 wird ein Jahr der Klarheit
2025 war ein Jahr des Wandels. 2026 wird ein Jahr der Klarheit. Wir werden im nächsten Jahr deutlich klarer sehen, welche Open-Source-Projekte ihre Governance im Griff haben – und welche nicht. Wir werden sehen, welche Lizenzmodelle funktionieren und welche die Community entfremden. Wir werden erkennen, welche EU-Regulierungen echte Innovation auslösen – und wo nachjustiert werden muss.
Ich persönlich freue mich darauf, diese Diskussionen aktiv mitzugestalten. Open Source bedeutet für mich: Optionen behalten. Verantwortung übernehmen. Und souverän bleiben – technisch, strategisch und rechtlich.
Als punkt.de werden wir auch 2026 unseren Weg konsequent gehen:
Open Source als Default.
Europäische Technologie als Fundament.
Souveränität als Haltung.
Es ist ein guter Zeitpunkt, über Technologie neu nachzudenken. Und es ist ein großartiger Zeitpunkt, Verantwortung zu übernehmen.
Autor: Fabian Stein
Fabian beschäftigt sich mit der Digitalisierung in Deutschland und der Entwicklung des Open Source Marktes als CEO von punkt.de
punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de
Geschäftsführer
Telefon: +49 (721) 9109-124
E-Mail: stein@punkt.de
Matomo statt Google – Tracking gehört Ihnen
Viele Unternehmen stehen derzeit vor der Frage, wie sie ihr Web-Tracking und ihre Analyse datenschutzkonform und zukunftssicher gestalten können. Google Analytics – insbesondere die aktuelle Version GA4 – ist zwar weit verbreitet, bewegt sich aber weiterhin in einer juristischen und technischen Unsicherheitszone. Mehrere Datenschutzbehörden in Europa haben bestätigt, dass GA4 in seiner Standardkonfiguration nicht DSGVO-konform betrieben werden kann. Das schafft Risiken, die langfristig schwer kalkulierbar sind.
Gleichzeitig wünschen sich Teams ein Tracking-System, das professionelle Analyse-Funktionen bietet und dennoch die volle Kontrolle über die eigenen Daten ermöglicht. Genau hier setzt Matomo an. Die Open-Source-Plattform wird weltweit eingesetzt, ist technisch ausgereift und erlaubt Unternehmen, Webanalyse unter eigener Kontrolle zu betreiben – ohne Abhängigkeit von US-Anbietern.
Datenschutz und Datensouveränität als klare Vorteile
Der grundlegende Unterschied zwischen Matomo und GA4 liegt weniger in der Oberfläche als im Umgang mit Daten. Während die Datenströme von Google Analytics automatisch in ein US-basiertes Ökosystem fließen, lässt sich Matomo so betreiben, dass Datensouveränität vollständig gewährleistet ist:
- Daten können auf eigenen Servern gespeichert werden
- Hosting in deutschen oder europäischen Rechenzentren ist problemlos möglich
- Es findet kein Transfer personenbezogener Daten an Dritte statt
- Der Zugriff ist vollständig kontrollierbar
Diese Form der Datensouveränität wird für Unternehmen immer wichtiger – nicht nur aus juristischen Gründen, sondern auch für die interne Risikoabwägung. Matomo unterstützt diesen Ansatz durch integrierte Datenschutzfunktionen wie IP-Anonymisierung, „Do Not Track“-Unterstützung oder Datenlöschung auf Anfrage. Unter bestimmten Bedingungen ist Matomo sogar ohne Einwilligungsbanner nutzbar, weil das Tracking ohne Cookies möglich ist.
Damit wird Matomo zu einer Analyse-Plattform, die Datenschutz nicht als Einschränkung, sondern als Grundprinzip versteht.
Warum Matomo auch fachlich überzeugt
Die Entscheidung für eine Analyse-Plattform sollte nicht nur rechtliche Aspekte berücksichtigen, sondern auch die Qualität des eigenen Trackings. Hier zeigt sich, dass Matomo in einigen Punkten strukturelle Vorteile gegenüber GA4 hat.
Anders als Google Analytics arbeitet Matomo ohne Sampling. Die Analyse basiert immer auf vollständigen Daten – unabhängig vom Traffic-Volumen. Das erleichtert sowohl strategische Auswertungen als auch detaillierte Fragestellungen, etwa bei Conversion-Optimierung oder Kampagnenanalysen.
Hinzu kommt die Offenheit des Systems: In Matomo stehen – insbesondere bei Self-Hosting – die Rohdaten zur Verfügung. Unternehmen können eigene Auswertungen fahren oder Daten mit BI-Tools verbinden. Ein weiterer Vorteil liegt darin, dass Matomo neue Ziele oder Segmente nicht nur für die Zukunft berechnen kann, sondern auch rückwirkend. Bei GA4 dagegen verhindert die begrenzte Datenspeicherung oft, dass historische Auswertungen vollständig möglich sind.
Auch wenn die Oberfläche von Matomo weniger verspielt wirkt als die von GA4, erfüllt sie die Erwartungen moderner Tracking-Prozesse. Matomo bietet E-Commerce-Tracking, Event-Tracking, Kampagnenanalyse, Funnel-Berichte und erweiterte Funktionen wie Heatmaps oder A/B-Tests.
Für viele Anwendungsfälle ist Matomo damit nicht nur eine datenschutzfreundliche Alternative, sondern auch eine funktional stabile und nachvollziehbare Analyse-Plattform.
Unabhängigkeit und Planungssicherheit
Ein Punkt, der bei der Wahl eines Tracking-Systems oft unterschätzt wird, ist die langfristige Planbarkeit. GA4 hat gezeigt, wie abrupt Google grundlegende Änderungen vornehmen kann – sei es technisch, strukturell oder im Hinblick auf Datenhaltungsfristen. Die Abschaltung von Universal Analytics hat viele Unternehmen gezwungen, Daten zu migrieren oder sogar ganz aufzugeben.
Matomo entwickelt sich in einem anderen Rhythmus: transparent, nachvollziehbar und ohne externe Abhängigkeiten. Für Unternehmen bedeutet das langfristige Stabilität. Auch Migrationen – etwa von Piwik PRO oder Google Analytics – sind möglich und verlieren durch Matomos offene Struktur ihren Schrecken.
Vor allem Organisationen, die Tracking im Kontext von Compliance, Governance oder IT-Sicherheit betrachten, schätzen diese Form der Datensouveränität.
Fazit: Matomo schafft eine Balance aus Datenschutz, Kontrolle und professioneller Analyse
Für Unternehmen, die Wert auf rechtssicheres Tracking und gleichzeitig auf qualitativ hochwertige Analyse legen, ist Matomo heute oft die bessere Wahl. Die Plattform kombiniert:
- Datensouveränität durch volle Kontrolle über Speicherorte und Datenzugriff
- Datenschutz durch integrierte Schutzmechanismen
- Professionelle Tracking-Funktionen, die den Vergleich mit GA4 nicht scheuen müssen
- Transparenz und Offenheit, die langfristige Planung erleichtern
Matomo ist vielleicht nicht in jeder Nutzerinteraktion so poliert wie GA4 – dafür ist es klar strukturiert, nachvollziehbar und bietet Unternehmen die Freiheit, ihre Webanalyse selbstbestimmt zu gestalten.
Wer Web-Tracking nachhaltig, rechtssicher und zukunftsfähig betreiben möchte, kommt an Matomo kaum vorbei.
Die punkt.de GmbH ist eine Open-Source Software Agentur. Was uns auszeichnet sind mehr als 25 Jahre Erfahrung und der Anspruch unsere Kunden nachhaltig weiterzubringen. Erfrischend direkt, ehrlich und bodenständig.
punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de
Geschäftsführer
Telefon: +49 (721) 9109-124
E-Mail: stein@punkt.de
