e

elwoms Architektur

Stand: 2026-05-16

Wie alles zusammenhängt

elwoms ist kein einzelnes Tool, sondern eine Familie von Apps mit unterschiedlichen Zielgruppen. Diese Seite zeigt wer was kann und wer wovon abhängt — bevor wir strukturelle Entscheidungen treffen.

📖 Vision-Dokument (Was wir entschieden haben) 📊 Architektur-Übersicht (Markdown) 📋 Pro-Projekt Quick-Reference

Visuelle Prototypen

Klickbare Mockups mit denselben Beispiel-Daten zum Vergleichen

A
Modell A — Notion-Style
Alles in einer App

Eine Sidebar links, alle Module darin. Kunde X = eine Detail-Seite mit Tabs für WhatsApp, Tasks, Termine, Angebote.

→ Prototyp öffnen
D
Modell D — Variante 1
Microsoft-365-Look · dunkle Top-Bar, App-Farben

App-Launcher mit farbcodierten Apps (CRM blau, Tasks lila, WhatsApp grün etc.). Cross-Links zwischen Apps.

→ Prototyp öffnen
D2
Modell D — Variante 2 (elwoms Design-System) ⭐
Gleiche Architektur · warmes Monochrom aus tasks.elwoms.app

Selbe Architektur wie Variante 1, aber im elwoms-tasks Design-System — warmes Creme-Monochrom, schwarzer CTA, Status-Farben nur wo sie Bedeutung tragen. Konsistent mit deinem bestehenden Look.

→ Prototyp öffnen
7
elwoms-Projekte aktiv
3
Customer-Facing Produkte
4
Stark gekoppelt an elwoms
9
Offene Fragen

Projekt-Klassifizierung

Drei Klassen — drei verschiedene Strategien

🧑‍💼 Internes Tooling

User: Florian

  • ▸elwoms — Workspace + CRM
  • ▸whatsappbot — Inbox + Bot
  • ▸tasks — ToDo-App
  • ▸agent — Cron-Runner

→ Kandidaten für Modular-Monolith

🛍 Customer-Facing

User: andere Kunden

  • ▸tools — Live-Sessions (Mentimeter)
  • ▸shop — Shirtigo E-Commerce
  • ▸links — Linktree-Clone

→ Eigene Produkte, nicht konsolidieren

🎓 Innoakademie

User: Akademie-Mitglieder

  • ▸innoakademie — Marketing
  • ▸innoakademie-campus — Community
  • ▸toolfinder — LLM-Tool

→ Enger anbinden via SSO/API

Abhängigkeits-Diagramm

Wer hängt an wem — und wie eng

graph TB subgraph Infra["🌐 Shared Infrastructure"] Mail["mg.elwoms.app
Mailgun-Domain"] Storage["elwoms-storage
Hetzner Bucket"] end subgraph Internal["🧑‍💼 Internes Tooling"] ELWOMS["elwoms
Workspace + CRM
Postgres"] WA["whatsappbot
Meta API + Inbox
eigene Postgres"] Tasks["tasks
ToDo-App
eigene Postgres"] Agent["agent
Cron-Jobs
keine DB"] end subgraph Inno["🎓 Innoakademie"] InnoMarket["innoakademie
Marketing
Static"] InnoCampus["innoakademie-campus
Community
eigene Postgres"] end subgraph Customer["🛍 Customer-Facing"] Shop["shop
E-Commerce"] Tools["tools
Live-Sessions"] Links["links
Linktree"] end subgraph Public["🌐 Public Sites"] FP["florianpeschel
Portfolio + Booking"] NP["ninapeschel
Portfolio"] end WA -.elwomsOfferId.-> ELWOMS InnoCampus ==>|API + contactId| ELWOMS FP ==>|Booking-API + Webhook| ELWOMS Shop -.userId.-> ELWOMS Links -.userId.-> ELWOMS Tasks -.userId.-> ELWOMS ELWOMS --> Mail ELWOMS --> Storage InnoCampus --> Mail InnoCampus --> Storage InnoMarket --> Storage InnoMarket --> Mail FP --> Mail NP --> Mail Agent --> Mail classDef tight fill:#fef3c7,stroke:#d97706,stroke-width:3px classDef loose fill:#fff,stroke:#cbd5e1,stroke-dasharray:5 5 class WA,InnoCampus,FP tight
Enge Kopplung (API + Daten)
Lose Kopplung (User-ID-Anker)
Stark abhängig (kann nicht ohne elwoms)

Alle Projekte im Detail

Klick auf eine Karte für Details

Beispiel-Datenflüsse

📥 Lead → Kunde

  1. 1
    Meta-Ad geklickt, Lead-Form ausgefüllt
  2. 2
    whatsappbot empfängt Webhook, speichert LeadFormSubmission
  3. 3
    Bot sendet Begrüßungs-Template via Meta API
  4. 4
    Florian qualifiziert telefonisch / via Teams
  5. 5
    Florian erstellt Angebot in elwoms
  6. 6
    elwomsOfferId wird zurück nach whatsappbot synced
  7. 7
    Kunde bestätigt → elwoms erstellt Booking
  8. 8
    florianpeschel.de zeigt Termin-Bestätigung

🎓 Akademie-Registrierung

  1. 1
    User registriert sich auf innoakademie-campus
  2. 2
    Campus ruft elwoms-API: existiert die E-Mail?
  3. 3
    elwoms antwortet mit contactId
  4. 4
    Campus erstellt User in eigener DB mit contactId
  5. 5
    Activation-Mail über mg.elwoms.app
  6. 6
    User aktiviert → kann Kurse buchen

Offene Fragen

Diese müssen beantwortet werden bevor Konsolidierung Sinn macht

Geschäftlich
  • 1. Tasks-Doppelung: elwoms hat schon Tasks als Item-Type, daneben gibt's elwoms-tasks. Welches nutzt du wirklich täglich?
  • 2. WhatsApp-CRM-Sync ist aktuell halbmanuell. Soll's eine echte Bidirektional-API werden?
  • 3. Agent-Verantwortung: nur Ditix + Outlook. Welche weiteren Triggers sollen rein?
Architektonisch
  • 4. Auth-Strategie: aktuell hat jedes Projekt eigene Auth. Brauchst du Single-Sign-On?
  • 5. DB-Strategie: separate Postgres pro Projekt. Sollen elwoms + whatsapp + tasks in EINE DB?
  • 6. Innoakademie-Trennung: Campus hängt stark. Auth/Contact-Verwaltung enger verzahnen?
Strategisch
  • 7. Sales-Story: Verkaufst du Shop/Tools/Links an Kunden? Oder sind es Marketing-Tools für dich?
  • 8. Skalierung: welche Tools werden bei Wachstum am wichtigsten?
  • 9. Zeit-Budget: wieviel kannst du in eine Migration investieren (Wochen, nicht Monate)?
Vorläufige Empfehlung
  • ✅ whatsappbot in elwoms als Modul
  • ✅ agent als Cron-Modul in elwoms
  • ⚠️ tasks: eines von beiden killen
  • ❌ Shop / Tools / Links bleiben eigenständig (eigene User-Basen)
  • ⚠️ Innoakademie: bleibt separat, aber SSO + API verbessern