Firma punkt.de, Autor bei Software-Journal

FEGIME Extranet – Open Source im Mittelstand

By Firma punkt.de | 14. Oktober 2025

Der Kunde

Die Abkürzung „FEGIME” steht für „Fédération Européenne des Grossistes Indépendants en matériel électrique” (Europäischer Verband der unabhängigen Elektrogroßhändler). In der FEGIME Deutschland GmbH & Co. KG (FEGIME) sind ca. 45 Familienunternehmen des Elektrogroßhandels organisiert. Die FEGIME Deutschland ist über Jahrzehnte durch Fusionen von mittelständischen Marktgemeinschaften entstanden. Die Gesellschafter:innen setzen ca. 2,4 Milliarden Euro (2023) in Deutschland um und sind an über 160 Standorten vertreten (Details: https://www.fegime.de/…)

Das Problem – 15 Jahre Techdebt

Für die FEGIME als Marktgemeinschaft ist es sehr wichtig, die Abstimmung und Kommunikation ihrer Gesellschaften an einem Ort zu bündeln. Dabei setzte sie auf ein selbst entwickeltes Extranet, das über 15 Jahre hinweg gute Dienste geleistet hat. Das Extranet wurde intern betrieben und weiterentwickelt, allerdings beruhte es auf einer monolithischen Architektur und stieß nach dieser langen Zeit in vielen Bereichen an seine Grenzen.

Einerseits gab es viele Probleme im Bereich Design, UI und UX sowie Performance, andererseits gab es technische Probleme bei der Entwicklung neuer Funktionen. Die alltägliche Nutzung des Extranets gestaltete sich auf FEGIME- und Gesellschafterseite zunehmend schwierig und mühselig. Auch der Betrieb und die Wartung des Systems wurden durch einen Generationswechsel in der internen IT immer schwieriger.

Unser Auftrag war es, ein neues Extranet zu entwickeln, das folgende Ziele erfüllen musste:

Zentrales Informationsmanagement
Effiziente Kommunikation (intern, extern)
Striktes Rechtesystem um regulatorische Anforderungen zu erfüllen (Kartellrecht)
Die Kernwerte der FEGIME sollten sich im neuen Extranet wiederfinden
Strukturiertes Dokumentenmanagement
Kostenreduktion durch einfachere Prozesse und Skalierung
Ein intuitives Design mit optimierter UI und UX, das die Arbeit mit dem Extranet vereinfacht

Ein neues Extranet

Schon im ersten Workshop für das neue Extranet wurde schnell klar, dass vor einer Entwicklung viel grundlegende Konzeptarbeit nötig war. Das alte Extranet war über einen Zeitraum von 15 Jahren gewachsen. Es musste Komplexität aus dem System genommen werden, ohne dabei entscheidende Prozesse zu verlieren, während gleichzeitig neue Funktionen umgesetzt wurden. Da im Extranet sensible und wirtschaftlich kritische Informationen für die Gesellschafter zu finden sind, war auch das Thema Datenhoheit bei der Konzeption zu berücksichtigen.

Neben dieser Konzeptarbeit mussten auch diverse Schnittstellen, beispielsweise zu Shops und Datenbanken, eingeplant werden, um die vier Millionen Artikel der Gemeinschaft zu verwalten.

All dies sollte selbstverständlich extrem performant und für die Nutzer auf FEGIME- und Gesellschafterseite, die das Extranet täglich nutzen, attraktiv gestaltet sein.

Zudem sollte das neue Extranet auf einem modernen Kern aufbauen, der sich auch in Zukunft leicht weiterentwickeln lässt und die strengen Vorgaben an ein striktes und robustes Rechtesystem erfüllt. Die Bildung von Techdebt sowie die Bindung an einen Anbieter sollten vermieden werden.

Warum Open Source?

Zusammengefasst laufen die Anforderungen an das neue Extranet auf eine Anwendung hinaus, die sicher, performant, flexibel und unabhängig sein muss. Open-Source-Lösungen bringen all diese Eigenschaften (und noch mehr) mit sich.

Sicherheit

Der Kern der Anwendung ist TYPO3. Als quelloffenes CMS mit einer großen Community hat es sich in den letzten Jahrzehnten etabliert und liefert ein extrem gutes und robustes Berechtigungssystem. Zudem dient es als Data-Provider. Eine sehr aktive Community überwacht die Sicherheit des CMS und reagiert schnell auf aktuelle Bedrohungen.

Performance

Durch den Einsatz von TYPO3 als Kern und einem selbst entwickelten React-Frontend waren wir in der Lage, die Reaktionszeiten zu optimieren. Für die Suche setzen wir auf Solr mit eigenen Indizes, was für die Nutzer zu spürbaren Verbesserungen bei der Suche nach Informationen im Extranet geführt hat und somit die Akzeptanz der neuen Anwendung fördert.

Flexibel

In der Konzeptionsphase wurden Workshops mit den verschiedenen Fachbereichen (Lieferanten, Einkauf, Marketing, IT etc.) durchgeführt. Dadurch war es möglich, individuell auf die Anforderungen der einzelnen Bereiche einzugehen und die entsprechenden Funktionen passgenau zu entwickeln. Zusammen mit einer guten Dokumentation und offenem Code ist es ein Leichtes, die Anwendung weiterzuentwickeln und auch in Zukunft zu betreiben.

Unabhängigkeit

Die Themen „Datensouveränität” und „Vendor-Lock-in” sind aktueller denn je. Auch in diesem Projekt war es der FEGIME wichtig, Herr über die eigenen Daten zu sein. Da im Extranet sensible und auch wirtschaftlich kritische Informationen für die Gesellschafter ausgetauscht werden, müssen sowohl die Sicherheit als auch die Souveränität gewährleistet sein. Doch was bedeutet das?

Diese Anforderung bezieht sich sowohl auf das Hosting der Anwendung als auch auf den Code. Ein großer Vorteil von Open-Source-Lösungen ist, dass der Code nicht der Agentur, sondern dem Kunden (in diesem Fall der FEGIME) gehört. Der entwickelte Code ist offen und kann von der IT des Kunden eingesehen und verwaltet werden. Sollten sich die Rahmenbedingungen für die Anwendung oder die Zusammenarbeit mit der Agentur in Zukunft ändern, gehören der Code und alle Daten dem Auftraggeber. Das ist ein wesentlicher Unterschied zu Anbietern proprietärer Software.

Open Source für den Mittelstand

Unser FEGIME-Projekt ist ein sehr gutes Beispiel dafür, wie Open Source dem Mittelstand dabei hilft, sich zu modernisieren, ohne sich einem Anbieter auszuliefern. Dabei müssen keine Kompromisse in Bezug auf Sicherheit, Features oder Performance der Anwendung gemacht werden. Auch eine Skalierung der Anwendung ist problemlos möglich.

Mit einer Open-Source-Lösung können mittelständische und auch Großunternehmen Herr über die eigenen Daten bleiben und eine Anwendung entwickeln lassen, die sich genau an ihre Bedürfnisse anpasst. Und das Ganze ist auch noch frei von Lizenzkosten.

Firmenkontakt und Herausgeber der Meldung:

punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de

Weiterführende Links

Für die oben stehende Story ist allein der jeweils angegebene Herausgeber (siehe Firmenkontakt oben) verantwortlich. Dieser ist in der Regel auch Urheber des Pressetextes, sowie der angehängten Bild-, Ton-, Video-, Medien- und Informationsmaterialien. Die United News Network GmbH übernimmt keine Haftung für die Korrektheit oder Vollständigkeit der dargestellten Meldung. Auch bei Übertragungsfehlern oder anderen Störungen haftet sie nur im Fall von Vorsatz oder grober Fahrlässigkeit. Die Nutzung von hier archivierten Informationen zur Eigeninformation und redaktionellen Weiterverarbeitung ist in der Regel kostenfrei. Bitte klären Sie vor einer Weiterverwendung urheberrechtliche Fragen mit dem angegebenen Herausgeber. Eine systematische Speicherung dieser Daten sowie die Verwendung auch von Teilen dieses Datenbankwerks sind nur mit schriftlicher Genehmigung durch die United News Network GmbH gestattet.

Was Videospiel-Speedruns und Frontend-Entwicklung miteinander zu tun haben

By Firma punkt.de | 6. Oktober 2025

Es gibt Werkzeuge, welche fertigen Code untersuchen können, und Fehler und Sicherheitslücken hervorheben können. Es gibt Listen, welchen man als Entwickler folgen kann.

Aber – wo bleibt denn da der Spaß?

Als begeisterter Computerspieler bin ich ungefähr 2017 auf die Speedrunning-Szene gestoßen, in der es darum geht, ein Videospiel (oder Teile davon) so schnell wie möglich durchzuspielen, wofür Glitches ausgenutzt werden.

"Glitches? Das ist doch nichts anderes als ein Programmierfehler!"

Als Entwickler dachte ich "Glitches? Das ist doch nichts anderes als ein Programmierfehler!" Und damit begann ich, die Speedruns nicht nur mit den Augen eines Spielers, sonder mit den Augen eines Entwicklers zu sehen. Eines meiner Erkenntnisse – Spieleentwicklung und Frontendentwicklung teilen sich gewisse Konzepte und Gedanken – genug, dass es Frontend-Javascript-Frameworks gibt, mit denen Videospiele entwickelt werden können.

Beide Entwicklungs-Umgebungen besitzen Stores zur Datenhaltung und verwenden Events, um Benutzereingaben zu verarbeiten, und bei beiden gibt es ähnliche Fallstricke, wenn ein Benutzer zum falschen Zeitpunkt bestimmte Events auslöst. Bei beiden sollte der Store zentral verwaltet sein und nur definierte, klare Zustände annehmen können.

Als Beispiel für einen Glitch, der sich auf Frontend-Anwendungen abbilden lässt, gibt es zum Beispiel einen der bekanntesten Glitches aller Zeiten – der Backwards Longjump (kurz BLJ) aus Super Mario 64.

In diesem Spiel ist die Geschwindigkeit, welche Mario aufbauen kann, nach oben hin begrenzt – Rückwärts kann man jedoch beliebig schnell werden, wenn man die korrekten Tasten am Controller drückt. Dadurch kann man so schnell werden, dass Mario sich rückwärts durch eine unsichtbare Wand durchmogeln kann, welche ihn eigentlich immer wieder an den Anfang einer Treppe setzen soll.

Durch die Geschwindigkeit befindet man sich in einem Frame vor der Wand und im nächsten Frame dahinter, die Kollision an sich findet nie statt. Durch solche Beispiele werde ich als Programmierer gerne daran erinnert, dass ich beim Validieren von User-Eingaben keine Abkürzungen nutzen sollte, und auch nicht davon ausgehen sollte, dass der User nur Daten sendet, die ich auch erwarte, sondern theoretisch jeder beliebige Wert gesendet werden könnte.

Features, die man "nur noch schnell" einbaut

Weitere Probleme beim Entwickeln sind oft Features, die man "nur noch schnell" einbaut, welche gut gemeint sind, aber vielleicht nicht hundertprozentig notwendig oder nach dem üblichen Qualitätsstandard. Da kann es dann gerne passieren, dass der neue Code Nebenwirkungen hat, welche man als Entwickler nicht erwartet hat. Als Beispiel dafür sehe ich das Spiel The Legend of Zelda – Link’s Awakening, welches voll von derartigen Features ist. Ursprünglich sollte das Spiel ein "Demake" eines Zelda-Spieles auf dem Super Nintendo sein, doch die Entwickler haben ein paar Features implementiert, damit es sich vom Original abhebt.

Eines dieser Features ist der Bombenpfeil – wenn man eine Bombe innerhalb ein paar Frames nach einem Pfeil einsetzt, wird die Bombe an den Pfeil angehängt und explodiert bei Kontakt. Der Fehler dabei – schafft man es, zwei Bomben hintereinander in diesem kurzen Zeitraum zu legen (beispielsweise durch ein Loch im Boden oder einen Bildschirm-Wechsel), dann weiß das Spiel nicht, wo die zweite Bombe angehängt werden soll, und löst eine Zwischensequenz eines Spiel-Objektes an einer bestimmten Stelle im Code aus. Im Falle von einsammelbaren Gegenständen bedeutet dies, dass man diese aus beliebiger Distanz und durch Wände einsammeln kann. An anderen Stellen im Spiel kann man damit Wege freischalten, die erst später oder durch andere, länger dauernde Methoden geöffnet werden sollten.

Solche Beispiele zeigen mir, dass "nur mal schnell" ein Satz ist, über den man sehr genau nachdenken sollte.

Egal, ob Backend oder Frontend – alle kochen mit Wasser

Außerdem sollten Frontend-Entwickler immer daran denken, dass man im Browser jederzeit auf den ausgeführten Code schauen kann, und dass die diversen Build-Tools wie WebPack, Rollup und Vite oft von den Entwicklern selbst so eingestellt werden, dass Sourcemaps erzeugt werden, welche den Code explizit lesbar machen. Dies bedeutet natürlich, dass jede noch so gute Sicherheitsmaßnahme im Code jederzeit nachvollziehbar ist, und man sich lieber doch auf die Security im Backend-Code verlassen sollte.

Bei Videospielen zeigt sich dies auf zweierlei Arten. Zum einen gibt es die Möglichkeit, auf den Arbeitsspeicher des ausgeführten Spieles zu schauen, um nachvollziehen zu können, welcher Wert z.B. für die Lebenspunkte steht, die Munition oder ähnliches. Wenn man diese Werte versteht und bestenfalls sogar noch manipulieren kann, kann man "perfekte" Speedruns gestalten. Zum Anderen gibt es Projekte, welchen den kompilierten Code von Spielen analysieren und die Abläufe erklären. Dadurch werden z.B. internas wie der verwendete Zufallsgenerator oder auch das Verhalten von Gegnern und anderen Spielmechaniken bekannt gemacht, wodurch neue Glitches und Strategien entwickelt werden können.

Alles in Allem lässt sich feststellen, dass alle Programmierer – sei es Backend, Frontend, Spiele, Desktop-Anwendungen, … – auch nur mit Wasser kochen, und auf ziemlich ähnliche Probleme achten müssen. Wieso also nicht mal mit Spiel, Spaß und Speed?

Firmenkontakt und Herausgeber der Meldung:

punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de

Weiterführende Links

Mit Cursor zur eigenen App

By Firma punkt.de | 30. September 2025

Ich bin kein Vollzeit-Entwickler, ehrlich gesagt war ich das auch nie. Seit Jahren bin ich als technischer Product Owner unterwegs und habe ein gewisses Verständnis für unsere Setups, aber Programmieren ist definitiv nicht mein Tagesgeschäft. Genau deshalb wollte ich herausfinden, wie weit man mit einem Tool wie Cursor kommt, wenn man einfach mal selbst ein kleines internes Tool baut – ohne den Anspruch, ein „richtiger“ Entwickler zu sein.

1) Stack wählen: Zwischen Anspruch und Realität

Mein erster Reflex: „Wenn schon, denn schon.“ Früher (so um 2010) habe ich lokal mit MAMP gearbeitet; heute weiß ich: wir fahren Docker/Podman, Services sauber getrennt, alles Container. Also habe ich mich an unseren Projekten orientiert und Cursor eine „erwachsene“ Kombi vorgeschlagen: Postgres als DB, Next.js für den API-/Backend-Layer, React fürs Frontend.

Cursor hat das auch prompt auf die Straße gesetzt – nur leider ist die Straße dabei ständig weggebrochen. Mal startete ein Container nicht, mal war das Routing im Eimer, mal blockierte irgendein Nebencontainer den Rest. Und während unsere Dev-Maschinen mit 64 GB RAM darüber müde lächeln, lief meine brave Management-Büchse heiß: fünf parallele Container, um … eine Startseite zu rendern. Ernsthaft?

Warum es sich lohnt, als Geschäftsführer selbst mal zu (vibe-)codenEine völlig neue Möglichkeit für Nicht-Entwickler, die Herausforderungen zu verstehen.Warum ich das überhaupt versuche

Erstes Learning: „Architektur abspecken“ per Prompt klingt gut, funktioniert aber selten. Cursor behauptet, er könne das; wenn ein Projekt aber einmal in die falsche Richtung losgerannt ist, ist wegwerfen und neu starten fast immer schneller und sauberer. Meine Budget-App habe ich fünfmal komplett blank neu aufgesetzt. Das Wissen bleibt ja im Kopf – der Code darf weg. Die Idee war, eine App zu entwickeln, die automatisch einen Überblick über alle Budgets im Unternehmen liefert, indem sie Daten aus unserer Zeiterfassung und den verschiedenen Angeboten nutzt. So kann ich auf alle relevanten Informationen zugreifen, ohne die einzelnen Projekte manuell durchsuchen zu müssen.

2) Prompting-Aha: Weniger ist manchmal mehr

Nach dem Big-Bang-Fehlschlag kam die nächste (falsche) Idee: „Ist doch KI – wenn ich ihr noch mehr Kontext gebe, wählt sie schon eine kluge Architektur.“ Tat sie auch. Formal korrekt. Praktisch unbrauchbar. Cursor baute engagiert los, fügte Schicht um Schicht hinzu, und nach zwei Stunden war das Einfangen aufwendiger als neu anfangen.

Also habe ich die Richtung gedreht: Schritt für Schritt statt Masterplan. Meine erste wirklich funktionierende Cursor-App war deshalb nicht die Budget-App, sondern ein kleines Monitoring-Dashboard fürs Team.

Klar, unsere Teams brauchen so einen Monitor eigentlich nicht. Wir sind schon vor Jahren auf sinnvolle Alarmierungsstrategien umgestiegen – gerade beim mobilen Arbeiten ist ein Bildschirm im Büro, der rot blinkt, nicht das praktikabelste Mittel. Aber zum Einstieg ins Cursor-Prompting braucht man einen Use Case, der überschaubar ist und trotzdem Nutzen bringt. Und ehrlich: Es hat was Beruhigendes, durchs Teamzimmer zu gehen und grüne Statusanzeigen zu sehen – auch wenn ich weiß, dass bei Fehlern sowieso alle anders benachrichtigt werden.

Der Prompt war radikal simpel: „Nimm diese API und zeig mir das Ergebnis auf einem Dashboard an.“ Kein Architekturessay, keine Datenbankdiskussion. Und plötzlich lief es: Node.js im Backend, React im Frontend, Datenspeicherung erstmal ganz pragmatisch in JSON, weil ich noch keine persistente Ablage brauchte. Nicht hübsch, nicht final – aber das erste echte Erfolgserlebnis.

3) Wenn’s ernst wird: API-Keys und der Umgang mit echten Daten

Nachdem das Dashboard stand und die ersten grünen Anzeigen liefen, kam natürlich die Frage: „Okay, was mache ich jetzt damit?“ Der nächste Schritt war der Zugriff auf echte Systeme – bei mir GitLab und Uptime Kuma – also brauchte ich API-Keys.

Und da wird es für jemanden wie mich, der kein erfahrener Entwickler ist, plötzlich spannend: Zugriffe und Berechtigungen sind kein Nebenthema. Klar, als Geschäftsführer habe ich relativ umfassende Accounts, aber ich bin nicht geübt darin, sensible Daten über APIs oder Datenbanken zu handhaben. Genau hier hilft Austausch mit erfahrenen Entwickler:innen enorm – damit man nicht aus Versehen zu großzügige Zugänge vergibt oder etwas baut, das man später bereut.

Mein persönlicher Guardrail: nur lesende Schnittstellen. Ich habe Cursor ausdrücklich immer wieder gesagt, er solle keine schreibenden Endpunkte generieren. Noch besser: API-Keys, die serverseitig nur Lesezugriff haben. So kann ich gar nicht erst versehentlich Live-Daten verändern.

4) Deployment: Wenn’s ans Team geht – und die KI spooky wird

Lokal lief die App, und ja, ich war stolz wie Bolle. Aber klar: Nur auf meinem Rechner bringt das niemandem etwas. Also musste das Ding „ins Teamzimmer“, sprich: auf einen Server.

Hier hat KI dann wirklich daneben gelegen. Ich habe versucht, das Projekt mit Cursor direkt auf einen unserer proServer zu bringen. Was dann passierte, war, freundlich gesagt, spooky: Cursor bediente sich ziemlich ungefragt meiner SSH-Keys, las in der Server-Doku nach und schien sogar zu erkennen, welcher Pro-Server sudo hat und welcher User nur normaler Anwender ist – und hat dann mit den „richtigen“ Usern angefangen, auf dem Server rumzuschrauben. Zum Glück war das ein leerer Server, den ich nur für diesen Zweck genommen habe.

Das Ergebnis? Irgendwie war die App da, irgendwie lief auch etwas – aber im Browser kam nichts Gescheites an. Richtig stabil wurde es nicht.

Am Ende bin ich zu unseren DevOps-Kollegen gegangen. Die haben das sauber hinter einen Reverse Proxy gestellt, auf Sicherheit geachtet und generell mal geschaut, was die App eigentlich treibt. Fazit: Produktiv-Deployment nur mit Cursor war ein Schuss in den Ofen – das mache ich so nicht wieder. Gerade beim Ausrollen gilt: Sicherheit > Geschwindigkeit.

Genau an der Stelle wurde uns klar: Wenn Menschen, die nicht täglich entwickeln, mit solchen Tools arbeiten, brauchen wir klare, management-kompatible Leitplanken zusätzlich zu den bestehenden Engineering-Standards. Also haben mein Geschäftsführungskollege – der wirklich ein sehr guter Entwickler ist – und ich uns hingesetzt und intensiv ausdiskutiert, was muss sein, was kann sein, wie gehen wir damit um. Das ist dann Stoff für einen separaten Blogpost.

Wenn du herausfinden möchtest, wie du in deinem Unternehmen Räume für solche Experimente schaffst – mit klaren Services im Hintergrund und sicheren Leitplanken – dann sprich uns gerne an.

Und wenn du Lust hast, dich direkt mit mir über Cursor, AI-Coding und den praktischen Nutzen für Projektmanager:innen auszutauschen, melde dich ebenfalls gern – ich teile meine Erfahrungen und freue mich auf den Austausch.

Firmenkontakt und Herausgeber der Meldung:

punkt.de GmbH
Sophienstr. 187
76185 Karlsruhe
Telefon: +49 (721) 9109-0
Telefax: +49 (721) 9109-100
https://www.punkt.de

Weiterführende Links