WHITEPAPER

Das JAMstack-Ökosystem für ehrliche Open-Source-Alternativen zu Worldsoft, Shopware und Odoo

Stand: April 2026 Autor: DevOps / cBUZZ.IO + inFactory.com Review: Claude Pro (Opus 4.7) Status: Strategiedokument v1.0 Mission: Kaizen (改善) — Jeden Tag 1% besser.

i-NIC.com ☀ Domains kaufen, verkaufen oder mieten.

↸ Zurück zur Lead-Page ⒈)🔸Über infactory.com ☀️ ⒉)🔸You@ in.infactory.com ＠ ⒊)🔸Projekt umsetzen ䷴

inFactory@ /YOU <> https://inFactory.at <> https://inFactory.com <>

Executive Summary

inFactory@ ist der Rahmen für ein modulares JAMstack-Ökosystem, das den technologischen Paradigmenwechsel vom monolithischen SaaS (Worldsoft-Stil) und monolithischen Open-Source-ERP (Odoo/Shopware-Stil) zum composable, API-first, headless Ansatz vollzieht.

Die drei Kernerkenntnisse:

Worldsoft hat 2005–2017 bewiesen, dass ein integriertes "alles aus einer Hand"-Ökosystem in DACH funktioniert — mit 25.000 Firmenkunden und einem Partner-Netzwerk in über 300 Städten. Die Produktvision war richtig; das technologische Fundament und die MLM-artige Vertriebsrhetorik sind überholt.
Odoo und Shopware sind die besten monolithischen Open-Source-Antworten — aber auch sie stoßen an Grenzen moderner Webtechnologie (Server-rendered Templates, schwerfällige Upgrades, begrenzte AI-Agent-Tauglichkeit).
Der natürliche Nachfolger ist ein Composable Stack: Payload CMS + Puck Editor + Medusa.js + Next.js — TypeScript durchgängig, MIT-Lizenziert, CDN-geliefert, AI-Agent-nativ.

inFactory@ erbt die Produkt-Vision von Worldsoft, die DACH-Business-Logik von Odoo, das eCommerce-Konzeptwissen von Shopware — aber keine einzige Zeile ihres Codes. Stattdessen: moderne JAMstack-Bausteine, als Funktions-Fork (Lernen, nicht Kopieren) kombiniert.

Das Partner-Programm von cBUZZ.IO bildet den Vertriebs-Fork von Worldsoft — Lifetime-Provisionen ohne Franchise-Zwang, ohne Seminar-Gebühren, ohne Zertifizierungs-Pyramide.

Roadmap-Eckpunkte:

Q2 2026: Foundation / Phase 0 (Payload + Puck + Next.js Starter)
Q3 2026: /Studio Launch (Content & Landing Pages)
Q4 2026: /Shop MVP (Medusa-basiert, DACH-Lokalisierung)
2027: /CRM, /Rechnung, /Lager als Iterations-Pipeline

Teil I: Was wir von Worldsoft lernen

1.1 Die Erfolgsfaktoren 2005–2017

Worldsoft hat in der Pionierphase des europäischen SaaS-Marktes eine Kategorie aufgebaut, die es zuvor nicht gab: das integrierte Kleinunternehmer-Ökosystem für DACH-KMU. Sieben Faktoren haben das möglich gemacht:

1. Produkt aus einer Hand. CMS + CRM + E-Mail-Marketing + Shop + Faktura + Affiliate in einer Oberfläche, ein Login, ein Ansprechpartner. Für einen Handwerker, einen Coach, einen Kleinhändler war das 2008 revolutionär — HubSpot war in Europa unbekannt, ActiveCampaign existierte noch nicht.

2. SaaS-Mietmodell von Anfang an. Kein Softwarekauf, keine Update-Gebühren, keine eigene Server-Infrastruktur. Damit 10 Jahre vor dem Marktstandard positioniert.

3. FollowUp-Automation als echter USP. Die WBS konnte "Formular ausgefüllt → E-Mail-Serie → Rechnungsstellung → Affiliate-Tracking" automatisch durchlaufen. Das war 2010 in Deutschland praktisch konkurrenzlos im KMU-Segment.

4. Franchise-Partner-Netzwerk. Statt Direktvertrieb: Quereinsteiger als zertifizierte "Internet Success Coaches" in über 300 Städten Europas. Skalierung ohne eigene Vertriebskosten.

5. Lifetime-Provisionen statt Kopfprämien. 20% auf Hosting-Gebühren, lebenslang. Das hat echte Loyalität erzeugt — Partner hatten ein Interesse, dass ihre Kunden bleiben.

6. Technikpartner-Framing. "Ihr seid Marketingexperten, wir kümmern uns um die Technik." Diese Rollentrennung war psychologisch brillant und hat Agenturen entlastet.

7. DACH-Fokus ohne Internationalisierungs-Ambitionen. Keine US-Konkurrenz-Hysterie, keine Multi-Market-Zerrissenheit. Klare Positionierung auf Deutsch, klare Rechnungsstellung in Euro/Franken.

1.2 Warum es heute ein Auslaufmodell ist

Die gleichen Faktoren, die 2005–2017 Stärken waren, sind 2026 Schwächen geworden:

Damals Stärke	Heute Schwäche
Proprietäres SaaS ("alles aus einer Hand")	Vendor-Lock-in, kein Datenexport, 25.000 Websites würden bei einer Insolvenz stillstehen
Eigenes CMS	Server-rendered PHP, keine JAMstack-Performance, Google Core Web Vitals problematisch
FollowUp-Automation als Pionier	ActiveCampaign, Brevo, Mautic, HubSpot sind heute ausgereifter und günstiger
Franchise-Partner mit Seminar-Pflicht	"Internet Success Coach"-Rhetorik klingt heute wie MLM, schreckt seriöse Agenturen ab
"Kein Software-Kauf" als USP	Heute Standard — jede Open-Source-Lösung ist günstiger und portabler
Monatliche Hostinggebühr	Pro-Feature-Pricing (Lightning, ActiveCampaign, Ghost) ist transparenter
Admin-UI aus 2012	Moderne Nutzer erwarten mobile-first, keyboard-shortcuts, dark mode
Keine API, kein Headless	AI-Agenten können nicht integrieren, kein Headless für Mobile Apps

Die Firma ist heute nicht tot — sie hat laut eigenen Angaben 4,8/5-Sterne bei Google-Bewertungen und ein funktionierendes Bestandsgeschäft. Aber die Neukunden-Akquise ist leiser geworden, die Partner-Websites wirken wie Wartungs-Portfolios, und der Tech-Stack ist seit zehn Jahren nicht architektonisch erneuert worden.

1.3 Was davon übertragbar bleibt

Von Worldsoft übernehmen wir die Produktvision und das Vertriebsmodell, nicht die Technologie:

Produkt-Integration aus einer Hand → bei uns als composable Module, nicht als Monolith
Lifetime-Provisionen für Partner → bei uns 40% Reseller / 30% Affiliate ohne Seminar-Zwang
DACH-Fokus ohne globale Hysterie → bei uns explizit AT/DE/CH/LI
Technikpartner-Framing → bei uns "cBUZZ.IO kümmert sich um Hosting, ihr um die Kundenprojekte"

Nicht übernommen:

❌ Proprietäres SaaS (wir sind 100% Open Source)
❌ Franchise-Zwang mit Zertifizierungs-Pyramide
❌ "Internet Success Coach"-Rhetorik / "Lizenz zum Geldverdienen"
❌ Monolith-Admin-UI
❌ Vendor-Lock-in durch fehlende Export-Möglichkeiten

Teil II: Der technologische Paradigmenwechsel

2.1 Monolith → Headless: Der Abstand

Zwischen dem Worldsoft-/Odoo-/Shopware-Paradigma und dem inFactory@-Ansatz liegt nicht eine technische Iteration, sondern ein Generationssprung. Vier Architektur-Dimensionen verdeutlichen das:

Rendering-Architektur:

Worldsoft / Odoo / Shopware:     Browser → Server renders page → HTML
                                 (bei jedem Request aufs Neue)

inFactory@ /Headless:            Build-Time: Content → Static HTML → CDN
                                 Runtime:   Browser → CDN (instant)

Datenfluss:

Monolith:                        UI und Daten im selben Request gekoppelt

Headless:                        UI (Next.js) ↔ API (Payload/Medusa) ↔ DB
                                 Mobile App, Smart Watch, AI Agent — alle
                                 nutzen dieselbe API

AI-Agent-Kompatibilität:

Worldsoft CMS:                   Keine öffentliche API
Odoo / Shopware:                 Admin-APIs vorhanden, aber XML-/PHP-Eigenheiten
                                 machen LLM-Integration mühsam

inFactory@:                      TypeScript-Interfaces, JSON-APIs, React-Komponenten
                                 → Claude Code generiert zuverlässig lauffähigen Code

Upgrade-Pfad:

Monolith:                        Major-Release = "Migration", Wochen bis Monate Arbeit

JAMstack:                        npm update, git merge, deploy — Minuten bis Stunden

2.2 Tech-Stack-Vergleich 2026: Worldsoft vs. cBUZZ.IO/inFactory@

Dimension	Worldsoft AG 2026	cBUZZ.IO / inFactory@ 2026
Architektur	Proprietärer Monolith (SaaS)	Composable, API-first, Headless
Lizenz	Proprietär	MIT / LGPL v3 durchgängig
Frontend-Tech	PHP-Templates, jQuery-Ära	Next.js 15 + React 19 + TypeScript
Backend-Tech	PHP/MySQL (unbestätigt, nicht öffentlich dokumentiert)	Node.js + PostgreSQL + Drizzle ORM
CMS	Worldsoft-CMS (proprietär)	Payload CMS (MIT, TypeScript)
Visual Editor	Worldsoft-eigener Template-Editor	Puck Editor (MIT, React)
eCommerce-Engine	WBS-Shop-Modul (proprietär)	Medusa.js (MIT, TypeScript)
Marketing-Automation	WBS FollowUp-System	Mautic / Brevo / eigene Workflows
Hosting	2 Schweizer Rechenzentren, HP-Server	EU-Hosting (AT/DE/CY), 100% Ökostrom
API	Keine öffentliche	REST + GraphQL nativ
Mobile	Responsive Web	PWA, Native App möglich
Performance	Origin-gerendert	CDN-geliefert (sub-100ms global)
AI-Integration	Keine	Nativ via MCP, API, Claude Code
Datenexport	Keine dokumentierte Möglichkeit	PostgreSQL-Dump, JSON, CSV jederzeit
Update-Modell	"Keine Update-Kosten" (schleichende Stagnation)	Opt-in via git, kontinuierliche Upgrades
Entwickler-Zugang	Geschlossen	GitHub, npm, vollständig einsehbar
Preis (Einstieg)	Monatliche Hosting-Miete (Details intransparent)	Connect €4,90/M
Preis (eCommerce)	WBS-Paket (Preis auf Anfrage)	eCommerce €69,00/M

Zentrale Erkenntnis: Der Preisunterschied ist nicht das eigentliche Thema. Entscheidend ist, dass inFactory@-Kunden jederzeit weggehen können — mit ihren Daten, ihrem Code, ihrem Design. Wir machen keinen Druck, wir überzeugen durch Leistung. Bei Worldsoft-Kunden ist genau dieser Exit-Pfad versperrt.

Teil III: Die inFactory@ /Headless Architektur

Das inFactory@-Ökosystem besteht aus spezialisierten Modulen, die alle auf demselben technologischen Fundament laufen:

┌─────────────────────────────────────────────────────────────┐
│              inFactory@ SHARED FOUNDATION                    │
│  ─────────────────────────────────────────────────────────  │
│  TypeScript 5+ · React 19 · Next.js 15 · Node.js 22         │
│  PostgreSQL 16 · Drizzle/Prisma · MIT License durchgängig   │
│  Puck Editor als universeller Visual Editor                 │
│  Claude Code als AI-Agent-Partner                           │
└─────────────────────────────────────────────────────────────┘
                              ↑
     ┌────────────────────────┼────────────────────────┐
     ↓                        ↓                        ↓
┌─────────┐            ┌─────────────┐          ┌──────────────┐
│ /Studio │            │    /Shop    │          │  Weitere     │
│ Content │            │  Commerce   │          │  Module      │
└─────────┘            └─────────────┘          └──────────────┘

Kapitel 3.1 — inFactory@ /Studio

Zweck: Content-Management-System für Websites, Landingpages, Marketing-Content, Newsletter-Grundlagen.

Technik-Stack:

Komponente	Rolle	Lizenz
Payload CMS (v3+)	Headless CMS, Admin UI, REST+GraphQL API	MIT
Puck Editor	Visual Page Builder, Drag & Drop Components	MIT
Next.js 15	Frontend, Static Generation, SEO	MIT
PostgreSQL	Content-Datenhaltung	PostgreSQL License
React 19	Komponenten-Bibliothek	MIT

Warum diese Kombination:

Payload ist das am schnellsten wachsende TypeScript-native Headless CMS, Code-first, mit nativer Next.js-Integration
Puck ist ein spezialisierter Visual Editor für React-Komponenten, der in Payload als Feld/Plugin integriert werden kann (siehe @delmaredigital/payload-puck, aktiv gepflegt)
Next.js 15 liefert Static Generation für maximale Performance, mit dynamischen Islands wo nötig
Alle drei Komponenten teilen MIT-Lizenz — maximale Lizenz-Freiheit für cBUZZ.IO-Kunden

Zielgruppe von /Studio (im cBUZZ.IO-Paket-Kontext):

Connect (€4,90/M) — einfache Marketing-Websites
Combo (€9,90/M) — komplexe Websites mit Multi-Page-Strukturen
Unlimited (€19,90/M) — Content-Business mit Newsletter, Memberships (Ghost-Alternative)

Architektur-Skizze:

┌──────────────────────────────────────────────────┐
│  inFactory@ /Studio — Architektur                │
├──────────────────────────────────────────────────┤
│                                                  │
│  ┌────────────────┐    ┌────────────────────┐   │
│  │  Content-Team  │───▶│  Payload Admin UI  │   │
│  │  (Redaktion)   │    │  + Puck Editor     │   │
│  └────────────────┘    └──────────┬─────────┘   │
│                                    │             │
│                                    ▼             │
│                         ┌────────────────────┐   │
│                         │   PostgreSQL 16    │   │
│                         │   (Content Store)  │   │
│                         └──────────┬─────────┘   │
│                                    │             │
│                     Build-Time     │             │
│                                    ▼             │
│  ┌─────────────┐          ┌────────────────┐    │
│  │  Besucher   │◀─────────│  Next.js 15    │    │
│  │  (Browser)  │   CDN    │  Static Output │    │
│  └─────────────┘          └────────────────┘    │
│                                                  │
└──────────────────────────────────────────────────┘

Kapitel 3.2 — inFactory@ /Shop

Zweck: Vollständige eCommerce-Plattform als Alternative zu Shopware 6 und Odoo eCommerce.

Technik-Stack:

Komponente	Rolle	Lizenz
Medusa.js (v2+)	Commerce-Engine (Cart, Checkout, Orders, Tax, Inventory)	MIT
Payload CMS	Admin-Overlay, Content-Seiten, Marketing-Inhalte	MIT
Puck Editor	Visual Editor für Shop-Pages, Landing Pages, Kategorie-Layouts	MIT
Next.js 15	Storefront, SSG + ISR für Produktseiten	MIT
PostgreSQL 16	Produkte, Bestellungen, Kunden	PostgreSQL License
Stripe / PayPal / Mollie	Payment-Provider (swappable Modules)	Proprietär (nur APIs)

Funktions-Fork aus Shopware + Odoo eCommerce + Odoo Studio:

Wir forken keinen Code — wir forken Konzepte. Konkret:

Übernommenes Konzept	Ursprung	inFactory@-Implementation
Shopping Experiences (Sections → Blocks → Elements)	Shopware 6	Puck-Komponenten-Hierarchie mit derselben Logik
Rule Builder (visuelle Bedingungen)	Shopware 6	TypeScript-DSL + React-Admin-UI, AI-generierbar
Flow Builder (Workflow-Automation)	Shopware 6	Trigger.dev oder n8n-Integration, API-gesteuert
Produktvariants + Kombinationen	Odoo eCommerce	Medusa-nativ (ProductVariant Entity)
Make-to-Order Workflows	Odoo	Medusa-Extensions + eigene Workflows
Studio-ähnlicher Visual Builder	Odoo Studio / Flectra	Puck + Claude Code (besser als beide Originale)
B2B-Kundengruppen + Preislisten	Odoo + Shopware Rise	Medusa Customer Groups + Price Lists (nativ)
DACH-Steuer-Logik (USt, Reverse Charge, UID-Prüfung)	Odoo l10n-at/de/ch	Medusa Tax Module + eigene DACH-Plugins

Architektur-Skizze:

┌─────────────────────────────────────────────────────────┐
│  inFactory@ /Shop — Composable Commerce                 │
├─────────────────────────────────────────────────────────┤
│                                                         │
│   ┌────────────────┐      ┌────────────────────────┐   │
│   │  Shop-Betreiber│─────▶│  Payload Admin UI      │   │
│   │   (Merchant)   │      │  (Content + Marketing) │   │
│   └────────────────┘      └──────────┬─────────────┘   │
│                                       │                 │
│   ┌────────────────┐      ┌──────────▼─────────────┐   │
│   │  Shop-Manager  │─────▶│  Medusa Admin Dashboard│   │
│   │  (Bestellungen)│      │  (Orders, Inventory)   │   │
│   └────────────────┘      └──────────┬─────────────┘   │
│                                       │                 │
│          ┌────────────────────────────┼──────────┐     │
│          ▼                            ▼          ▼     │
│   ┌─────────────┐             ┌──────────┐  ┌────────┐ │
│   │  Payload DB │             │ Medusa DB│  │ Stripe │ │
│   │  (Content)  │             │(Commerce)│  │  API   │ │
│   └──────┬──────┘             └─────┬────┘  └────────┘ │
│          │                          │                   │
│          └─────────────┬────────────┘                   │
│                        │                                │
│           ┌────────────▼────────────┐                  │
│           │   Next.js Storefront    │                  │
│           │ (SSG + ISR + Edge)      │                  │
│           └────────────┬────────────┘                  │
│                        │                                │
│                   ┌────▼────┐                          │
│                   │Kunde im │                          │
│                   │ Browser │                          │
│                   └─────────┘                          │
└─────────────────────────────────────────────────────────┘

Zielgruppe (im cBUZZ.IO-Kontext):

Das eCommerce-Paket (€69/M) bei cBUZZ.IO — das bisher "Odoo eCommerce oder Shopware 6" anbietet — bekommt mit inFactory@/Shop eine dritte, überlegene Option:

Multi-Channel-Händler mit Amazon/eBay-Anbindung
B2B-Großhändler mit individuellen Preislisten
Wachsende B2C-Shops ohne GMV-Gebühren

Kapitel 3.3 — inFactory@ /CRM

Zweck: Kundenbeziehungs-Management als Alternative zu HubSpot/Salesforce und als natürliche Integration mit /Shop.

Technik-Basis: Zwei realistische Wege:

Option A: Twenty CRM (2024 Open-Source-Launch, TypeScript/React/GraphQL, MIT)

Moderne Alternative zu Salesforce, native Next.js-Integration
Sehr junges Projekt (2024/25), aber rasches Wachstum
Passt stack-technisch perfekt

Option B: Payload-Collections als Custom-CRM

Payload bietet Multi-Tenant, Rollen, Workflows nativ
Für einfache Anforderungen (Kontakte, Deals, Tasks) ausreichend
Weniger Funktionsumfang als Twenty, aber volle Kontrolle

Funktions-Fork aus Worldsoft WBS:

FollowUp-Automation → Workflows in Trigger.dev oder n8n
E-Marketing-System → Integration mit Brevo/Mautic
Affiliate-Tracking → eigenes Modul auf Medusa-Basis

Empfehlung: Start mit Payload-basiertem Minimal-CRM (Phase 1), Migration zu Twenty wenn dort produktionsreif (Phase 2+).

Kapitel 3.4 — inFactory@ /ERP

Zweck: Enterprise Resource Planning — Finanzbuchhaltung, Controlling, Reporting.

Realitätscheck: Ein vollständiger ERP-Kern in JAMstack neu zu bauen ist ein 10-Jahre-Projekt. Odoo hat genau das über 15 Jahre entwickelt. Den Kampf gewinnen wir nicht frontal.

Pragmatische Lösung: Hybrid-Architektur

┌──────────────────────────────────────────────────┐
│  inFactory@ /ERP — Hybrid-Architektur            │
├──────────────────────────────────────────────────┤
│                                                  │
│   ┌────────────────────────┐                     │
│   │  inFactory@ Frontend   │ ← User-facing       │
│   │  (Next.js + Payload)   │                     │
│   └──────────┬─────────────┘                     │
│              │                                   │
│              ▼ REST / XML-RPC / GraphQL          │
│   ┌────────────────────────┐                     │
│   │  Odoo Community 18 LTS │ ← Business-Logik   │
│   │  (Backend-Service)     │   (nicht sichtbar)  │
│   └────────────────────────┘                     │
└──────────────────────────────────────────────────┘

Odoo bleibt unsichtbar im Backend und übernimmt komplexe Buchhaltung, Bilanzen, Steuererklärungen, DATEV-Export
inFactory@-Frontend liefert eine moderne UI, die AI-Agent-gestützt ist
Das ist kein Odoo-Fork — wir nutzen Odoo als API-Service

Was das für die vorherige Fork-Diskussion bedeutet: Die Frage "Odoo Community oder Flectra forken?" ist damit hinfällig. Wir forken keinen ERP-Kern. Wir konsumieren Odoos Kern als Service.

Kapitel 3.5 — inFactory@ /Lager

Zweck: Warenwirtschaft, Bestandsführung, Multi-Warehouse.

Technik-Basis: Medusa.js Inventory Module (bereits in /Shop vorhanden) + eigene Payload-Oberfläche für komplexere Szenarien.

Für Kunden mit einfachen Anforderungen (ein Lager, linear ablaufender Bestand): Medusa-Nativ. Für Kunden mit Multi-Warehouse, Chargenverwaltung, Seriennummern, Mindesthaltbarkeit: Odoo-Integration analog zu /ERP.

Kapitel 3.6 — inFactory@ /Rechnung

Zweck: Faktura, E-Rechnung (XRechnung, ZUGFeRD, E-Rechnung AT), DATEV-Export.

Technik-Basis:

Kernfunktion: Medusa.js generiert Rechnungen aus Bestellungen
E-Rechnung-Formate: Eigenes TypeScript-Modul (Libraries vorhanden: xrechnung, zugferd-node)
Steuerberechnung: Medusa Tax Module + DACH-spezifische Regeln (Reverse Charge, Kleinunternehmer, UID-Prüfung via VIES)
DATEV-Export: Eigenes Modul, generiert EXTF-Dateien

Funktions-Fork aus Odoo: Die DACH-Steuer-Logik aus l10n-at / l10n-de / l10n-ch wird als Konzept übernommen, neu in TypeScript geschrieben.

Kapitel 3.7 — inFactory@ /Produktion

Zweck: Manufacturing, Stücklisten, Produktionsplanung.

Realitätscheck: Produktionsplanung ist komplexer als ERP — das ist realistisch eine Domäne, die inFactory@ mittelfristig nicht selbst abdeckt.

Empfehlung:

Für einfache Fälle (Stückliste → Auftrag → Lager): Medusa + Custom-Module
Für komplexe Fälle (MRP, Kapazitätsplanung, Shopfloor): Odoo-Integration via API wie bei /ERP
Neukunden mit diesem Bedarf explizit auf die Hybrid-Lösung aufmerksam machen

Teil IV: Funktions-Forks — Lernen statt Kopieren

4.1 "Conceptual Forking" als Methode

Wir übernehmen Konzepte, Datenmodelle und Business-Logik-Muster, aber keinen Code. Das ist legal, technisch sauber, und spart uns Jahrzehnte an Domänen-Know-how. Die drei Upstream-Quellen liegen als git clone im ~/dev/upstream/-Verzeichnis (analog zur XED-Projektstruktur), werden regelmäßig gerebased, dienen aber ausschließlich als Referenz.

4.2 Was wir aus Shopware 6 lernen

Shopping-Experiences-Hierarchie (Sections → Blocks → Elements): reifste Block-Struktur im eCommerce, 1:1 in Puck abbildbar
Rule Builder: visuelles Bedingungs-System für Sichtbarkeit, Preise, Versand
Flow Builder: Workflow-Automation mit Triggern und Aktionen
Plugin-Manifest-Struktur: Wie isoliert man Kundenanpassungen vom Core?
B2B-Customer-Groups: UI-Muster für Kundengruppen und Preislisten

4.3 Was wir aus Odoo lernen

DACH-Accounting-Datenmodell: UVA, UStVA, SAF-T, steuerliche Fristen
res.partner-Struktur: universelle Kontakt-Entity für Kunden/Lieferanten/Mitarbeiter
Inventory-Domain-Logic: Bestandsreservierung, Lieferpräferenzen, Mehrlager
Double-Entry-Accounting: Korrekte Umsetzung doppelter Buchführung
Chart-of-Accounts-Templates: Deutsche/Österreichische/Schweizer Kontenrahmen

4.4 Was wir aus Worldsoft lernen (Funktions-Ebene)

FollowUp-Sequences: "Formular → E-Mail 1 → 3 Tage warten → E-Mail 2 → Bedingung prüfen"
Affiliate-Tracking-Patterns: Cookie-Lifetime, Referrer-Handling, Provisionsberechnung
Integrierte Dashboard-Philosophie: Ein Login für alles (als UX-Prinzip, nicht als Architektur)

Teil V: Vertriebs-Fork — Das Partner-Programm neu gedacht

Was bei Worldsoft funktioniert hat — und was wir erben, aber sauber aufbereiten.

5.1 Das Worldsoft-Modell im Detail

Worldsoft Partner-Pfad:

1. Info-Seminar (kostenlos, aber Verkaufs-Pitch)
   ↓
2. Internet-Success-Coach-Ausbildung (kostenpflichtig, mehrtägig)
   ↓
3. Zertifizierung (gegen Gebühr)
   ↓
4. Franchise-Partner-Status
   ↓
5. 20% Lifetime-Provision auf Hosting

Was daran funktioniert hat: Lifetime-Provision, kein MLM mit Downline, ehrliches Wiederkehrmodell.

Was problematisch ist: Die Stufen 1–3 sind ein Revenue-Pfad für Worldsoft selbst. Partner zahlen, um Partner werden zu dürfen. Das ist kein direktes MLM, aber fühlt sich so an.

5.2 Das inFactory@-/cBUZZ.IO-Modell

cBUZZ.IO Partner-Pfad:

1. Anmeldung auf cbuzz.io (kostenlos, unverbindlich)
   ↓
2. Wahl des Modells:
   ├─ Reseller (40% Rabatt, White-Label)
   └─ Affiliate (30% Provision, persönlicher Link)
   ↓
3. Loslegen — keine Pflichtseminare, keine Zertifizierung, keine Gebühren

Eckdaten:

Modell	Rabatt/Provision	Typische monatliche Einkünfte pro Kunde
Reseller	40% Rabatt auf Listenpreis	€1,96 (Connect) bis €27,60 (eCommerce)
Affiliate	30% Lifetime-Provision	€1,47 (Connect) bis €20,70 (eCommerce)

Unterschiede zu Worldsoft im Detail:

❌ Keine Seminar-Pflicht — Dokumentation ist öffentlich, YouTube-Tutorials frei
❌ Keine Zertifizierungs-Gebühren — wer verkaufen will, verkauft
❌ Kein "Internet Success Coach"-Branding — Partner sind Partner, nicht Coach-Franchisees
❌ Keine Mindestumsätze — wie bei Worldsoft, aber expliziter kommuniziert
✅ Transparente Provisions-Tabellen auf der öffentlichen Website
✅ Sofortiger White-Label-Zugang (Reseller) ohne Wartezeit
✅ Echte Datenportabilität — wenn ein Kunde migrieren will, kriegt er seine Daten mit

Teil VI: Roadmap

6.1 Phase 0 — Foundation (Q2 2026)

Ziel: Lauffähige Basis-Infrastruktur, Development-Umgebung, CI/CD.

Aufgaben:

[ ] Repo-Struktur ~/dev/infactory/ analog zu ~/dev/xed/
[ ] Upstream-Klone in ~/dev/infactory/upstream/: Odoo 18, Shopware 6 Community, Flectra, Medusa, Payload, Puck
[ ] Docker-Compose-Setup: Payload + Medusa + PostgreSQL + Redis
[ ] Next.js-Starter-Projekt als Template
[ ] Claude-Code-Auftragssystem analog zu XED (postbox/-Verzeichnis)
[ ] AGENTS.md und DEVELOPMENT.md für AI-Agent-Anbindung

Liefergegenstand: git clone infactory-starter && pnpm install && pnpm dev läuft in unter 10 Minuten.

6.2 Phase 1 — /Studio Launch (Q3 2026)

Ziel: Payload + Puck + Next.js als produktive Basis für cBUZZ.IO Connect/Combo-Pakete.

Aufgaben:

[ ] Payload-Plugin für Puck integrieren (@delmaredigital/payload-puck oder Eigenbau)
[ ] Block-Library DACH-konform: Hero, Call-to-Action, Testimonials, Feature-Grid, FAQ, Kontaktformular, etc.
[ ] Themes: 3 Starter-Designs (Minimal, Business, Portfolio)
[ ] DSGVO-konforme Cookie-/Tracking-Vorlage
[ ] White-Label-Unterstützung für Reseller
[ ] Ghost-Import-Migrator (falls Bestandskunden migrieren)

Liefergegenstand: Ein Connect-Kunde kann seine Website in unter einer Stunde aufsetzen.

6.3 Phase 2 — /Shop MVP (Q4 2026)

Ziel: Medusa + Payload + Puck als Shopware-Alternative im cBUZZ.IO eCommerce-Paket.

Aufgaben:

[ ] Medusa-Installation mit DACH-Lokalisierung (USt, UID, Rechtstexte)
[ ] Puck-Integration für Produktseiten und Kategorie-Layouts
[ ] Payment-Provider: Stripe, PayPal, Klarna (Mollie optional)
[ ] Versandintegrationen: DHL, Post.at, Swiss Post
[ ] Steuer-Module: AT-USt, DE-USt, CH-MwSt, Reverse Charge B2B
[ ] UID-Validierung via VIES (aus dem who@-/edikte@-Ökosystem)
[ ] E-Rechnung: XRechnung, ZUGFeRD, E-Rechnung AT
[ ] DATEV-Export (EXTF-Format)
[ ] B2B-Customer-Groups + Preislisten

Liefergegenstand: Ein €69/M-eCommerce-Kunde kann zwischen Odoo, Shopware, inFactory@ /Shop wählen — inFactory@ /Shop ist die strategisch bevorzugte Option.

6.4 Phase 3 — Ecosystem-Expansion (2027)

Iterative Entwicklung der weiteren Module, abhängig von Kundennachfrage:

Q1 2027: /CRM (Payload-basiert, minimal) + Odoo-Integration für komplexes ERP
Q2 2027: /Rechnung (eigenständiges Modul, E-Rechnung-Fokus)
Q3 2027: /Lager (Medusa-Inventory-Erweiterung + Multi-Warehouse)
Q4 2027: /Produktion (MVP oder explizite Odoo-Delegation — Entscheidung nach Kundenfeedback)

6.5 Meilensteine für cBUZZ.IO

Quartal	MRR-Ziel	Kunden (kumulativ)	Produkt-Status
Q2 2026	—	—	Phase 0 Foundation
Q3 2026	€500	50	/Studio live (Connect/Combo)
Q4 2026	€1.500	120	/Shop MVP live (eCommerce)
Q1 2027	€2.500	170	/CRM Alpha
Q2 2027	€3.400	200	/Rechnung live
Q4 2027	€4.400	220	Vollständiges /Headless-Ökosystem

Ziel €4.400/M MRR Ende 2027 entspricht dem bestehenden who@-/edikte@-Whitepaper-Plan und bleibt konsistent.

Teil VII: Positionierung gegen Worldsoft (und gegen proprietäre Konkurrenz allgemein)

Drei Alleinstellungsmerkmale, die direkt kommunizierbar sind:

7.1 Open Source DNA

Jede einzelne Komponente ist MIT oder LGPL v3 lizenziert
Quellcode auf GitHub öffentlich einsehbar
Kunden können jederzeit selbst hosten
Kein Mysterium, keine Black Box

7.2 Keine MLM-Rhetorik

Keine "Lizenz zum Geldverdienen"-Sprache
Keine Seminar-Pyramide mit Zertifizierungs-Kaskade
Keine übertriebenen Erfolgsversprechen in Referenzen
Ehrliche Provisionstabellen, ehrliche Durchschnittswerte

7.3 Datenhoheit & EU-Hosting

Server in EU (AT/DE/CY)
100% Ökostrom
DSGVO-konform by default
Datenexport jederzeit möglich (PostgreSQL-Dump, CSV, JSON)
Kein US-Cloud-Act-Risiko

7.4 Die direkte Gegenüberstellung für die Website

	Worldsoft	inFactory@ /Headless
Lizenz	Proprietär	MIT / LGPL v3
Datenexport	Nicht dokumentiert	Jederzeit (PostgreSQL, JSON, CSV)
Hosting	Schweiz	EU (AT/DE/CY), 100% Ökostrom
Partner-Modell	Franchise mit Ausbildungspflicht	Reseller / Affiliate ohne Verpflichtung
Partner-Einstieg	Kostenpflichtige Seminare	Kostenlos, sofort startklar
Provision	20% Lifetime (Hosting)	30% Affiliate / 40% Reseller (Lifetime)
Tech-Stack	PHP-Monolith (proprietär)	TypeScript/JAMstack (Open Source)
AI-Agent-Integration	Keine	Nativ
Mobile	Responsive	PWA-ready
Performance	Origin-gerendert	CDN-geliefert, sub-100ms
Community	Geschlossen	GitHub, Discord, öffentliche Docs

Teil VIII: Anhang

A. Tech-Stack-Referenz (konsolidiert)

Core-Stack (durchgängig in allen Modulen):

Node.js 22 LTS
TypeScript 5+
React 19
Next.js 15
PostgreSQL 16
Tailwind CSS 4

CMS & Content:

Payload CMS v3+
Puck Editor (@puckeditor/core >= 0.21)

Commerce:

Medusa.js v2+
Stripe / PayPal / Mollie (Payment-Provider)

Integration-Targets (KEIN Fork, nur API-Konsument):

Odoo Community 18 LTS (als Backend-Service für komplexe ERP-Fälle)
edikte@ API (Firmenbuch-Autocomplete)
who@ API (B2B-Kontext)
Delta Chat Bot API (2FA, Admin-Workflows)
Ghost (falls dedizierter Publishing-Workflow)

Upstream-Quellen (nur zum Lernen, ~/dev/infactory/upstream/):

Odoo 18 Community
Shopware 6 Community
Flectra (Referenz für "was nicht zu tun ist")

B. Lizenzen im Überblick

Komponente	Lizenz	Kommerziell verwendbar	Modifikationen publizieren?
Next.js	MIT	✅	❌
React	MIT	✅	❌
Payload CMS	MIT	✅	❌
Puck Editor	MIT	✅	❌
Medusa.js	MIT	✅	❌
PostgreSQL	PostgreSQL License	✅	❌
Odoo (falls API-Nutzung)	LGPL v3	✅	Bei Modifikation des Kerns ja

Konsequenz: inFactory@-Eigenentwicklungen können frei gewählte Lizenz haben (MIT empfohlen für Community, proprietär für kommerzielle Add-ons möglich).

C. Glossar

JAMstack — Architekturprinzip: JavaScript, APIs, Markup. Statisch generierte Frontends, die über APIs dynamische Daten abrufen.
Headless — Frontend und Backend sind getrennt. Das Backend liefert nur Daten via API, das Frontend rendert unabhängig.
Composable Commerce — Commerce-Architektur, bei der einzelne Services (Cart, Payment, Catalog) unabhängig austauschbar sind.
Visual Editor — Editor, in dem Content-Redakteure Seiten per Drag & Drop zusammenstellen, ohne Code zu schreiben.
Funktions-Fork — Übernahme von Konzepten und Datenmodellen, nicht von Code. Legal, technisch sauber, lizenzrechtlich unbedenklich.

D. Historie dieses Dokuments

Version	Datum	Änderungen
1.0	April 2026	Erstausgabe. Ersetzt `STRATEGY-Odoo-vs-Flectra-vs-EigenFork.md` (nach `ARCHIVE/` verschoben)

Vorgängerdokumente in ARCHIVE/:

STRATEGY-Odoo-vs-Flectra-vs-EigenFork.md — weiterhin wertvoll für Flectra-Copyright-Analyse und Odoo-Community-vs-Enterprise-Diskussion. Die Fork-Empfehlung selbst ist durch den JAMstack-Paradigmenwechsel obsolet.

Schlusswort

Worldsoft hat eine wichtige Frage vor 20 Jahren richtig beantwortet: "Wie bekommt ein DACH-Kleinunternehmer eine integrierte Online-Präsenz, ohne Programmierer zu sein?"

Die Antwort damals war ein proprietärer Monolith. Die Antwort 2026 ist ein composable JAMstack-Ökosystem, das dieselbe Frage radikaler beantwortet — mit Open Source, Datenhoheit, AI-Agent-Nativität und ohne Franchise-Rhetorik.

inFactory@ ist nicht "der nächste Shopware-Klon mit KI". Es ist die ehrliche Antwort auf die Frage, die Worldsoft aufgeworfen hat, mit den Werkzeugen, die 2026 tatsächlich zur Verfügung stehen.

Kaizen. Jeden Tag 1% besser.

Ende Whitepaper v1.0 — April 2026