Warum ich
lynox gebaut habe.
Ich bin 37. Die erste Website, die ich gebaut habe, war die meiner Eltern, mit zwölf — handgeschriebenes HTML und CSS. Der Weg von dort bis hierher ist die Geschichte hier drunter.
Zwölf bis siebenunddreissig
Von dieser ersten Homepage ging es weiter mit einer IT-Lehre und einem eidg. Diplom als Web Project Manager, danach ein professioneller Weg, den ich nicht wirklich geplant hatte: Mit Mitte zwanzig habe ich ein Entwicklungsteam von 10+ Personen bei einem der grösseren Unternehmen geleitet, für die ich gearbeitet habe. 15+ Jahre lang habe ich in der langweiligen-aber-wichtigen Schicht digitaler Arbeit für B2B- und B2C-Schweizer-Unternehmen gesteckt — Analytics, Ads, SEO, Tag Manager, Systemintegration, daten-getriebenes Marketing und die DSGVO-Compliance-Arbeit, die das alles für ein reguliertes Geschäft überhaupt deployable macht. Ich führe nebenbei eine kleine Agentur namens Brandfusion, wo dieselben Skills auf echte Kundendaten angewandt werden: echte Kampagnen, echte Analytics-Streams, echte Strategy-Reviews auf echten Zahlen. Genau diese Arbeit hat mir gezeigt, wie kaputt die operative Schicht kleiner Unternehmen ist.
Der Bruchpunkt
Ende 2025 bin ich ertrunken. Nicht in Kunden — die waren in Ordnung. In Tools. CRM hier, Automations-Tool dort, ChatGPT fürs Denken, GA4 für Analytics, die Ad-Plattformen, das CMS, die Buchhaltung, der E-Mail-Host, der Projekt-Tracker. Jeden Montagmorgen tippte ich denselben Kontext in drei verschiedene Fenster, damit jedes Tool 'verstand', was ich gerade tat. Die Daten sassen in Silos. Die Intelligenz sass in einem anderen Silo. Die zwei zu verbinden war Handarbeit. Da hatte ich AutoGPT schon seit Release ausprobiert — so klumpig es war, die Richtung war klar. Das würde verändern, wie operative Arbeit gemacht wird. Vor sechs Monaten habe ich angefangen, alles, was ich konnte, durch Claude Code zu fahren. Es wurde mein Playground für das Gefühl, was ein Agent-Loop in der Praxis ist. Das Ding ist extrem mächtig für Entwickler — aber Kommandozeilen-Agents werden nie ein kleines Business betreiben. Die CLI ist falsch für Business-Operatoren. Cross-Thread-Memory ist falsch. Neue APIs anbinden ist falsch. Nichts davon ist bereit für jemanden, der nicht schon Entwickler ist.
Was die OSS-Landschaft nicht abdeckt
Anfang 2026 habe ich die OSS-Landschaft evaluiert. Kurz OpenClaw angeschaut, dann Agent Zero in einem Wochenend-Projekt ausprobiert. Mir hat Agent Zero gefallen — saubere Architektur, gute Loops. Aber damit es zu meiner tatsächlichen Arbeitsweise passt, hätte ich das Meiste neu bauen müssen. Die OSS-Landschaft, die ich evaluiert habe — OpenClaw, Agent Zero, die Post-AutoGPT-Welle — ist überwiegend auf individuelles Experimentieren ausgelegt: Chat mit einem schlauen LLM, schau zu wie es ein paar Tools nutzt, sieh was passiert. Grossartige Hobby-Spielwiesen. Was ich brauchte, war anders: etwas, das meine Kunden über Konversationen hinweg kennt, das sich erinnert welche Kampagne letztes Quartal performt hat, das echte Zahlen aus Analytics und Ads zieht wenn ich frage 'wo verliere ich Geld', das Montags KPI-Review auf Cron fährt egal ob ich online bin, das einen verschlüsselten Vault für OAuth-Tokens hat, dem ich einen regulierten Schweizer B2B-Auftrag übergeben kann ohne eine separate Compliance-Schicht zusammenzuhacken. Die existierenden OSS-Tools nehmen an, dass du am Agent iterierst. Ich brauchte etwas, wo ich am Geschäft iteriere und der Agent leise nachzieht.
Warum nicht n8n
Etwa zur gleichen Zeit habe ich mich hingesetzt, um n8n-Flows für meine eigene Agentur zu bauen. Ich habe nach einer Stunde aufgehört. n8n und ähnliche Tools (Zapier, Make) nehmen an, dass die Zukunft Menschen sind, die Systeme auf immer höheren Abstraktionsebenen zusammenstecken. Das Muster, das ich tatsächlich entstehen sah, ist die Umkehrung: Menschen nutzen Agents, und die Agents verbinden die Systeme. Warum also Flows von Hand bauen? Wenn der Agent fähig genug ist, beschreibst du welche API du nutzen willst, und er findet den Rest heraus. Das ist die Wette, die lynox eingeht. Du beschreibst was du verbinden willst — 'verbinde HubSpot', 'aus Shopify holen', 'sprich mit meinem Stripe' — und der Agent liest die Doku und baut eine typisierte Integration. Arbeit, die ich zweimal mache, wird als Workflow aufgezeichnet und geplant. Darunter liegt ein Graph-Store, der Entities (Kunden, Deals, KPIs, Kampagnen) über Konversationen hinweg behält. Ich habe lynox ursprünglich nur für mich selbst bei Brandfusion gebaut — um operative Last von meiner Liste zu nehmen. Etwa einen Monat nach dem Public-Go ist lynox produktiv bei Brandfusion und frühen Self-Hostern im Einsatz.
Falls das Projekt je den Besitzer wechselt, läuft die Kopie, die du deployt hast, weiter.
Warum source-available
Ich habe absichtlich die Elastic License v2 gewählt statt einer OSI-approved Lizenz. ELv2 erlaubt jedem, den Code zu lesen, zu modifizieren, für das eigene Business oder die eigenen Kunden zu deployen und frei zu forken. Die eine Einschränkung: niemand darf lynox als konkurrierenden Managed-Service anbieten — der Zug, der genug Open-Source-Unternehmen unter kommerziellen Druck gesetzt hat, dass es wichtig ist. Die Lizenz-FAQ ist eine eigene Seite; lesenswert, falls dir der Trade-off wichtig ist.
Wohin es geht
lynox wird heute solo gewartet und wächst in ein kleines Team hinein. Öffentliche Roadmap, Fork-Rechte für immer, transparente Preise. Falls das Projekt je den Besitzer wechselt oder pivotet, läuft die Kopie, die du bereits deployt hast, weiter — das ist, was source-available wirklich bedeutet. Es ist für Menschen, die wollen, dass ihr Business-Operations laufen, während sie die Arbeit machen, die nur sie machen können. Wenn das du bist, liegt alles im Repo.