OpenClaw Multi-Agent-Team: Reales Setup, Reale Kosten
Am zweiten Tag erschien eine Abbuchung von 200 Dollar in meinem API-Dashboard.
Ich hatte vier KI-Agenten parallel laufen — jeder mit seinem eigenen Slack-Bot, seiner eigenen Rolle, seinen eigenen geplanten Aufgaben — und die Token-Rechnung traf ein, bevor die Agenten irgendetwas besonders Beeindruckendes geleistet hatten. Nur Konfigurationsarbeit, Speicherindizierung, ein paar explorative Abfragen. Zweihundert Dollar in achtundvierzig Stunden, und ich hatte noch keine einzige Zeile Produktionscode geschrieben.
Diese Zahl war ernüchternd. Aber das war nicht der Moment, der mich innehalten und alles überdenken ließ. Was mich wirklich zum Nachdenken brachte, war das Dashboard, auf das ich schaute — nicht die integrierte Oberfläche von OpenClaw, sondern die benutzerdefinierte Rails-App, für deren Entwicklung ich ein Wochenende aufgewendet hatte, nur um Einblick in das zu bekommen, was meine Agenten taten. Aufgabenverteilung über vier verschiedene Bots. Token-Verbrauch pro Agent. Sitzungsprotokolle. Ein gemeinsamer "Brain Folder", der über alle Agenten synchronisiert war.
Ich hatte Entwickler-Tooling gebaut. Für KI-Agenten. Um sie wie ein Software-Team zu verwalten.
In diesem Moment verstand ich, dass OpenClaw kein KI-Tool im eigentlichen Sinne ist. Es ist eine Infrastrukturkategorie. Und es richtig aufzusetzen — mit echter Sicherheitsisolation, echter Kostenkontrolle und der richtigen Hardware darunter — ist ein grundlegend anderes Problem als eine einzelne Claude-Sitzung zu starten und sie zu bitten, etwas Code zu schreiben.
Dies ist der Beitrag, den ich mir gewünscht hätte, bevor ich anfing.
Warum Ein Agent Nie Ausreichen Würde
Bevor ich OpenClaw ausprobierte, arbeitete ich mit Single-Agent-Workflows. Einem Agenten eine Aufgabe stellen, ein Ergebnis erhalten, weitermachen. Dieses Modell funktioniert gut für klar abgegrenzte, sequenzielle Arbeit — einen Beitrag entwerfen, einen PR reviewen, ein Skript generieren.
Was es nicht leisten kann, ist die gleichzeitige, überlappende Arbeit, die ein kleines Team in der Praxis tatsächlich ausmacht.
Stell dir vor, was ein echtes Vierpersonenteam an einem aktiven Projekttag bewältigt: Jemand debuggt ein Produktionsproblem, jemand beantwortet Kundenfragen, jemand plant den Content der nächsten Woche, jemand schreibt Dokumentation. All das geschieht parallel, mit gemeinsamem Kontext, über verschiedene Systeme und Dateien hinweg. Es wartet nicht darauf, dass jede Aufgabe abgeschlossen ist, bevor die nächste beginnt.
Das ist die Lücke, die Single-Agent-KI nicht schließen kann. Man kann mehrere Claude Code-Sitzungen in separaten Terminals ausführen. Man kann manuell zwischen Aufgaben wechseln. Aber man kann keine persistenten, autonomen Agenten haben, die voneinander wissen, Speicher teilen und im Hintergrund laufen, während man selbst etwas anderes tut.
OpenClaw wurde speziell für dieses parallele Teammodell entwickelt. Es entstand aus früheren Tools (Claudebot, Moltbot) und stellt einen bedeutenden architektonischen Schritt nach vorne dar: ein persistenter Gateway-Prozess, der auf dedizierter Hardware läuft, einen gemeinsamen Arbeitsbereich verwaltet, den Sitzungsverlauf protokolliert und es mehreren Agenten ermöglicht, gleichzeitig über Chat-Oberflächen wie Slack oder Telegram zu arbeiten.
Das Konzept ist solide. Die Einrichtung ist nicht trivial.
Es gibt eine Entscheidung, die man früh trifft und die bestimmt, wie schwierig alles andere wird — und die meisten Menschen treffen sie falsch. Das behandle ich vor allem anderen.
Die Hardware-Entscheidung, Die Niemand Ernst Genug Nimmt
Der Instinkt beim Aufbau eines persistenten Agent-Systems ist, einen VPS zu verwenden. Günstig, remote, immer online. Klingt auf dem Papier sinnvoll.
Was tatsächlich passiert: Man bekommt einen headless Server ohne einfaches Screen Sharing, begrenzte Debugging-Optionen, wenn um drei Uhr nachts etwas kaputt geht, und eine persistente Angriffsfläche, für deren Verwaltung man selbst verantwortlich ist. Und wenn Agenten unerwartete Dinge tun — was sie tun werden, besonders am Anfang — ist die Möglichkeit, in Echtzeit zu sehen, was tatsächlich läuft, enorm wertvoll.
Ich entschied mich stattdessen für einen dedizierten Mac Mini M4. Die Anschaffungskosten liegen bei rund 600 Dollar. Das ist eine echte Zahl. Aber die praktischen Vorteile sind für diesen speziellen Anwendungsfall erheblich:
Screen Sharing funktioniert sofort. Wenn ein Agent unerwartet Token verbrennt, kann ich von jedem Gerät über Screen Sharing einspringen und die Terminal-Ausgabe, die Logs, den Dateisystemstatus — alles in Echtzeit sehen. Auf einem headless VPS erfordert diese Untersuchung SSH-Sitzungen und mühsames Log-Lesen.
Speicher und Leistung sind lokal. Der gemeinsame Arbeitsbereich der Agenten — was ich den Brain Folder nenne — liegt auf schnellem lokalem NVMe-Speicher. Keine Latenz beim Lesen von Dateien, keine unerwarteten Bandbreitenkosten, keine Sorgen um VPS-Speichertarife.
Die Maschine bleibt unter meiner physischen Kontrolle. Das spielt eine größere Rolle, wenn man Sicherheitsisolation für den Agentenzugriff einrichtet. Ich weiß genau, was auf dieser Maschine läuft, welche Netzwerkverbindungen sie hat, und was passiert, wenn ich sie sofort herunterfahren muss.
Für ein Hobbyprojekt, bei dem man gelegentlich einen Agenten betreibt, ist ein VPS völlig in Ordnung. Für ein System, in dem man vier persistente Agenten mit Zugriff auf Entwicklungstools, E-Mail-Konten, GitHub-Repos und Content-Publishing-Systeme betreibt — möchte man eine Maschine, die man vollständig kontrolliert.
Aber hier ist die Sache: Die Hardware ist der einfache Teil des Sicherheitsproblems.
Agenten Wie Echte Teammitglieder Behandeln (Einschließlich der Zugriffskontrollen)
Dies ist das Gestaltungsprinzip, das OpenClaw im großen Maßstab tragfähig macht: KI-Agenten sollten denselben abgegrenzten, isolierten Zugriff haben, den man einem echten Junior-Teammitglied einräumen würde. Kein Root-Zugriff auf alles. Keine vollständige Einsicht in persönliche Konten. Spezifische, nachvollziehbare, eingeschränkte Berechtigungen.
Für mein vierköpfiges Agenten-Team bedeutete das die Einrichtung einer separaten Infrastruktur für jeden Agenten, bevor ich eine einzige Zeile Agenten-Konfiguration schrieb:
GitHub: Ein separater GitHub-Benutzername für den Entwickleragenten (Bernard) mit Zugriff nur auf die Repositories, die er benötigt. Seine Commits sind nachverfolgbar. Sein Push-Zugriff ist begrenzt. Wenn in der Produktion etwas schiefläuft, kann ich sofort sehen, welcher Commit von einem Menschen und welcher von einem Agenten stammt.
E-Mail: Eine dedizierte E-Mail-Adresse für agentengenerierten Schriftverkehr. Kein Zugriff auf meinen persönlichen Posteingang. Agenten können Benachrichtigungen, Berichte und Zusammenfassungen senden — aber sie handeln unter ihrer eigenen Identität, ohne mich zu imitieren.
Dateisystem: Der Brain Folder ist ein spezifisches Verzeichnis mit einer Dropbox-Freigabe, die Agenten Zugriff auf genau diese Dateien gewährt. Nicht meine persönliche Dropbox. Nicht meine Kundenprojektordner. Ein abgegrenzter Bereich mit kontrolliertem Umfang.
API-Schlüssel: Der Slack-Bot jedes Agenten hat seinen eigenen Token. API-Schlüssel sind pro Agent und unabhängig voneinander rotierbar. Wenn der Schlüssel eines Agenten kompromittiert wird oder zurückgesetzt werden muss, laufen die anderen weiter.
Das Einrichten dauerte länger als das Konfigurieren von OpenClaw selbst. Aber die Alternative — Agenten mit breitem Zugriff auf persönliche Konten und Systeme — ist kein Team-Management-Problem. Es ist eine Haftungsfrage.
Das Sicherheitsdesign spiegelt wider, wie gute Engineering-Teams arbeiten: geringstes Privileg, klare Rechenschaftspflicht, nachvollziehbare Aktionen. Die Tatsache, dass man KI-Agenten statt menschliche Entwickler verwaltet, ändert diese Grundsätze nicht.
Nun zu den eigentlichen Agenten — und hier wird die Konfiguration interessant.
Die Vier Agenten Konfigurieren: Rollen, Persönlichkeiten und die Slack-Architektur
Die Vier-Agenten-Teamstruktur, die nach Experimenten entstanden ist:
Claw übernimmt die Systemadministration. Monitoring, Infrastrukturgesundheit, Log-Analyse, die Metaarbeit, die anderen Agenten am Laufen zu halten. Claw verwendet für komplexe Reasoning-Aufgaben eine leistungsstärkere Modellstufe — in der Praxis Claude claude-opus-4-6, wenn die Aufgabe es erfordert.
Bernard ist der Entwickler. Backlog-Triage, PR-Review, Fehlerverfolgung, Dokumentationsaktualisierungen, wenn ich nicht verfügbar bin. Bernard läuft für die meisten Aufgaben auf einer mittleren Modellstufe und eskaliert nur für wirklich komplexes Debugging zu einem leistungsstärkeren Modell. Diese einzelne Optimierung — Aufgabenkomplexität auf Modellstufe abzustimmen — ist der Hauptgrund, warum sich meine Token-Kosten nach Tag zwei stabilisierten.
Vale kümmert sich um Marketing und Content-Arbeit. Social-Media-Planung, Content-Kalender-Management, das Festhalten von Erkenntnissen aus Projektarbeiten, die es sonst nicht in öffentliche Beiträge schaffen. Vale verarbeitet viele textlastige Aufgaben, bei denen ein leistungsfähiges, aber kosteneffizientes Modell gut funktioniert.
Gumbo ist der Generalassistent — das Bindeglied. Planung, Koordination, Dokumentation, der administrative Overhead, der in jedem Team existiert und typischerweise durchs Raster fällt. Gumbo erledigt die Aufgaben, die nirgendwo sonst klar zugeordnet sind.
Jeder Agent hat seinen eigenen Slack-Bot, seine eigene Identität, seinen eigenen Avatar. (Wenn man KI-Teammitglieder haben wird, sollte man das voll auskosten — die Gorillaz-inspirierten Avatare waren ein 20-Minuten-Projekt, das die Art, wie ich mit den Agenten interagiere, spürbar verbessert hat. Ein Gesicht auf dem Bot lässt die Kommunikation weniger wie das Abfragen eines Dienstes und mehr wie das Schreiben an einen Kollegen wirken.)
Warum Slack statt Telegram
Ich begann mit Telegram, weil die Einrichtung schneller geht. Aber Slack hat zwei Vorteile, die auf dieser Teamgröße wichtig sind: ordentliches Markdown-Rendering in Nachrichten und Thread-Gespräche. Wenn Bernard über einen PR-Review berichtet oder Vale ein Content-Kalender-Update sendet, ist die Formatierung lesbar, ohne Escape-Zeichen durchsuchen zu müssen. Threads ermöglichen es mir, auf den Bericht eines bestimmten Agenten zu antworten, ohne die anderen Kanäle zu unterbrechen.
Das Multi-Bot-Slack-Setup (ein Workspace, vier Bots, ein Kanal pro Agent plus ein gemeinsamer allgemeiner Kanal) ist nun der Ort, von dem aus ich das gesamte Team verwalte. Befehle gehen rein, Berichte kommen raus, Eskalationen erfolgen über Thread-Antworten. Es funktioniert so, wie ich erwartet hatte, dass gemeinsame Agentenkommunikation funktionieren würde, bevor ich die Alternativen ausprobiert hatte.
Das Kostenkontrollproblem: Open Router und Modellauswahl
Hier scheitern die meisten Multi-Agent-Setups lautlos, bis die Rechnung eintrifft.
Vier persistente Agenten zu betreiben, die den ganzen Tag API-Aufrufe tätigen, erzeugt Token-Ausgaben, die sich schnell summieren. Der naive Ansatz — alles auf das leistungsstärkste Modell ausrichten — liefert exzellente Agenten-Ausgaben und katastrophale Abrechnungen. Der überkorrekte Ansatz — alles auf das günstigste Modell beschränken — liefert schnelle, günstige, mittelmäßige Ergebnisse, die den Sinn leistungsfähiger Agenten zunichte machen.
Der richtige Ansatz ist Routing: Aufgabenkomplexität auf Modellkapazität abstimmen, und das systematisch.
Ich verwende Open Router als zentralen API-Gateway für alle vier Agenten. Anstatt dass jeder Agent die Anthropic API direkt aufruft, rufen sie Open Router mit einer Modellspezifikation auf. Dies ermöglicht mir:
Modelle pro Aufgabentyp wechseln, ohne die Agenten-Konfiguration anzupassen. Vales Content-Aufgaben laufen standardmäßig auf Sonnet. Claws Infrastrukturanalyse eskaliert bei einem wirklich komplexen Problem zu Opus. Bernards routinemäßiges Code-Review läuft effizient; sein Produktions-Debugging erhält das volle Modell.
Ausgaben pro Agent in einem Dashboard verfolgen. Open Router bietet mir eine einzige Abrechnungsansicht über alle Anbieter und Modelle. Ich kann sehen, dass Bernard an einem beliebigen Tag dreimal so viel verbrennt wie Vale, und untersuchen, ob das angemessen ist (komplexer Dev-Sprint) oder ein Konfigurationsproblem vorliegt (Agent in einer Retry-Schleife feststeckend).
API-Nutzung der Agenten von der persönlichen Nutzung trennen. Das ist für die Klarheit der Nutzungsbedingungen wichtig. Abonnementpläne haben spezifische Bedingungen rund um agentische Nutzung. Den Agenten-Traffic auf einem separaten API-Schlüssel über Open Router zu halten — getrennt von meinem persönlichen Claude-Abonnement — bewahrt eine saubere Trennung und vermeidet Unklarheiten.
Die Unklarheit selbst ist es wert, benannt zu werden: Stand Anfang 2026 sind die Bedingungen rund um den Betrieb persistenter Agenten-Systeme auf Abonnementplänen nicht einheitlich klar bei allen Anbietern. Wenn man in irgendeiner bedeutenden Größenordnung arbeitet, sollte man die aktuellen Bedingungen sorgfältig lesen und die Abrechnung entsprechend trennen.
Die Token-Ausgaben stabilisierten sich um Tag vier, nachdem ich die Modell-Routing-Regeln abgestimmt und einige aggressive Cron-Jobs entfernt hatte, die unnötige Aufgaben ausführten. Derzeit befinde ich mich auf einem handhabbaren Niveau für den Wert, den das Team produziert — aber ich bin ehrlich, dass die erste Woche mehr kostete, als ich erwartet hatte.
Wenn Die Eingebauten Tools Nicht Ausreichen
OpenClaws integrierte Aufgabenplanung ist für einfache, wiederkehrende Einzelagenten-Aufgaben ausreichend. Für die Verwaltung von vier Agenten mit unterschiedlichen Aufgabenplänen, Prioritätsstufen und Zuweisungslogik reicht sie nicht aus.
Diese Lücke ist der Grund, warum ich ein Wochenende damit verbracht habe, ein benutzerdefiniertes Rails-Dashboard zu bauen.
Das Dashboard erledigt drei Dinge, die die OpenClaw-Oberfläche nicht gut handhabt:
Aufgabenzuweisung per Agent. Anstatt Aufgaben generisch in die Warteschlange zu stellen, kann ich bestimmte Arbeiten bestimmten Agenten zuweisen — "diese Content-Recherche geht an Vale, diese Backlog-Triage geht an Bernard" — und auf einen Blick sehen, wie die aktuelle Auslastung jedes Agenten aussieht.
Token-Nutzungsvisualisierung pro Agent. Nicht nur Gesamtausgaben, sondern Ausgaben über die Zeit pro Agent, mit der Möglichkeit, in einzelne Sitzungen zu bohren. Als ich bemerkte, dass Claw an einem Dienstag ungewöhnlich hohe Token-Ausgaben hatte, konnte ich es auf ein Monitoring-Skript zurückführen, das in eine Schleife geraten war. In zehn Minuten aufgespürt und behoben, anstatt als Überraschung auf der nächsten Rechnung aufzutauchen.
Ein Markdown-Editor für den Brain Folder. Das gemeinsame Gedächtnissystem, aus dem alle vier Agenten lesen, ist ein Ordner mit Markdown-Dateien. Ohne eine anständige Bearbeitungsschnittstelle wird die Pflege dieses gemeinsamen Kontexts zur Reibungsquelle. Das Dashboard enthält einen einfachen Editor zum Hinzufügen, Aktualisieren und Organisieren dieser Dateien — was die gemeinsame Wissensbasis der Agenten aktuell hält, ohne dass ich sie über das Terminal verwalten muss.
Der Aufbau war eine Entscheidung, über die ich debattiert habe. Es gibt vorhandenes Tooling. Es gibt andere Dashboards. Aber die spezifische Kombination dessen, was ich brauchte — agentenbewusste Aufgabenplanung, agentenbezogenes Token-Tracking, Brain-Folder-Bearbeitung — existierte nicht in einem einzigen Paket. Zwei Tage Rails-Arbeit produzierten etwas, das nun jeden Tag läuft.
Wenn man mehr als zwei Agenten mit nennenswerten Aufgabenvolumen betreibt, sollte man benutzerdefiniertes Tooling einplanen. Die Out-of-the-Box-Erfahrung ist ein Ausgangspunkt, kein Ziel.
Das Ehrliche Bild: Was Sich Wirklich Verbessert und Was Nicht
Nach mehreren Wochen Betrieb eines Multi-Agent-Teams hier die ehrliche Beurteilung.
Was sich tatsächlich verbessert:
Die Bindegliedarbeit verschwindet. Der administrative Overhead — Planung, Dokumentation, Statusaktualisierungen, Log-Reviews — findet nun ohne meine Aufmerksamkeit statt. Gumbo erledigt es. Die kognitive Entlastung, diese Aufgaben nicht mehr im Kopf behalten zu müssen, ist real und wächst über die Zeit, während man den Agenten darauf trainiert, mehr von den eigenen spezifischen Mustern zu übernehmen.
Content-Erfassung wird automatisch. Jedes Projekt produziert Erkenntnisse, die es nie in öffentliche Beiträge schaffen, weil keine Zeit bleibt, sie aufzuschreiben. Vale erfasst diese nun, sobald sie entstehen, erstellt Notizen und markiert sie für spätere Ausarbeitung. Material, das früher verschwand, hat nun einen Platz.
Entwicklungsarbeit läuft asynchron weiter. Wenn ich in einer Besprechung bin oder nicht verfügbar bin, arbeitet Bernard weiter am Backlog. Kleine Probleme werden untersucht. Dokumentation wird aktualisiert. PRs liegen nicht stundenlang brach. Das Team pausiert nicht, wenn ich nicht zuschaue.
Was sich (noch) nicht verbessert:
Komplexe, urteilsintensive Arbeit braucht mich nach wie vor. Agenten handeln Ausführung gut ab. Strategische Entscheidungen — was als nächstes zu bauen, wie auf eine schwierige Kundensituation zu reagieren, ob eine Produktrichtung Sinn ergibt — erfordern immer noch menschliches Urteilsvermögen. Das Team ist gut darin, Dinge zu tun, nicht darin, zu entscheiden, welche Dinge zu tun sind.
Die Einrichtungskurve ist real. Ich habe mehr Zeit damit verbracht, OpenClaw zu konfigurieren, Sicherheitsisolation aufzubauen, das Dashboard zu erstellen und das Agenten-Verhalten zu optimieren, als an den meisten Feature-Projekten. Dies ist kein Plug-in-und-los-System. Es ist Infrastruktur, die Engineering-Denken erfordert, um sie richtig einzurichten.
OpenClaw ist in einem frühen Stadium. Die Plattform verbessert sich schnell, aber es gibt raue Kanten. Man sollte damit rechnen, dass Dinge gelegentlich kaputt gehen. Man sollte damit rechnen, Agenten-Verhalten auf eine Art zu debuggen, die bei einem herkömmlichen SaaS-Tool nicht notwendig wäre. Die Entwickler reagieren schnell und die Community ist aktiv, aber ausgereifte Politur ist noch nicht vorhanden.
Die Kostenrealität:
Ein aktiv laufendes Vier-Agenten-Team kostet echtes Geld. Wie viel hängt von Aufgabenvolumen und Modellauswahl ab — aber man sollte bedeutungsvolle, keine theoretische Budgetplanung machen. Die erste Woche kostet mehr als erwartet, während man kalibriert. Nach der Kalibrierung ergeben die Kosten Sinn, wenn man das Team tatsächlich einsetzt, um Arbeit zu produzieren. Wenn Agenten laufen, aber keinen Wert produzieren, merkt man das sofort an den Token-Ausgaben.
Was Das Team Ermöglicht, Was Ein Tool Nie Könnte
Dies ist der Wandel, der am schwierigsten zu beschreiben ist, bis man ihn erlebt hat: Die Arbeit mit persistenten Agenten verändert, wie man über das Mögliche in einer gegebenen Woche denkt.
Mit Single-Agent-Tools filtere ich Aufgaben mental durch eine Linse: "Ist das den Overhead des Startens einer Sitzung wert?" Kurze Aufgaben schaffen diese Hürde oft nicht. Kontextwechsel kostet Energie. Das Tool dient mir, wenn ich es aktiv nutze, und steht dann brach.
Mit einem persistenten Team verschwindet dieser Filter. Vale arbeitet bereits an Content. Bernard beobachtet bereits das Backlog. Gumbo kümmert sich im Hintergrund um die Planung. Aufgaben, die unter meiner Schwelle von "es wert, manuell zu erledigen" liegen, werden trotzdem abgeschlossen, weil das Team immer läuft.
Dieser Wandel akkumuliert sich. Arbeit, die früher aufgrund von Priorisierung verdampfte, wird nun abgeschlossen. Ideen werden festgehalten statt vergessen. Code bleibt dokumentiert statt nach und nach zu Archäologie zu werden.
Das Team ersetzt weder mein Urteilsvermögen noch meine Kreativität. Es beseitigt die Reibung rund um Ausführung. Und das konsequente Beseitigen von Ausführungsreibung in großem Maßstab verändert sich, was für einen Solo-Builder möglich ist, auf Weisen, die sich kaum vollständig antizipieren lassen, bis man sie gespürt hat.
Entwirf Dein Team Diese Woche
Nicht die vollständige Implementierung. Nur den Entwurf.
Setz dich hin und beantworte ehrlich: Was sind die drei wiederkehrenden Aufgaben in deiner Arbeit, die Zeit kosten, aber nicht dein bestes Denken erfordern? Was ist die Bindegliedarbeit, der administrative Overhead, die Dokumentation, die immer zurückfällt?
Diese drei Aufgaben sind dein erster Agenten-Brief. Schreib sie auf, als würdest du ein neues Teammitglied einarbeiten — was es wissen muss, welchen Zugriff es bräuchte, wie "gut erledigt" für jede Aufgabe aussieht.
Beantworte dann die schwierigere Frage: Welche dieser Aufgaben gehören zum selben Agenten, und welche gehören zu verschiedenen Agenten mit unterschiedlichen Spezialisierungen?
Diese Entwurfsübung lehrt mehr darüber, wie Multi-Agent-Systeme tatsächlich funktionieren, als jede Menge Lektüre darüber. Die Einschränkungen werden real. Die Zugriffsanforderungen werden konkret. Die Modell-Routing-Entscheidungen haben offensichtlich richtige Antworten statt abstrakte Abwägungen.
Ich startete meine erste Live-Sitzung mit allen vier aktiven Agenten an einem Donnerstagmorgen. Bis Freitagmittag hatte Gumbo meinen gesamten wöchentlichen Planungsblock erledigt, Vale hatte drei Content-Stücke aus Projektnotizen entworfen, die ich vergessen hatte, und Bernard hatte vier Backlog-Punkte abgearbeitet, die ich schon länger vor mir herschob.
Das ist keine Demo. Das ist ein Team.
Bau deins.
🤝 Lass Uns Zusammenarbeiten
Du möchtest KI-Systeme aufbauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe dir gerne.
- 🔗 Fiverr (individuelle Builds & Integrationen): fiverr.com/s/EgxYmWD
- 🌐 Portfolio: mejba.me
- 🏢 Ramlit Limited (Enterprise-Lösungen): ramlit.com
- 🎨 ColorPark (Design & Branding): colorpark.io
- 🛡 xCyberSecurity (Sicherheitsdienstleistungen): xcybersecurity.io
