Initial brief, brand system, product description
This commit is contained in:
Pascal Oelmann
commit
c226562a44
5 changed files with 1605 additions and 0 deletions
BIN
.DS_Store
vendored
Normal file
BIN
.DS_Store
vendored
Normal file
Binary file not shown.
824
CLAUDE.md
Normal file
824
CLAUDE.md
Normal file
|
|
@ -0,0 +1,824 @@
|
|||
# SlimCore Marketing Site — Implementation Brief
|
||||
|
||||
> **Stand:** 2026-05-04 · **Autor:** Pascal Oelmann (mit Claude Chat) · **Adressat:** Claude Code
|
||||
> **Aufgabe:** Implementierung der Marketing-/Landing-Webseite für SlimCore unter `slimcore.io`.
|
||||
> Diese Datei ist die Steuerungsquelle für alle Entscheidungen. Bei Konflikten gewinnt diese Datei gegenüber Default-Annahmen oder Lovable-Vorlagen.
|
||||
|
||||
---
|
||||
|
||||
## 0. TL;DR für Claude Code
|
||||
|
||||
- **Stack:** Astro 5 (Static Site, SEO-first) + Tailwind v4 + selektive React-Islands für interaktive Komponenten + shadcn/ui-Primitives + TypeScript strict.
|
||||
- **Domain:** `slimcore.io` = Marketing. `app.slimcore.io` = SaaS-App (separates Repo, nicht Teil dieses Briefs).
|
||||
- **Positionierung:** Primärgruppe sind Solo-Selbstständige und kleine Teams (1–10). Sekundär wachsende KMU bis ~30. Tertiär eCommerce-Händler. Hero-Linie: **„Schlank starten. Grenzenlos wachsen."**
|
||||
- **Familienzugehörigkeit:** SlimCore ist eine eigenständige Produktmarke unter dem digiFORMER-Dach (Adobe-Modell, nicht Atlassian-Modell). Familien-Anker sind Typografie + nummerierte Sektionen + Status-Glyphen — NICHT die Farbe. Jede Marke hat genau eine eigene Akzentfarbe.
|
||||
- **Akzentfarbe SlimCore:** Electric Persimmon `#FF6B2C` (`oklch(0.71 0.22 38)`). Definiert im familienweiten Markensystem (siehe `digiformer-brand-system.md`). Text-on-Accent ist `#2A0F02` (dunkles Persimmon-Schwarz), nicht Weiß — Kontrast-Grund.
|
||||
- **Nicht verhandelbar:** Eine Akzentfarbe (kein Theme-Switcher). Umlaute. Sentence case. Keine US-Marketing-Klischees. Vision-Features als Vision benennen, nicht als verfügbar verkaufen.
|
||||
- **Inhaltlicher Master:** `produktbeschreibung.pdf` (im Repo unter `/docs/produktbeschreibung.pdf`). Diese CLAUDE.md übersetzt das in Code-Anweisungen — nicht alle Inhalte werden hier wiederholt.
|
||||
- **Markensystem-Master:** `digiformer-brand-system.md` regelt Farben, Typografie, Status-Glyphen und Markenarchitektur. **§7 ist die verbindliche Vendor- und Stack-Politik** (DE/CH/AT/EU-Headquarter + EU-Rechenzentren, Whitelist/Greylist/Blacklist). Bei Konflikten zwischen CLAUDE.md und Brand-System gewinnt das Brand-System. Bei Default-Empfehlungen wie „nimm Vercel" oder „nimm Stripe" prüft Claude Code immer zuerst Brand-System §7.4 — diese Vendors sind ausgeschlossen.
|
||||
|
||||
---
|
||||
|
||||
## 1. Mission
|
||||
|
||||
SlimCore ist die schlanke, modulare Geschäftssoftware für Solo-Selbstständige und kleine Teams — souverän in Europa gehostet, ohne Abhängigkeit von US-Konzernen, ohne Vendor-Lock-in. Die Marketing-Site muss drei Aufgaben erfüllen:
|
||||
|
||||
1. **Tester gewinnen.** Primärer Conversion-Funnel ist die Tester-Anmeldung. Phase 1 läuft jetzt.
|
||||
2. **Glaubwürdigkeit aufbauen.** Souveränitäts-Versprechen ist Differenzierung — muss visuell und sprachlich substantiell wirken, nicht wie Marketing-Geschwurbel.
|
||||
3. **Produkt verständlich machen.** 16 Module in 4 Säulen, mit klaren Status-Markierungen. Solo-Selbstständige und kleine Teams sollen in unter 30 Sekunden erkennen, ob SlimCore zu ihrer Situation passt — und ob es mit ihnen wachsen kann.
|
||||
|
||||
**Zentrales Versprechen:** „Schlank starten. Grenzenlos wachsen." — der Wachstums-Aspekt ist neuer Kern-USP gegenüber bisheriger Positionierung.
|
||||
|
||||
**Sekundär:** SEO-Sichtbarkeit für Suchanfragen wie „CRM für Solo-Selbstständige", „Geschäftssoftware Solo", „ERP Alternative DSGVO", „Odoo zu komplex", „CRM Made in Germany", „SaaS Hetzner Hosting".
|
||||
|
||||
---
|
||||
|
||||
## 2. Architektur-Entscheidung
|
||||
|
||||
### 2.1 Warum Astro statt Next.js / Vite-SPA
|
||||
|
||||
Die SlimCore-Web-App selbst läuft auf Vite + React + TanStack. Für die **Marketing-Site** sind die Anforderungen aber andere:
|
||||
|
||||
| Anforderung | Gewinner |
|
||||
|---|---|
|
||||
| SEO (statisches HTML, schnelles First Paint) | Astro (SSG by default) |
|
||||
| Geringe Bundle-Größe für Marketing | Astro (ships zero JS by default) |
|
||||
| MDX für späteren Blog/Notizen | Astro (eingebaut) |
|
||||
| React-Komponenten wo nötig (Forms, Roadmap-Toggle) | Astro Islands (`client:load`, `client:visible`) |
|
||||
| Tailwind v4 Kompatibilität | Astro (offizieller Adapter) |
|
||||
| Tooling-Vertrautheit | beide ok |
|
||||
|
||||
Astro ist die richtige Wahl, weil 90 % der Site statisch ausgeliefert werden können. Interaktive Inseln (Tester-Formular, Roadmap-Filter, Modul-Tabelle mit Filter) werden als React-Islands punktuell hydriert.
|
||||
|
||||
### 2.2 Domains
|
||||
|
||||
- `slimcore.io` — Marketing-Site (dieses Repo)
|
||||
- `app.slimcore.io` — SaaS-App (anderes Repo, existiert)
|
||||
- `slimcore.io/login` → 301 Redirect auf `app.slimcore.io/login`
|
||||
- `slimcore.io/app` → 301 Redirect auf `app.slimcore.io`
|
||||
|
||||
### 2.3 Hosting
|
||||
|
||||
Statisches Build-Output wird auf einem **Hetzner-VPS** ausgeliefert, mit **Coolify** als Deployment-Layer. Build- und Deploy-Pipeline läuft über Forgejo Actions (oder GitHub Actions als Übergangs-Realität, siehe Brand-System §7.5).
|
||||
|
||||
Vercel, Netlify, Cloudflare Pages und alle anderen US-gehosteten Static-Site-Plattformen sind **nicht zulässig** — siehe Brand-System §7.4. Die Marketing-Site einer Marke, deren Kernversprechen Souveränität ist, kann nicht auf US-Infrastruktur stehen, ohne sich beim ersten DNS-Lookup einer technisch versierten Tester-Person selbst zu widerlegen.
|
||||
|
||||
Alternativ-Host: **OVHcloud** (FR) als zweite Option, falls Hetzner-Kapazitäten ausgeschöpft oder Pascal aus anderen Gründen wechseln möchte.
|
||||
|
||||
**Default-Annahme für SlimCore-Marketing:** Hetzner-VPS in Falkenstein (Konsistenz mit der App-Hosting-Region), Coolify als Deployment-Orchestrator, Caddy oder nginx als Reverse-Proxy mit Auto-TLS via Let's Encrypt. Statisches Astro-Build-Output direkt aus dem Build-Container deployt.
|
||||
|
||||
### 2.4 Form-Handling
|
||||
|
||||
Tester-Anmeldungen gehen **direkt an die SlimCore-App-API**, nicht an einen externen Form-Service:
|
||||
|
||||
- **Primär (festgelegt):** POST an `https://app.slimcore.io/api/public/leads` (siehe `slimcore-go-to-market.md` §3 für die Spezifikation). Lead landet sofort im digiFORMER-Mandanten als CRM-Eintrag, dem Operator-Tenant für SlimCore.
|
||||
- **Brevo** wird nur als Transactional-Mail-Provider für die Double-Opt-In-Bestätigung verwendet — nicht als Lead-Speicher. Brevo bekommt keine Lead-Daten zur Verwaltung; die SlimCore-App rendert die DOI-Mail und versendet sie über Brevo SMTP.
|
||||
- **Kein Supabase**, kein Formspree, kein HubSpot, kein Typeform — Souveränitäts-Konsistenz mit dem Rest des Stacks.
|
||||
|
||||
Bot-Schutz: **Altcha** (Open Source, self-hosted Proof-of-Work-Challenge, keine Drittpartei). Plus Honeypot-Feld. Cloudflare Turnstile, reCAPTCHA und hCaptcha sind ausgeschlossen — siehe Brand-System §7.4.
|
||||
|
||||
---
|
||||
|
||||
## 3. Repo-Struktur
|
||||
|
||||
```
|
||||
slimcore-marketing/
|
||||
├── CLAUDE.md ← diese Datei (Implementierungs-Brief)
|
||||
├── README.md
|
||||
├── docs/
|
||||
│ ├── digiformer-brand-system.md ← Marken-System (Mirror — Master später als npm-Paket)
|
||||
│ ├── produktbeschreibung.md ← Inhalt-Master in Markdown (für Re-Builds)
|
||||
│ ├── produktbeschreibung.pdf ← Inhalt-Master als PDF (für Lesefluss)
|
||||
│ └── design-tokens-rationale.md ← optionale Notizen zu Designentscheidungen
|
||||
├── astro.config.mjs
|
||||
├── tailwind.config.ts ← falls Tailwind-Config-Datei nötig (v4 nutzt @theme, Datei evtl. minimal)
|
||||
├── tsconfig.json
|
||||
├── package.json
|
||||
├── public/
|
||||
│ ├── favicon.svg
|
||||
│ ├── og-default.png ← 1200×630 OG-Bild, generiert
|
||||
│ └── fonts/ ← self-hosted (DSGVO!)
|
||||
│ ├── source-serif-4-variable.woff2
|
||||
│ ├── inter-variable.woff2
|
||||
│ └── jetbrains-mono-variable.woff2
|
||||
├── src/
|
||||
│ ├── styles/
|
||||
│ │ └── global.css ← Tailwind v4 @theme + Reset
|
||||
│ ├── content/
|
||||
│ │ ├── module.ts ← Modul-Liste als typed data
|
||||
│ │ └── notizen/ ← MDX für späteren Blog
|
||||
│ ├── components/
|
||||
│ │ ├── primitives/ ← shadcn/ui (Button, Input, Dialog)
|
||||
│ │ ├── marketing/
|
||||
│ │ │ ├── NavBar.astro
|
||||
│ │ │ ├── Footer.astro
|
||||
│ │ │ ├── Eyebrow.astro
|
||||
│ │ │ ├── SectionHeading.astro
|
||||
│ │ │ ├── NumberedItem.astro
|
||||
│ │ │ ├── ModuleCard.astro
|
||||
│ │ │ ├── ModuleGrid.astro
|
||||
│ │ │ ├── StatusDot.astro
|
||||
│ │ │ ├── TechStrip.astro
|
||||
│ │ │ ├── SovereigntyBlock.astro
|
||||
│ │ │ ├── RoadmapTimeline.astro
|
||||
│ │ │ ├── ObjectionAnswer.astro
|
||||
│ │ │ └── CTABlock.astro
|
||||
│ │ └── islands/ ← React, hydriert
|
||||
│ │ ├── TesterForm.tsx
|
||||
│ │ ├── ModuleFilter.tsx ← optional
|
||||
│ │ └── ContactForm.tsx
|
||||
│ ├── layouts/
|
||||
│ │ └── BaseLayout.astro ← <head>, NavBar, Footer
|
||||
│ └── pages/
|
||||
│ ├── index.astro ← Home
|
||||
│ ├── module.astro
|
||||
│ ├── souveraenitaet.astro
|
||||
│ ├── tester.astro
|
||||
│ ├── roadmap.astro
|
||||
│ ├── kontakt.astro
|
||||
│ ├── impressum.astro
|
||||
│ ├── datenschutz.astro
|
||||
│ └── danke.astro ← Tester-Formular Submit-Ziel
|
||||
└── e2e/
|
||||
└── nav.spec.ts ← Playwright smoke tests
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Tech-Stack-Details
|
||||
|
||||
### 4.1 Astro
|
||||
|
||||
- Astro 5.x, Output-Mode `static`.
|
||||
- `@astrojs/react` für React-Islands.
|
||||
- `@astrojs/sitemap` für `sitemap-index.xml`.
|
||||
- `@astrojs/mdx` für `/content/notizen` (Phase 2).
|
||||
|
||||
### 4.2 Tailwind v4
|
||||
|
||||
Pascal nutzt Tailwind v4 in der App. Hier auch. Das bedeutet:
|
||||
|
||||
- Konfiguration über `@theme` in `global.css`, nicht via `tailwind.config.ts` (falls möglich; minimaler Config nur wenn Plugins gebraucht werden).
|
||||
- Custom-Properties als Single Source of Truth — diese werden später vom App-Repo geteilt (Phase 2: design-tokens als monorepo package).
|
||||
|
||||
### 4.3 React-Islands
|
||||
|
||||
Nur dort React laden, wo Interaktivität nötig ist:
|
||||
|
||||
- `TesterForm` — `client:load` (oberhalb der Falte)
|
||||
- `ContactForm` — `client:visible`
|
||||
- `ModuleFilter` — `client:visible`, optional
|
||||
|
||||
Die Roadmap-Timeline ist statisches Astro-Markup, keine Hydration nötig.
|
||||
|
||||
### 4.4 shadcn/ui
|
||||
|
||||
shadcn/ui ist komponentenweise — wir installieren NUR was wir brauchen:
|
||||
|
||||
- `button`
|
||||
- `input`
|
||||
- `textarea`
|
||||
- `label`
|
||||
- `dialog` (für Tester-Modal von der NavBar aus)
|
||||
|
||||
Kein Card-Component, kein Accordion, kein Carousel. Marketing-Cards bauen wir selbst minimal mit Tailwind.
|
||||
|
||||
### 4.5 TypeScript
|
||||
|
||||
`strict: true`, `noUncheckedIndexedAccess: true`. Module-Daten in `src/content/module.ts` als `as const`-Tupel mit explizitem Type-Export.
|
||||
|
||||
### 4.6 Schriftarten — self-hosted (DSGVO!)
|
||||
|
||||
Keine Google Fonts CDN. Alle Fonts liegen in `public/fonts/` und werden über `@font-face` mit `font-display: swap` geladen.
|
||||
|
||||
- **Serif:** Source Serif 4 Variable (SIL OFL, kostenlos)
|
||||
- **Sans:** Inter Variable (SIL OFL, kostenlos)
|
||||
- **Mono:** JetBrains Mono Variable (SIL OFL, kostenlos)
|
||||
|
||||
Alternativen falls Pascal anderen Charakter wünscht: Newsreader (Serif, leicht editorial-warm), Geist Sans/Mono (modern-technisch), GT Sectra (Paid, premium).
|
||||
|
||||
---
|
||||
|
||||
## 5. Design System
|
||||
|
||||
### 5.1 Markenhaltung — Familienzugehörigkeit zu digiFORMER
|
||||
|
||||
`digiformer.eu` ist Beratungsmarke, ruhig-editorial. SlimCore ist Produktmarke — gleiche Haltung, mehr „Werkzeugkasten-Anmutung":
|
||||
|
||||
| Aspekt | digiFORMER | SlimCore | Gemeinsam |
|
||||
|---|---|---|---|
|
||||
| Tonalität | „Erst verstehen. Dann umsetzen." | „Schlank. Souverän." | Knapp, sachlich, kein Hype |
|
||||
| Hauptvisual | Lange Editorial-Fließtexte | Modul-Raster (4×16) | Nummerierte Sektionen 01–04 |
|
||||
| Akzentfarbe | dezent | EINE definierte | Beide nutzen genau eine |
|
||||
| Mono-Font-Einsatz | wenig | viel (Stack, Status, Eyebrows) | Mono ist Familien-Marker |
|
||||
| Sprache | Deutsch primär | Deutsch primär, EN Phase 2 | DE-first |
|
||||
|
||||
### 5.2 Farben
|
||||
|
||||
> **Quelle der Wahrheit:** Alle Marken-Farbtoken stehen in `digiformer-brand-system.md`. Diese Sektion zeigt nur die SlimCore-relevanten Werte als Code-Snippet. Bei Konflikt: Brand-System gewinnt.
|
||||
|
||||
**SlimCore-Akzent:** Electric Persimmon `#FF6B2C` — festgelegt im Markensystem (`digiformer-brand-system.md` §3.2). Lightness 0.71 / Chroma 0.22 / Hue 38° in OKLCH. Perceptiv auf gleicher Helligkeitsstufe wie digiFORMER-Cyan und SlimSafe-Lime.
|
||||
|
||||
**Familien-Logik:** Mutterbrand digiFORMER trägt Electric Cyan (`#06D8FF`), SlimCore als Produktmarke trägt Electric Persimmon. Die Familien-Anker sind nicht die Farbe, sondern Typografie + Status-Glyphen + nummerierte Sektionen. Adobe-Modell, nicht Atlassian-Modell.
|
||||
|
||||
```css
|
||||
/* SlimCore Akzent — siehe digiformer-brand-system.md §3.2 */
|
||||
--brand-slimcore: oklch(0.71 0.22 38); /* #FF6B2C */
|
||||
--brand-slimcore-hover: oklch(0.62 0.23 38); /* #E04F0F */
|
||||
--brand-slimcore-soft: oklch(0.71 0.22 38 / 0.12); /* tint */
|
||||
|
||||
/* Konvenienz-Aliasse innerhalb dieses Repos */
|
||||
--color-accent: var(--brand-slimcore);
|
||||
--color-accent-hover: var(--brand-slimcore-hover);
|
||||
--color-accent-soft: var(--brand-slimcore-soft);
|
||||
|
||||
/* Text-on-Accent (siehe Brand-System §3.7) */
|
||||
/* WICHTIG: NICHT #FFFFFF — Kontrast unter WCAG-AA bei diesem Orange */
|
||||
--color-text-on-accent: #2A0F02;
|
||||
```
|
||||
|
||||
**Restliche Tokens — Light Mode (Default), familienweit identisch:**
|
||||
|
||||
```css
|
||||
@theme inline {
|
||||
/* Surfaces */
|
||||
--color-bg-base: oklch(0.99 0.005 90); /* ~#FBFAF7 — warm offwhite */
|
||||
--color-bg-surface: oklch(1.00 0 0); /* pure white für Karten */
|
||||
--color-bg-inverse: oklch(0.18 0.01 270); /* ~#1A1B22 — fast schwarz, leicht kühl */
|
||||
|
||||
/* Text */
|
||||
--color-text-primary: oklch(0.20 0.01 270); /* ~#1F2128 */
|
||||
--color-text-secondary: oklch(0.45 0.01 270); /* ~#5C5F6B */
|
||||
--color-text-tertiary: oklch(0.60 0.01 270); /* ~#8B8E97 */
|
||||
|
||||
/* Borders */
|
||||
--color-border: oklch(0.90 0.005 90); /* ~#E2E0DA */
|
||||
--color-border-strong: oklch(0.80 0.005 90);
|
||||
|
||||
/* Status-Glyphen — monochrom, NICHT in Akzentfarbe (siehe Brand-System §5) */
|
||||
--color-status-available: var(--color-text-primary); /* ● = filled */
|
||||
--color-status-developing: oklch(0.20 0.01 270 / 0.45);/* ◐ = halftone */
|
||||
--color-status-planned: transparent; /* ○ = outlined */
|
||||
--color-status-vision: transparent; /* ◌ = dashed */
|
||||
}
|
||||
```
|
||||
|
||||
**Dark Mode (`:root[data-theme="dark"]`)** — invertierte Surface-/Text-Tokens, Marken-Token bleiben unverändert (sie funktionieren in beiden Modi). Detail-Werte beim Implementieren ableiten.
|
||||
|
||||
**Wichtig — Akzent-Verwendungs-Regeln (siehe Brand-System §3.5):**
|
||||
|
||||
- Akzent NUR für: primären CTA, Hover-States, Focus-Rings, 1–2 hervorgehobene Worte in der Hero-Headline, aktive Nav-Indikatoren, „aktuelle Phase"-Pille auf der Roadmap
|
||||
- Akzent NICHT für: Modul-Karten-Hintergründe, Status-Dots (die sind monochrom), Hero-Backgrounds, Border auf Karten, Body-Text-Farbe
|
||||
- Die Akzentfarbe lebt von Knappheit. Wenn auf einer Sektion zwei Worte in Persimmon stehen, ist das viel. Drei sind zu viel.
|
||||
|
||||
### 5.3 Typografie
|
||||
|
||||
```css
|
||||
/* Font-Stacks */
|
||||
--font-serif: "Source Serif 4", Georgia, serif;
|
||||
--font-sans: "Inter", system-ui, sans-serif;
|
||||
--font-mono: "JetBrains Mono", ui-monospace, monospace;
|
||||
|
||||
/* Type-Scale */
|
||||
--text-eyebrow: 0.6875rem; /* 11px, mono, uppercase, letter-spacing 0.08em */
|
||||
--text-body-sm: 0.8125rem; /* 13px */
|
||||
--text-body: 1rem; /* 16px, line-height 1.65 */
|
||||
--text-body-lg: 1.0625rem; /* 17px Hero-Lead */
|
||||
--text-h3: 1.25rem; /* 20px */
|
||||
--text-h2: 1.5rem; /* 24px (mobile) → 1.875rem 30px (desktop) */
|
||||
--text-h1: 2rem; /* 32px (mobile) → 3rem 48px (desktop) → 3.5rem 56px (xl) */
|
||||
--text-display: 3rem; /* 48px Eyecatcher (Souveränität-Block) */
|
||||
```
|
||||
|
||||
**Regeln:**
|
||||
|
||||
- Headlines (`h1`, `h2`): Serif, weight 500 (NICHT 600 oder 700), `letter-spacing: -0.015em` für Display-Größen, `line-height: 1.1–1.2`.
|
||||
- Body: Sans, weight 400, `line-height: 1.65`.
|
||||
- Eyebrows: Mono, 11px, uppercase, `letter-spacing: 0.08em`, Tertiärfarbe.
|
||||
- Status-Dots, Section-Numbern (`01`–`04`), Tech-Stack-Marker: Mono.
|
||||
- Sentence case überall. Niemals Title Case. Niemals ALL CAPS außer Mono-Eyebrows.
|
||||
- Maximale Textbreite für Fließtext: 60–70 Zeichen (`max-w-[65ch]`).
|
||||
|
||||
### 5.4 Spacing & Grid
|
||||
|
||||
- Container: `max-w-[1100px] mx-auto px-6 md:px-10 xl:px-12`.
|
||||
- Section-Padding vertikal: `py-20 md:py-28 xl:py-32`.
|
||||
- Zwischen Hero und erster Sektion: `pt-12 md:pt-20`.
|
||||
- Modul-Grid: 1 Spalte mobil, 2 Spalten tablet, 4 Spalten desktop. `gap-3 md:gap-4`.
|
||||
- Numbered-Items (4er-Reihen): 1/2/4-Spalten responsive.
|
||||
|
||||
### 5.5 Status-Glyphen (zentrales visuelles Vokabular)
|
||||
|
||||
Diese 4 Glyphen ziehen sich durch die ganze Site und sind das wichtigste sekundäre Marken-Asset:
|
||||
|
||||
| Status | Glyph (CSS) | Bedeutung |
|
||||
|---|---|---|
|
||||
| Verfügbar | ● — gefüllter Kreis, primary-text | heute produktiv |
|
||||
| In Entwicklung | ◐ — halbgefüllt (`opacity: 0.45` filled) | aktiv im Bau |
|
||||
| Geplant | ○ — solider Outline-Kreis | feste Roadmap, noch nicht gestartet |
|
||||
| Vision | ◌ — gestrichelter Outline-Kreis | Richtung, nicht Versprechen |
|
||||
|
||||
Implementiert als `<StatusDot status="...">`-Astro-Komponente. NICHT mit Emoji oder SVG-Icons aus Bibliotheken — eigene CSS-Lösung mit `border` und `background`.
|
||||
|
||||
### 5.6 Komponenten-Inventar
|
||||
|
||||
Custom-Komponenten (alle in `src/components/marketing/`):
|
||||
|
||||
- **`Eyebrow`** — Mono-Caption über Headlines. Slot: text. Optional: status (Pill-Style: „IN ENTWICKLUNG").
|
||||
- **`SectionHeading`** — `h2` mit optionalem Eyebrow. Slot: subtitle.
|
||||
- **`NumberedItem`** — Nummeriertes Item für Methoden/Säulen-Listen. Props: `number` (`"01"`), `title`, slot für body. Mono-Nummer in Tertiärfarbe links oben oder über dem Title.
|
||||
- **`ModuleCard`** — eine der 4 Säulen-Karten mit Status-Liste. Props: `pillarNumber`, `pillarTitle`, `modules: { name: string; status: ModuleStatus }[]`.
|
||||
- **`ModuleGrid`** — Wrapper, der 4 ModuleCards in Grid layoutet.
|
||||
- **`StatusDot`** — atomar.
|
||||
- **`TechStrip`** — horizontale Mono-Leiste mit Stack-Komponenten, Trennzeichen `·`.
|
||||
- **`SovereigntyBlock`** — 2-Spalten-Layout (links Headline, rechts 4 Argumente mit Border-Left-Akzent).
|
||||
- **`RoadmapTimeline`** — vertikale Linie mit 4 Phasen (Heute / Q3-Q4 2026 / 2027 / Vision). Jede Phase = Card mit Liste der Items.
|
||||
- **`ObjectionAnswer`** — Frage als Serif-Quote, Antwort als Body-Text. 4 davon im Grid.
|
||||
- **`CTABlock`** — Schluss-Sektion mit Headline + zwei Buttons + E-Mail-Link.
|
||||
- **`NavBar`** — sticky-on-scroll mit minimaler Mode-Reduktion (kein Background-Wechsel-Schauspiel).
|
||||
- **`Footer`** — 4-Spalten, dezente Border-Top, Akzent nur bei Hover-Links.
|
||||
|
||||
### 5.7 Buttons
|
||||
|
||||
```
|
||||
Primary: bg-text-primary text-bg-base, hover: bg-accent
|
||||
Secondary: border-text-primary, transparent bg, hover: bg-text-primary/5
|
||||
Ghost-Link: underline-offset-4, hover: text-accent
|
||||
```
|
||||
|
||||
Keine `rounded-full`-Mega-Pills. `rounded-md` (6–8px) reicht. Padding: `px-5 py-2.5 text-sm` für CTAs, `px-3 py-1.5 text-xs` für Sekundär.
|
||||
|
||||
### 5.8 Was es im Design NICHT gibt
|
||||
|
||||
- Keine Drop-Shadows (außer 1px-Border auf Karten). Keine Glow-Effekte. Keine Glassmorphism.
|
||||
- Keine Farbverläufe/Gradients — nirgends.
|
||||
- Keine animierten Hintergründe, keine Particles, keine Floating-Blobs.
|
||||
- Kein Theme-Switcher zwischen Akzentfarben.
|
||||
- Keine 3D-Render von Software-Mockups (auch wenn AI das schnell macht).
|
||||
- Keine Stock-Fotos von „glücklichen Geschäftsleuten am Laptop".
|
||||
- Keine Emoji als Icons.
|
||||
- Keine bunten Icon-Badges (Material/Heroicons-Buntheit). Wenn Icons: einfarbig, Lucide-Strichstärke 1.5px, Größe 16–20px, Farbe `--color-text-secondary`.
|
||||
|
||||
---
|
||||
|
||||
## 6. Information Architecture
|
||||
|
||||
### 6.1 Sitemap
|
||||
|
||||
```
|
||||
/ Home
|
||||
/module Alle Module mit Status, filterbar
|
||||
/souveraenitaet Long-form über Hosting, Open Source, Egress
|
||||
/tester Tester-Programm + Anmeldeformular
|
||||
/roadmap Detail-Roadmap (verlinkt von Home-Roadmap-Section)
|
||||
/kontakt Kontaktformular + Adresse + E-Mail
|
||||
/notizen (Phase 2) Blog/Notizen, MDX-basiert
|
||||
/notizen/[slug] (Phase 2) Einzelner Notiz-Beitrag
|
||||
/impressum Pflicht
|
||||
/datenschutz Pflicht
|
||||
/danke Tester-Form-Submit-Ziel
|
||||
```
|
||||
|
||||
### 6.2 Navigation
|
||||
|
||||
**Top-Nav (Desktop):**
|
||||
|
||||
```
|
||||
[slimcore] Module · Souveränität · Roadmap · Tester DE | EN [Tester werden →]
|
||||
```
|
||||
|
||||
- Logo links: nur Wortmarke "slimcore" in Mono, weight 500. Kein Icon-Logo (Phase 2 evtl.).
|
||||
- Sprache: Mono, klein. Phase 1 nur DE aktiv, EN ausgegraut. `<a hreflang="...">` korrekt.
|
||||
- CTA rechts: Primary-Button.
|
||||
|
||||
**Mobile:** Hamburger → Drawer (Dialog von rechts). Link-Liste, gleiche Struktur.
|
||||
|
||||
**Sticky-Verhalten:** NavBar bleibt sticky on scroll, aber subtil — `border-b` erscheint nur wenn `scrollY > 8px`, kein Background-Wechsel.
|
||||
|
||||
### 6.3 Footer
|
||||
|
||||
4 Spalten:
|
||||
|
||||
1. Marken-Block: Logo + 1-Zeiler + Newsletter-Hinweis (führt zu `/kontakt#newsletter` — Phase 2).
|
||||
2. Produkt: Module / Souveränität / Roadmap / Tester
|
||||
3. Stack: PostgreSQL / PostgREST / Docker / Hetzner DE
|
||||
4. Kontakt: hallo@slimcore.io / Termin → / digiFORMER GmbH-Adresse
|
||||
|
||||
Bottom-Bar: `© 2026 SlimCore — ein Produkt der digiFORMER GmbH · Impressum · Datenschutz · AGB`
|
||||
|
||||
---
|
||||
|
||||
## 7. Seiten-Spezifikation
|
||||
|
||||
### 7.1 `/` (Home) — der Reihe nach
|
||||
|
||||
**1. Hero**
|
||||
- Eyebrow (Mono): „GESCHÄFTSSOFTWARE FÜR SOLO-SELBSTSTÄNDIGE UND KLEINE TEAMS"
|
||||
- H1 (Serif, Display): „Schlank starten.<br>Grenzenlos wachsen."
|
||||
- „Grenzenlos" optional in Persimmon-Akzent als hervorgehobenes Wort (siehe §5.2 Akzent-Verwendungs-Regeln — sparsam!)
|
||||
- Alternativ-Varianten für späteren A/B-Test: „Klein und schlank. Auch wenn Sie wachsen." / „Eine Plattform für alles, was nicht Buchhaltung ist."
|
||||
- Lead (17px, Sans, secondary): „SlimCore ist die schlanke Geschäftssoftware für Solo-Selbstständige und kleine Teams. Sie aktivieren am Anfang nur, was Sie heute brauchen — meistens CRM, Belege und Aufgaben. Wenn aus Ihnen drei werden, dann fünfzehn, schalten Sie weitere Module zu, ohne zu wechseln."
|
||||
- CTAs: `[Tester werden →]` (primary) `[Module ansehen →]` (secondary)
|
||||
|
||||
**2. Tech-Strip** (direkt unter Hero, voll Container-Breite, `border-y`)
|
||||
- Mono, 11px: `STACK · PostgreSQL · PostgREST · Docker · Traefik · Hetzner Falkenstein / Nürnberg · DSGVO · ZUGFeRD 2.0 · DATEV`
|
||||
|
||||
**3. Modul-Landschaft (Hero-Visual)**
|
||||
- Eyebrow: `VIER SÄULEN · 16 MODULE`
|
||||
- H2: „Aktivieren Sie nur, was Sie heute brauchen."
|
||||
- Lead (1 Satz): „Jedes Modul ist einzeln aktivierbar. Heute starten Sie mit CRM, Belegen und Aufgaben — morgen schalten Sie Versand und Team-E-Mail dazu, ohne Migration, ohne Wechsel."
|
||||
- Legende mit 4 Status-Glyphen
|
||||
- 4-Spalten-Grid mit `<ModuleCard>` für jede Säule (siehe Quelltext der Modul-Liste in §11 / Appendix A)
|
||||
- Footer-Link: `Alle Module & Status ansehen →` führt zu `/module`
|
||||
|
||||
**4. Was uns trennt — drei Differenzierungen**
|
||||
- Eyebrow: `WAS UNS TRENNT`
|
||||
- H2: „Best-Practices der großen Tools. Bedienbar wie ein modernes SaaS."
|
||||
- 3 NumberedItems (01/02/03):
|
||||
- 01 · **Schlank von Tag 1** — „Sie aktivieren das, was Sie heute brauchen — meistens CRM, Belege und Aufgaben. Kein Onboarding-Marathon, keine 27-Module-Suite, die Sie nie ausschöpfen."
|
||||
- 02 · **Wächst mit** — „Wenn aus Ihnen drei werden, dann fünfzehn, bleiben Sie in derselben Software. Team-Postfach, Lager, Versand, Workflow schalten Sie zu, wenn Sie sie wirklich brauchen — ohne Migration."
|
||||
- 03 · **Souverän** — „In Deutschland gehostet, Open-Source-Stack, Datenexport jederzeit. Keine US-Cloud, kein Vendor-Lock-in, keine Lizenzbedingungen, die nächstes Jahr neu geschrieben werden."
|
||||
|
||||
**5. Souveränität (das große Versprechen)**
|
||||
- Eyebrow: `DAS GROSSE VERSPRECHEN`
|
||||
- H2 (Display, 2-spaltig): links „Ihre Daten.<br>Ihr Land.<br>Ihre Kontrolle." | rechts: Lead + 2×2-Grid mit Border-Left-Items für Hosting / Stack / Export / Egress
|
||||
- Footer-Link: `Mehr zur Souveränität →` führt zu `/souveraenitaet`
|
||||
|
||||
**6. Roadmap-Snapshot**
|
||||
- Eyebrow: `ROADMAP`
|
||||
- H2: „Heute. Bald. Vision."
|
||||
- Vertikale 4-Phasen-Timeline (Heute / Q3-Q4 2026 / 2027 / Vision) mit jeweils Modul-Liste
|
||||
- Footer-Link: `Detail-Roadmap →` führt zu `/roadmap`
|
||||
|
||||
**7. Schnell-Argumentarium (5 Einwände)**
|
||||
- Eyebrow: `FÜNF EINWÄNDE, FÜNF SÄTZE`
|
||||
- H2: „Antworten, die Sie sonst erst im dritten Call bekommen."
|
||||
- Grid mit `<ObjectionAnswer>` (auf Mobile gestapelt, auf Desktop 2-spaltig mit ungerader letzter Zeile):
|
||||
1. „Wir sind nur zwei. Lohnt sich das?" → Genau für Sie gebaut. Drei Module zum Start, Module wachsen mit
|
||||
2. „Was, wenn wir wachsen?" → Skaliert von 1 bis ~50, dieselbe Software, mehr aktivierte Module
|
||||
3. „Wir nutzen schon HubSpot." → Lücke zwischen Pipeline und Belegen schließen, ohne HubSpot abzulösen
|
||||
4. „Odoo war zu komplex." → 80 % von Odoo, ohne Implementierungs-Overhead
|
||||
5. „Was, wenn ihr verschwindet?" → Voller Export, offenes Schema, jeder PG-Hoster führt's weiter
|
||||
- (Wortlaute aus PDF §13 — leicht angepasst, NICHT 1:1 wenn das den Lesefluss bricht.)
|
||||
|
||||
**8. Tester-Programm-Teaser**
|
||||
- Eyebrow: `TESTER-PROGRAMM · PHASE 1`
|
||||
- H2: „Sie kennen die Lücken besser als jeder Berater."
|
||||
- Body: „Helfen Sie uns, die Geschäftssoftware zu bauen, die Sie hoffentlich die nächsten zehn Jahre nutzen wollen. Im Gegenzug: früher Einfluss, vergünstigte oder kostenfreie Nutzung — und ein direkter Draht ins Team."
|
||||
- CTAs: `[Tester werden →]` `[hallo@slimcore.io]`
|
||||
|
||||
**9. Final-CTA**
|
||||
- Schlanker Closer: „30 Minuten, kostenlos, unverbindlich. Sie schildern, wo Sie stehen — wir sagen ehrlich, ob SlimCore zu Ihrer Situation passt."
|
||||
- Buttons: `[Tester werden →]` `[Termin vereinbaren →]`
|
||||
|
||||
### 7.2 `/module`
|
||||
|
||||
- Hero-light: Eyebrow + H1 „Module" + Lead „Was Sie aktivieren können — und in welcher Reife."
|
||||
- Filter-Bar (React-Island, `client:visible`): Status-Filter (Alle / Verfügbar / In Entw. / Geplant / Vision) + Säulen-Filter (Alle / 01 / 02 / 03 / 04). Reine Client-Filterung, kein State im URL für Phase 1.
|
||||
- Tabelle/Liste: pro Modul → Name, Säule, Status, 1-Satz-Beschreibung, ggf. Voraussetzungen.
|
||||
- Datenquelle: `src/content/module.ts` als Single Source of Truth (siehe Appendix A).
|
||||
|
||||
### 7.3 `/souveraenitaet`
|
||||
|
||||
Long-form, MDX-fähig. Sektionen:
|
||||
|
||||
1. **Warum das jetzt zählt** — CLOUD Act, Schrems II, geopolitische Unsicherheit (Pascal-Tonalität: nüchtern, nicht alarmistisch)
|
||||
2. **Hosting** — Hetzner, deutsches Recht, DSGVO
|
||||
3. **Open-Source-Stack** — PostgreSQL, PostgREST, Traefik, Docker, React. Tabellen: Komponente → Lizenz → Anbieter
|
||||
4. **Keine US-Abhängigkeiten** — Auth-Layer auf PostgreSQL-Basis (Zitadel als perspektivisches Ziel), Brevo (FR), Adress-Adapter (austauschbar), Garage Object Storage (selbst gehostet)
|
||||
5. **Kein Vendor-Lock-in** — Export-Formate, offenes Schema, BuHa-API-Kompatibilität
|
||||
6. **Optionaler Compliance-Layer** — Egress-Audit, Egress-Proxy
|
||||
|
||||
Visuelle Sprache wie auf Home: nummerierte Sektionen 01–06, viel Mono in Caption, Border-Left-Items für Listen.
|
||||
|
||||
### 7.4 `/tester`
|
||||
|
||||
- Hero: H1 „Tester-Programm · Phase 1", Lead: „Wir suchen Solo-Selbstständige und kleine Teams aus diversen Branchen — und auch ein paar wachsende KMU. Ein bewusst breites Spektrum, weil wir verschiedene Nutzungsmuster sehen wollen, bevor wir verengen."
|
||||
- Sektion „Wer wird gesucht" — Liste aus PDF §10.1 (Solos/Mikroteams primär, KMU sekundär, eCommerce „willkommen, kein Muss")
|
||||
- Sektion „Was Tester bekommen" — Liste aus §10.2
|
||||
- Sektion „Was Tester geben" — Liste aus §10.3
|
||||
- Sektion „Worauf einstellen" — Liste aus §10.4 (kursiv, ehrlicher Disclaimer)
|
||||
- **Anmeldeformular** (`<TesterForm>` React-Island):
|
||||
- Felder: Firma* (mit Hint „auch Einzelunternehmen — geben Sie einfach Ihren Namen an"), Name*, E-Mail*, Telefon (optional)
|
||||
- Branche: Free-Text statt Select (kein Genre-Korsett für die Primärgruppe)
|
||||
- Team-Größe: Range-Slider 1–50, Default 3
|
||||
- „Was nutzen Sie heute?" (Textarea, kurz) — wertvoller Diagnose-Input für Pascal
|
||||
- „Was wäre die größte Lücke?" (Textarea)*
|
||||
- Honeypot-Feld + Altcha (self-hosted Proof-of-Work-Challenge, kein Drittanbieter). Verifikation serverseitig.
|
||||
- Doppel-Opt-in via Brevo
|
||||
- Submit → `/danke`
|
||||
- Footer-Block mit Pascal-Tonalitäts-Zitat aus PDF §10.5
|
||||
|
||||
### 7.5 `/roadmap`
|
||||
|
||||
Detail-Version der Home-Timeline. Pro Phase: alle Module mit aktuellem Status und 1-Satz-Erläuterung. Klare visuelle Trennung „heute funktioniert" vs. „kommt vs. „Vision".
|
||||
|
||||
### 7.6 `/kontakt`
|
||||
|
||||
- Adresse digiFORMER GmbH, hallo@slimcore.io
|
||||
- **Termin-Buchung:** Calendly-Link `https://calendly.com/digiformer/quick-call` — als externer Link in einem neuen Tab, NICHT als Inline-Embed. Damit kein Calendly-JavaScript / keine Cookies in der SlimCore-Domain landen — vermeidet Cookie-Consent-Pflicht.
|
||||
- Kein Kontaktformular auf dieser Seite (Tester-Form ist primärer Funnel).
|
||||
- **Übergangs-Hinweis:** Calendly ist Übergangslösung. Ein SlimCore-natives Termin-Buchungs-Modul ist Pascal-Roadmap-Item; sobald verfügbar, wird der Link durch dieses Modul ersetzt. Bis dahin akzeptierter Souveränitäts-Trade-off, weil Calendly nur als externer Link verwendet wird (keine Daten-Verarbeitung auf slimcore.io selbst).
|
||||
- **Datenschutzerklärung:** Calendly als Datenverarbeiter erwähnen (US-Anbieter, Cookies bei Klick auf den Link), Hetzner und Brevo ebenfalls — siehe §7.7. Kein Cloudflare-Turnstile / reCAPTCHA, weil nicht im Stack.
|
||||
|
||||
### 7.7 `/impressum` & `/datenschutz`
|
||||
|
||||
- Impressum nach §5 TMG, vorbefüllen mit digiFORMER-GmbH-Daten als Platzhalter — Pascal final freigeben.
|
||||
- Datenschutzerklärung: Brevo (FR), Hetzner (DE) als Auftragsverarbeiter, Calendly (US, Übergangs-Realität bis SlimCore-natives Termin-Modul). Altcha ist self-hosted und damit nicht zu nennen. Keine Analytics in Phase 1.
|
||||
|
||||
---
|
||||
|
||||
## 8. Inhaltliche Regeln & Wording
|
||||
|
||||
Quelle: PDF §11 + Pascal-Memory.
|
||||
|
||||
### 8.1 Wording-Konventionen
|
||||
|
||||
- **„Mandant"** statt „Tenant" oder „Workspace"
|
||||
- **„Belegfluss"** statt „Document Flow"
|
||||
- Umlaute schreiben — IMMER `ä/ö/ü/ß`, niemals `ae/oe/ue`
|
||||
- **„KMU"** für die Zielgruppe (nicht „SMB", nicht „Mittelständler" überall)
|
||||
- **„Setup-Service"** statt „Onboarding-Paket"
|
||||
- **„DSGVO-konform"** ist Mindestanforderung — nicht als Verkaufsargument für sich allein
|
||||
- **„SlimCore"** — nicht „Cockpit", nicht „digiFORMER Cockpit"
|
||||
- **„digiFORMER GmbH"** — bei Markenangaben mit Camel-Case
|
||||
- **Kein Verweis auf Personen außerhalb von Pascal Oelmann** als Kontaktperson, solange das Team nicht explizit sichtbar ist
|
||||
|
||||
### 8.2 Tonalitäts-Verbote
|
||||
|
||||
- Keine US-Marketing-Klischees: kein „supercharge", „rocket", „game-changer", „revolutionize", „reimagine"
|
||||
- Keine Versprechen für Vision-Features. Vision = `<StatusDot status="vision">`. Vision wird benannt, nicht verkauft.
|
||||
- Keine echten Kundennamen ohne Freigabe (Phase 1: keine Kunden-Logos auf der Site)
|
||||
- Keine Vergleiche per Markenname ohne juristische Vorprüfung — bei den Einwänden im Schnell-Argumentarium ist HubSpot/Odoo OK (sind Eigenzitate aus typischen Verkaufsgesprächen, kein Vergleichsclaim)
|
||||
- Kein Superlativ ohne Beleg
|
||||
|
||||
### 8.3 Tonalitäts-Gebote
|
||||
|
||||
- Klar, nicht großspurig
|
||||
- Selbstbewusst, nicht arrogant
|
||||
- Pragmatisch, nicht idealistisch (Souveränität ist Nutzen, kein moralisches Argument)
|
||||
- Deutsch zuerst — EN folgt in Phase 2
|
||||
|
||||
---
|
||||
|
||||
## 9. Implementierungs-Phasen
|
||||
|
||||
Claude Code arbeitet diese Phasen sequenziell ab. Jede Phase endet mit einer Pause für Pascal-Review.
|
||||
|
||||
### Phase 0 — Setup (1 Session)
|
||||
|
||||
1. Astro-Projekt initialisieren (`pnpm create astro@latest`, Template: minimal)
|
||||
2. `@astrojs/react`, `@astrojs/sitemap`, `@astrojs/mdx` installieren
|
||||
3. Tailwind v4 einrichten (via Vite-Plugin, nicht via PostCSS)
|
||||
4. `global.css` mit `@theme` und allen Token-Variablen anlegen (siehe §5.2/5.3)
|
||||
5. Self-hosted Fonts in `public/fonts/` ablegen, `@font-face` in `global.css`
|
||||
6. shadcn/ui-Setup für Astro: Button, Input, Textarea, Label, Dialog
|
||||
7. `BaseLayout.astro` mit `<head>`, OG-Tags, NavBar, Footer
|
||||
8. NavBar + Footer minimal funktionsfähig
|
||||
9. **Pause:** Pascal überprüft Look der Layout-Hülle.
|
||||
|
||||
### Phase 1 — Komponenten-Bibliothek (1 Session)
|
||||
|
||||
10. `Eyebrow`, `SectionHeading`, `NumberedItem` — primitive Layout-Bausteine
|
||||
11. `StatusDot`, `ModuleCard`, `ModuleGrid`
|
||||
12. `TechStrip`, `SovereigntyBlock`, `RoadmapTimeline`
|
||||
13. `ObjectionAnswer`, `CTABlock`
|
||||
14. Storybook-light: `/dev/components.astro` — eine interne Seite, die alle Bausteine in allen Varianten zeigt (für visuelle Regression)
|
||||
15. **Pause:** Pascal überprüft Komponenten einzeln.
|
||||
|
||||
### Phase 2 — Home (1 Session)
|
||||
|
||||
16. `index.astro` mit allen 9 Sektionen
|
||||
17. Modul-Daten aus `src/content/module.ts` (Appendix A)
|
||||
18. SEO-Tags, OG-Image (statisches PNG zunächst)
|
||||
19. **Pause:** Pascal Review.
|
||||
|
||||
### Phase 3 — Module + Tester (1–2 Sessions)
|
||||
|
||||
20. `/module` mit Filter-Island
|
||||
21. `/tester` mit Form-Island
|
||||
22. App-API-Anbindung an `app.slimcore.io/api/public/leads` (siehe `slimcore-go-to-market.md` §3 für die Spezifikation). Brevo nur als Transactional-Mail-Provider für die DOI-Bestätigung.
|
||||
23. Altcha-Integration (self-hosted PoW-Challenge): NPM-Paket `altcha-lib` server-seitig, `altcha`-Web-Component clientseitig. Challenge-Endpoint im Astro-Server oder direkt in der App-API. Honeypot-Feld zusätzlich.
|
||||
24. `/danke` Bestätigungsseite
|
||||
25. **Pause:** End-to-End-Test der Tester-Anmeldung.
|
||||
|
||||
### Phase 4 — Restliche Seiten (1 Session)
|
||||
|
||||
26. `/souveraenitaet`, `/roadmap`, `/kontakt`
|
||||
27. `/impressum`, `/datenschutz` (Templates)
|
||||
28. **Pause:** Inhalts-Review mit Pascal.
|
||||
|
||||
### Phase 5 — Polish & Deploy (1 Session)
|
||||
|
||||
29. Lighthouse-Run, alle Scores ≥ 95 (Performance/SEO/A11y/Best-Practices)
|
||||
30. Sitemap + robots.txt
|
||||
31. Open-Graph-Bild dynamisch (Satori als self-hosted Render-Library, KEIN Vercel-OG-Library-Endpoint), optional. Phase 1 reicht statisches PNG.
|
||||
32. Hetzner-VPS-Deployment via Coolify, Domain-Anbindung, Caddy/nginx mit Let's Encrypt
|
||||
33. Playwright-Smoke-Tests für alle Seiten
|
||||
34. **Launch.**
|
||||
|
||||
### Phase 6 — Phase-2-Backlog (später, NICHT Teil des Initial-Builds)
|
||||
|
||||
- `/notizen` Blog mit MDX
|
||||
- EN-Variante mit `astro-i18n` oder Manual-Routing
|
||||
- Newsletter-Doppel-Opt-in über Brevo
|
||||
- Status-Page-Banner („System operational")
|
||||
- Pascal-„Über uns"-Mini-Sektion auf Home
|
||||
|
||||
---
|
||||
|
||||
## 10. Was Claude Code NICHT tun soll
|
||||
|
||||
- ❌ Ein Theme-Switcher zwischen Akzentfarben einbauen (auch nicht als Easter-Egg)
|
||||
- ❌ Komplexe Animationen mit Framer-Motion / GSAP / Lottie
|
||||
- ❌ Card-Hover-Effekte mit `transform` und Schatten
|
||||
- ❌ shadcn-Card-Komponente nutzen — wir bauen eigene minimale Cards
|
||||
- ❌ Stock-Fotos einbauen — keine Bilder von Menschen außer (Phase 2) Pascal-Portrait
|
||||
- ❌ Generierte 3D-Mockups der Software (auch wenn beeindruckend)
|
||||
- ❌ Google Fonts via CDN
|
||||
- ❌ Google Analytics, Hotjar, Meta Pixel — Tracking-Setup ist Phase-2-Diskussion mit Pascal
|
||||
- ❌ HubSpot/Pipedrive/Salesforce-Integrationen — Souveränitäts-Widerspruch
|
||||
- ❌ Cookie-Banner für nicht-existente Cookies. Altcha ist self-hosted (keine Drittpartei), Brevo läuft nur als Mail-Versender (keine Cookies auf slimcore.io), keine Analytics in Phase 1 — kein Banner nötig.
|
||||
- ❌ Vision-Features als verfügbar darstellen
|
||||
- ❌ Erfundene Kundenstimmen oder Logo-Walls
|
||||
|
||||
---
|
||||
|
||||
## 11. Module-Daten (Single Source of Truth)
|
||||
|
||||
Datei: `src/content/module.ts`
|
||||
|
||||
```typescript
|
||||
export type ModuleStatus = 'available' | 'developing' | 'planned' | 'vision';
|
||||
export type Pillar = '01' | '02' | '03' | '04';
|
||||
|
||||
export interface Module {
|
||||
id: string;
|
||||
name: string;
|
||||
pillar: Pillar;
|
||||
pillarTitle: string;
|
||||
status: ModuleStatus;
|
||||
description: string;
|
||||
}
|
||||
|
||||
export const modules: readonly Module[] = [
|
||||
// Pillar 01 — Kunden & Kommunikation
|
||||
{ id: 'crm', name: 'CRM', pillar: '01', pillarTitle: 'Kunden & Kommunikation', status: 'available', description: 'Zentrale Kontaktverwaltung mit Firmen/Personen, Interaktions-Timeline, Vertriebs-Pipeline (Kanban), Tags, Custom Fields, Massenaktionen.' },
|
||||
{ id: 'team-email', name: 'Team-E-Mail', pillar: '01', pillarTitle: 'Kunden & Kommunikation', status: 'developing', description: 'Geteilte Postfächer über MS365 angebunden. Drei-Spalten-UI, automatische CRM-Zuordnung, Inbox-Übersicht.' },
|
||||
{ id: 'helpdesk', name: 'Helpdesk', pillar: '01', pillarTitle: 'Kunden & Kommunikation', status: 'planned', description: 'Aus E-Mails werden Tickets. Zuweisung, Status-Workflow, SLA-Tracking. Kein Portal-Konto nötig.' },
|
||||
{ id: 'phone', name: 'Telefonie', pillar: '01', pillarTitle: 'Kunden & Kommunikation', status: 'planned', description: 'Yeastar P520-Anbindung. Echtzeit-Erfassung, CRM-Zuordnung, verpasste Anrufe als Widget.' },
|
||||
{ id: 'whatsapp', name: 'WhatsApp', pillar: '01', pillarTitle: 'Kunden & Kommunikation', status: 'planned', description: 'WhatsApp Business API als Eingangskanal. Automatisches CRM-Matching, Timeline-Eintrag.' },
|
||||
|
||||
// Pillar 02 — Handel & Logistik
|
||||
{ id: 'items', name: 'Artikel', pillar: '02', pillarTitle: 'Handel & Logistik', status: 'developing', description: 'Stammdaten mit Varianten, Stücklisten/Bundles, Chargen-/MHD-/Seriennummern, Preislisten, EU-LMIV-Felder.' },
|
||||
{ id: 'inventory', name: 'Lager', pillar: '02', pillarTitle: 'Handel & Logistik', status: 'available', description: 'Lagerorte, Bestandsführung, Wareneingänge, FIFO/FEFO, MHD-Tracking, Seriennummern, mehrere Lager.' },
|
||||
{ id: 'orders', name: 'Bestellungen', pillar: '02', pillarTitle: 'Handel & Logistik', status: 'available', description: 'Alle Kanäle konsolidiert. Positionsverwaltung, Status-Workflow, Bezahlstatus-Tracking.' },
|
||||
{ id: 'channels', name: 'Verkaufskanäle', pillar: '02', pillarTitle: 'Handel & Logistik', status: 'developing', description: 'WooCommerce bidirektional, Amazon SP-API kurz davor, Shopify/Kaufland/Etsy später.' },
|
||||
{ id: 'shipping', name: 'Versand', pillar: '02', pillarTitle: 'Handel & Logistik', status: 'developing', description: 'Multi-Carrier: DHL zuerst, DPD/GLS/Hermes folgen. Label, Tracking, Shiptastic-Integration.' },
|
||||
{ id: 'purchasing', name: 'Einkauf', pillar: '02', pillarTitle: 'Handel & Logistik', status: 'planned', description: 'Lieferanten als CRM-Kontakte, Einkaufsbestellungen, Wareneingang mit Bestandsbuchung.' },
|
||||
|
||||
// Pillar 03 — Belege & Finanzen
|
||||
{ id: 'documents', name: 'Belege', pillar: '03', pillarTitle: 'Belege & Finanzen', status: 'available', description: 'Konfigurierbarer Belegfluss: Angebot → AB → Lieferschein → Rechnung → Gutschrift → Mahnung. PDF-Erzeugung, Vorlagen pro Mandant.' },
|
||||
{ id: 'invoices', name: 'Rechnungen', pillar: '03', pillarTitle: 'Belege & Finanzen', status: 'developing', description: 'Aus Bestellungen, Zeiterfassung oder manuell. ZUGFeRD 2.0 und XRechnung.' },
|
||||
{ id: 'payments', name: 'Zahlungen', pillar: '03', pillarTitle: 'Belege & Finanzen', status: 'available', description: 'Offene-Posten, Zahlungseingänge, Teilzahlungen, vierstufiges Mahnwesen, Liquiditäts-Widget.' },
|
||||
{ id: 'accounting', name: 'BuHa-Export', pillar: '03', pillarTitle: 'Belege & Finanzen', status: 'available', description: 'DATEV-CSV produktiv, sevDesk-API und Lexware-API in Vorbereitung.' },
|
||||
|
||||
// Pillar 04 — Team & Organisation
|
||||
{ id: 'tasks', name: 'Aufgaben', pillar: '04', pillarTitle: 'Team & Organisation', status: 'developing', description: 'Kanban oder Liste. Zuweisung, Fälligkeiten, Kommentare, Verknüpfung mit Kontakten/Bestellungen/Belegen.' },
|
||||
{ id: 'projects', name: 'Projekte', pillar: '04', pillarTitle: 'Team & Organisation', status: 'planned', description: 'Klammer um Aufgaben mit Meilensteinen und Budget-Tracking.' },
|
||||
{ id: 'time', name: 'Zeiterfassung', pillar: '04', pillarTitle: 'Team & Organisation', status: 'planned', description: 'Stempeluhr + Projektzeiten. Erfasste Zeiten werden auf Wunsch zu Rechnungspositionen.' },
|
||||
{ id: 'hr', name: 'Personal', pillar: '04', pillarTitle: 'Team & Organisation', status: 'planned', description: 'Stammdaten, Arbeitsverträge, Urlaubsanträge mit Genehmigungs-Workflow, Abwesenheitskalender.' },
|
||||
] as const;
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 12. SEO & Meta
|
||||
|
||||
### 12.1 Globale Meta-Tags (in `BaseLayout.astro`)
|
||||
|
||||
```html
|
||||
<title>{title} — SlimCore</title>
|
||||
<meta name="description" content="{description}" />
|
||||
<meta property="og:title" content="{title}" />
|
||||
<meta property="og:description" content="{description}" />
|
||||
<meta property="og:image" content="{ogImage ?? '/og-default.png'}" />
|
||||
<meta property="og:type" content="website" />
|
||||
<meta property="og:locale" content="de_DE" />
|
||||
<meta name="twitter:card" content="summary_large_image" />
|
||||
<link rel="canonical" href="{canonicalUrl}" />
|
||||
<link rel="alternate" hreflang="de" href="{deUrl}" />
|
||||
<!-- hreflang en kommt in Phase 2 -->
|
||||
```
|
||||
|
||||
### 12.2 Default-Texte
|
||||
|
||||
- Site-Title: `SlimCore — Schlanke Geschäftssoftware für Solo-Selbstständige und kleine Teams`
|
||||
- Site-Description: `Modulare SaaS-Plattform für CRM, Belege, Aufgaben und Workflow. Schlank starten, grenzenlos wachsen — in Deutschland gehostet, Open-Source-Stack, kein Vendor-Lock-in.`
|
||||
|
||||
### 12.3 Pro-Seite-Meta (Beispiele)
|
||||
|
||||
```ts
|
||||
export const meta = {
|
||||
'/': { title: 'Schlank starten. Grenzenlos wachsen.', description: 'Schlanke Geschäftssoftware für Solo-Selbstständige und kleine Teams. CRM, Belege, Aufgaben — modular, in Deutschland gehostet, Open Source, kein Vendor-Lock-in.' },
|
||||
'/module': { title: 'Module — Was Sie aktivieren können', description: '16 Module in 4 Säulen. Was heute produktiv ist, was im Aufbau ist, was in der Roadmap steht. Aktivieren Sie heute drei, schalten Sie morgen das vierte zu.' },
|
||||
'/souveraenitaet':{ title: 'Digitale Souveränität — wie SlimCore das löst', description: 'Hetzner-Rechenzentren, Open-Source-Stack, kein US-Anbieter im Datenfluss, voller Datenexport in offenen Formaten.' },
|
||||
'/tester': { title: 'Tester-Programm — Phase 1', description: 'Wir suchen Solo-Selbstständige und kleine Teams für die Tester-Phase. Früher Einfluss, vergünstigte Nutzung, direkter Draht ins Team.' },
|
||||
'/roadmap': { title: 'Roadmap — Heute, bald, Vision', description: 'Was heute produktiv ist, was Q3/Q4 2026 kommt, was 2027 ansteht, und wohin wir wollen.' },
|
||||
};
|
||||
```
|
||||
|
||||
### 12.4 Strukturierte Daten
|
||||
|
||||
`schema.org/SoftwareApplication` auf der Home als JSON-LD:
|
||||
|
||||
```json
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "SoftwareApplication",
|
||||
"name": "SlimCore",
|
||||
"applicationCategory": "BusinessApplication",
|
||||
"operatingSystem": "Web",
|
||||
"offers": { "@type": "Offer", "priceCurrency": "EUR" },
|
||||
"publisher": {
|
||||
"@type": "Organization",
|
||||
"name": "digiFORMER GmbH",
|
||||
"url": "https://digiformer.eu"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 13. Performance-Budget
|
||||
|
||||
| Metrik | Ziel |
|
||||
|---|---|
|
||||
| LCP | < 1.5 s |
|
||||
| CLS | < 0.05 |
|
||||
| Total JS Bundle (Home) | < 50 KB nach gzip |
|
||||
| Total Page Weight (Home) | < 200 KB ohne Fonts |
|
||||
| Fonts | self-hosted, woff2, `font-display: swap`, subset Latin-Ext |
|
||||
|
||||
Astro liefert das mit Bordmitteln, solange wir keine Bilder ohne Optimierung einbauen. Alle eingebundenen Bilder über Astro's `<Image>` mit AVIF-Output.
|
||||
|
||||
---
|
||||
|
||||
## 14. Accessibility
|
||||
|
||||
- Alle interaktiven Elemente keyboard-erreichbar
|
||||
- Focus-Ring sichtbar (2px solid var(--color-accent), offset 2px)
|
||||
- Color-Contrast ≥ 4.5:1 für Body-Text, ≥ 3:1 für Large Text
|
||||
- `prefers-reduced-motion` respektieren — keine Auto-Scroll-Animationen
|
||||
- Form-Labels immer sichtbar (kein Placeholder-as-Label)
|
||||
- `aria-describedby` für Form-Hilfetexte
|
||||
- Sprache-Switcher: `<a hreflang>` korrekt gesetzt
|
||||
- Heading-Hierarchie strikt: ein H1 pro Seite, dann H2 → H3, keine Sprünge
|
||||
|
||||
---
|
||||
|
||||
## 15. Referenz-URLs
|
||||
|
||||
- **digiFORMER (Familien-Anker):** https://digiformer.lovable.app — Tonalität, nummerierte Sektionen, Editorial-Haltung
|
||||
- **Lovable-Entwurf SlimCore (Counter-Example):** https://slimcore-sparkle-design.lovable.app — was zu vermeiden ist (Theme-Switcher, zu bunt, fehlendes Modul-Visual)
|
||||
- **Produktbeschreibung (Master-Quelle):** `/docs/produktbeschreibung.pdf` und `/docs/produktbeschreibung.md`
|
||||
- **Markensystem (familienweit):** `/docs/digiformer-brand-system.md` — Farben, Typografie, Status-Glyphen
|
||||
- **Go-to-Market-Dokument:** lebt im SlimCore-App-Repo unter `/docs/slimcore-go-to-market.md` — dort sind API-Spezifikation für `/api/public/leads`, die drei Phasen, Workflow-Templates und Payment-Provider-Strategie dokumentiert. Marketing-Site referenziert dieses Dokument für die Form-Submission-Spec.
|
||||
|
||||
Claude Code soll die digiFORMER-Site EINMAL pro Session als visuelle Referenz fetchen, NICHT 1:1 nachbauen — sondern die typografische Haltung übernehmen und die Modul-zentrische Eigenständigkeit von SlimCore drauflegen.
|
||||
|
||||
---
|
||||
|
||||
## 16. Glossar
|
||||
|
||||
| Begriff | Bedeutung |
|
||||
|---|---|
|
||||
| Mandant | ein Kunde von SlimCore (= Tenant) |
|
||||
| Säule | eine der 4 Modul-Gruppen |
|
||||
| Modul | eine funktionale Einheit (CRM, Lager, ...) |
|
||||
| Belegfluss | Angebot → AB → Lieferschein → Rechnung → Gutschrift → Mahnung |
|
||||
| BuHa | Buchhaltung |
|
||||
| KMU | Kleine und Mittlere Unternehmen |
|
||||
| Setup-Service | Bezahlte Einrichtung/Datenmigration/Schulung |
|
||||
| Tester-Phase 1 | Aktuelle Programm-Stufe für Early Adopters |
|
||||
|
||||
---
|
||||
|
||||
## 17. Offene Entscheidungen (für Pascal)
|
||||
|
||||
Diese Punkte sind nicht final — Claude Code soll bei dem genannten Default starten und Pascal explizit auf die Stelle hinweisen, an der die Entscheidung steht.
|
||||
|
||||
1. **Akzentfarbe SlimCore — ✓ ENTSCHIEDEN:** Persimmon `#EC5C29`, Teil des familienweiten Markensystems. Siehe `digiformer-brand-system.md`.
|
||||
2. **Hosting — ✓ ENTSCHIEDEN:** Hetzner-VPS (DE) mit Coolify als Deployment-Layer. OVHcloud (FR) als zweite Option. Vercel/Netlify/Cloudflare-Pages ausgeschlossen — siehe Brand-System §7.4.
|
||||
3. **Form-Backend — ✓ ENTSCHIEDEN:** App-API (`app.slimcore.io/api/public/leads`) als primärer Endpoint. Brevo nur für Transactional-Mail. Spezifikation siehe `slimcore-go-to-market.md` §3.
|
||||
4. **Termin-Buchung — ✓ ENTSCHIEDEN:** Calendly `https://calendly.com/digiformer/quick-call`, als externer Link (kein Embed). Übergangslösung bis zum SlimCore-eigenen Buchungs-Modul. Datenschutzerklärung muss Calendly nennen.
|
||||
5. **OG-Image** — Phase 1: statisches PNG. Phase 2: dynamische Generierung via Satori.
|
||||
6. **Cookie-Consent** — abhängig von finalem Tracking-Setup. Default Phase 1: kein Banner, weil keine Cookies, die Consent benötigen.
|
||||
7. **Tokens-Paket** — Heute: Werte aus `digiformer-brand-system.md` kopieren. Später: `@digiformer/design-tokens` npm-Paket aufsetzen, wenn der dritte Marken-Build ansteht (Phase 2).
|
||||
8. **Bot-Schutz — ✓ ENTSCHIEDEN:** Altcha (Open Source, self-hosted). Keine Drittpartei zwischen Tester und SlimCore — das ist die souveränitäts-konsistenteste Option. Implementiert als kleiner Server-Endpoint (Proof-of-Work-Challenge), der lokal vom Astro-Backend oder direkt von der App-API ausgeliefert wird. Plus Honeypot-Feld. Friendly Captcha bleibt Backup, falls Altcha-PoW gegen Bot-Volumen nicht reicht.
|
||||
9. **Analytics — ✓ ENTSCHIEDEN:** Keine in Phase 1. Datenschutz-Premium und ein zusätzlicher konsistenter Souveränitäts-Punkt („Wir tracken Sie nicht" als Marken-Argument). Pirsch (DE) oder Plausible (EE) bleiben als Option für Phase 2, wenn Conversion-Optimierung relevant wird.
|
||||
10. **Code-Hosting — ✓ ENTSCHIEDEN:** GitHub für den Start (Übergangs-Realität, siehe Brand-System §7.5). Forgejo selbst gehostet auf Hetzner als mittel-fristiges Ziel. Migration vor erstem Production-Secret-Rollout. Bis dahin: keine sensiblen Secrets in GitHub-Issues, keine privaten Kunden-Daten in Repo-Files.
|
||||
|
||||
---
|
||||
|
||||
**Ende des Briefs.** Claude Code soll diese Datei in jeder Session zuerst lesen und bei Implementierungs-Entscheidungen explizit auf Sektionen verweisen.
|
||||
374
docs/digiformer-brand-system.md
Normal file
374
docs/digiformer-brand-system.md
Normal file
|
|
@ -0,0 +1,374 @@
|
|||
# digiFORMER Brand System
|
||||
|
||||
> **Stand:** 2026-05-04 · **Inhaber:** digiFORMER GmbH · **Pflege:** Pascal Oelmann
|
||||
> **Geltungsbereich:** Mutterbrand digiFORMER und alle Produktmarken (SlimCore, trendscout, SlimSafe, künftige).
|
||||
> **Zweck:** Diese Datei ist die Single Source of Truth für Farben, Typografie, visuelles Vokabular und Markenarchitektur. Jedes Repo, das eine Markenoberfläche produziert, importiert die Tokens aus dem (geplanten) Paket `@digiformer/design-tokens` — bis das existiert, kopiert man die Werte aus diesem Dokument.
|
||||
|
||||
---
|
||||
|
||||
## 1. Markenarchitektur
|
||||
|
||||
### 1.1 Beziehung zwischen Mutterbrand und Produkten
|
||||
|
||||
digiFORMER ist eine **Beratungs- und Umsetzungs-Marke**. SlimCore, trendscout, SlimSafe und alle weiteren Produkte sind **eigenständige Produktmarken unter dem digiFORMER-Dach**. Das Verhältnis folgt dem **Adobe-Modell**: der Mutterbrand sorgt für Stabilität und Vertrauen in formellen Kontexten (Pitch-Decks, Verträge, Vorstandsgespräche), die Produktmarken dürfen jeweils eigene laute Persönlichkeiten haben und werden nicht visuell mit dem Mutterbrand verschmolzen.
|
||||
|
||||
Konsequenz: Wenn auf einer SlimCore-Site „ein Produkt der digiFORMER GmbH" steht, ist das eine *Quellenangabe*, kein visuelles Hauptmotiv. SlimCore trägt seine eigene Akzentfarbe, nicht die von digiFORMER.
|
||||
|
||||
### 1.2 Was die Familie verbindet
|
||||
|
||||
Die Familienzugehörigkeit wird **nicht über Farbe** hergestellt, sondern über drei andere Ebenen, die auf jeder Site identisch sind:
|
||||
|
||||
1. **Typografisches System** — Source Serif 4 für Headlines, Inter für Body, JetBrains Mono für technische Marker. Skalen, Gewichte und Sentence-case-Regeln gleich.
|
||||
2. **Strukturelles Vokabular** — nummerierte Sektionen (`01`–`04`), Mono-Eyebrows in Tertiärfarbe, Editorial-Layout mit viel Weißraum, eine Akzentfarbe statt Farbflächen-Show.
|
||||
3. **Status-Glyphen** — `●` `◐` `○` `◌` werden überall identisch genutzt (siehe §5).
|
||||
|
||||
Was die Familie unterscheidet: jede Marke hat genau eine eigene Akzentfarbe (siehe §3).
|
||||
|
||||
---
|
||||
|
||||
## 2. Markenarchitektur-Regeln
|
||||
|
||||
### 2.1 Naming
|
||||
|
||||
- Mutterbrand: **digiFORMER** (Camel-Case, das `digi` immer klein, `FORMER` immer groß). Die GmbH-Form heißt **digiFORMER GmbH**.
|
||||
- Produktmarken: **SlimCore**, **trendscout**, **SlimSafe** — jeweils Camel-Case ohne Leerzeichen. `slimcore.io` (Domain) wird kleingeschrieben, im Fließtext aber `SlimCore`.
|
||||
- Niemals: „Cockpit", „digiFORMER Cockpit", „Slim Core" (mit Leerzeichen), „Trend Scout", „Slim Safe".
|
||||
|
||||
### 2.2 Sub-Branding-Verbote
|
||||
|
||||
- Kein Produktlogo darf das digiFORMER-Logo als Element enthalten
|
||||
- Keine Site nutzt zwei Akzentfarben gleichzeitig
|
||||
- Kein Theme-Switcher zwischen Marken-Akzentfarben innerhalb einer Site
|
||||
- Wenn ein Produkt einen Footer-Hinweis auf den Mutterbrand braucht, dann als kleiner Text-Link: `ein Produkt der digiFORMER GmbH`, nicht als farbiges Banner
|
||||
|
||||
### 2.3 Mutterbrand-zu-Produkt-Verlinkung
|
||||
|
||||
- digiFORMER-Site verlinkt auf alle Produkt-Sites unter `/digitools` (so bereits umgesetzt)
|
||||
- Produkt-Sites verlinken im Footer auf `digiformer.eu`, nicht auf andere Produkte (Cross-Linking zwischen Produkten ist Phase 2, wenn mehrere live sind)
|
||||
|
||||
---
|
||||
|
||||
## 3. Farbsystem
|
||||
|
||||
### 3.1 System-Logik
|
||||
|
||||
Alle Markenfarben des Systems liegen auf einem **gleichmäßig verteilten Farbkreis** mit **gleicher Sättigungs-Energie** („elektrisch-mutig"). Damit:
|
||||
|
||||
- ist jede Farbe von jeder anderen klar unterscheidbar
|
||||
- entsteht keine versehentliche Hierarchie zwischen Marken
|
||||
- harmonieren alle Farben, wenn sie nebeneinander auftreten
|
||||
- bleibt Raum für künftige Produkte ohne Restrukturierung
|
||||
|
||||
Es gibt **8 Slots** auf 360°. Vier sind aktiv besetzt, vier sind Reserve.
|
||||
|
||||
### 3.2 Aktive Markenfarben
|
||||
|
||||
| Marke | Rolle | OKLCH | Hex (≈) | Hue |
|
||||
|---|---|---|---|---|
|
||||
| **digiFORMER** | Beratung & Umsetzung | `oklch(0.78 0.16 215)` | `#06D8FF` | 215° (Electric Cyan) |
|
||||
| **SlimCore** | Geschäftssoftware | `oklch(0.71 0.22 38)` | `#FF6B2C` | 38° (Electric Persimmon) |
|
||||
| **trendscout** | Trend-Radar für E-Commerce | `oklch(0.62 0.25 350)` | `#E91E63` | 350° (Magenta) |
|
||||
| **SlimSafe** | Sicherheit & Compliance* | `oklch(0.86 0.22 130)` | `#A3E635` | 130° (Lime) |
|
||||
|
||||
*SlimSafe-Rolle ist Arbeitsannahme, bis das Produkt sich weiter konkretisiert.
|
||||
|
||||
### 3.3 Reserve-Slots für künftige Produkte
|
||||
|
||||
Vier weitere Slots auf dem Farbkreis sind reserviert. Bei einem neuen Produkt wird einer davon belegt — geleitet vom inhaltlichen Charakter, nicht von Reihenfolge.
|
||||
|
||||
| Slot | OKLCH | Hex (≈) | Hue | Charakter / passend für |
|
||||
|---|---|---|---|---|
|
||||
| **R1 — Acid Yellow** | `oklch(0.86 0.20 85)` | `#FACC15` | 85° | Schnell, sichtbar, kreativ — Marketing-/Content-/UGC-Werkzeuge, Kampagnen-Tools |
|
||||
| **R2 — Mint** | `oklch(0.74 0.15 165)` | `#14B8A6` | 165° | Ruhig, klar, sauber — Wartungs-, Admin-, Monitoring-, Wellness-Tools |
|
||||
| **R3 — Cobalt** | `oklch(0.50 0.22 265)` | `#2D52FF` | 265° | Vertrauen, Autorität — Finanz-, Recht-, Compliance-fokussierte Tools |
|
||||
| **R4 — Electric Violet** | `oklch(0.55 0.25 295)` | `#7C3AED` | 295° | AI, Intelligenz — Analytik-, ML-, Knowledge-Tools |
|
||||
|
||||
**Regel zur Belegung:** Slots werden in der Reihenfolge des Charakters zugewiesen, nicht in der Reihenfolge der Produkt-Launches. Wenn das nächste Produkt z. B. ein Audit-Tool ist, bekommt es Cobalt — nicht Acid Yellow nur weil das die niedrigste Slot-Nummer ist.
|
||||
|
||||
### 3.4 Hover- und Soft-Varianten
|
||||
|
||||
Für jede Markenfarbe gibt es zwei zwingende Begleit-Werte:
|
||||
|
||||
```
|
||||
Base — Vollton, für CTAs, Status-Highlights, primäre Marken-Anwendungen
|
||||
Hover — etwa 15–20% dunkler als Base, für Button-Hover und :active
|
||||
Soft — Base mit Alpha-Wert 0.10–0.12, für seltene Surface-Tints
|
||||
(z. B. „aktive Filter-Pille" oder Notification-Hintergrund)
|
||||
```
|
||||
|
||||
Beispiel SlimCore (Electric Persimmon):
|
||||
|
||||
```css
|
||||
--brand-slimcore: oklch(0.71 0.22 38); /* #FF6B2C */
|
||||
--brand-slimcore-hover: oklch(0.62 0.23 38); /* #E04F0F */
|
||||
--brand-slimcore-soft: oklch(0.71 0.22 38 / 0.12); /* tint */
|
||||
```
|
||||
|
||||
**Hue-Justage-Hinweis:** Electric Persimmon wurde 2026-05-04 von einem ursprünglichen `#EC5C29` (L 0.66 / C 0.19) auf den heutigen Wert kalibriert, um die perceptive Helligkeit an Cyan (L 0.78) und Lime (L 0.86) anzunähern. Dadurch entsteht ein in sich konsistentes Familienfoto, in dem keine Marke „dunkler" wirkt als die anderen.
|
||||
|
||||
### 3.5 Farb-Anwendungs-Regeln (gelten für jede Marken-Site)
|
||||
|
||||
- **Eine Akzentfarbe pro Site.** Niemals zwei Markenfarben in einer Oberfläche. Wenn eine SlimCore-Site auf ein digiFORMER-Cluster verlinkt, bleibt der Link in SlimCore-Persimmon — nicht in digiFORMER-Cyan.
|
||||
- **Akzent ist knapp.** Akzentfarbe wird ausschließlich verwendet für:
|
||||
- primäre CTA-Buttons (Background)
|
||||
- Hover-States auf Links
|
||||
- Focus-Rings bei Form-Elementen
|
||||
- 1–2 hervorgehobene Wörter in der Hero-Headline (optional, sparsam)
|
||||
- aktive Nav-Indikatoren (z. B. unterstrichene aktive Sektion)
|
||||
- Status-Pille „aktuelle Phase" auf der Roadmap
|
||||
- **Akzent wird NICHT verwendet für:**
|
||||
- Karten-Hintergründe (außer in seltenen Fällen mit `-soft`-Variante)
|
||||
- Body-Text-Farbe
|
||||
- Border auf Karten (außer fokussierten/aktiven)
|
||||
- Status-Dots der Modul-Liste (siehe §5 — Status-Glyphen sind monochrom)
|
||||
- Diagramme/Charts — diese nutzen die Tailwind-`c-`-Ramp-Klassen, nicht Akzentfarben
|
||||
- **Auf hellem Hintergrund:** Base-Variante. Auf fast-schwarzem Hintergrund (invertierter Hero): gleiche Base-Variante — unsere Markenfarben sind so gewählt, dass sie auf beiden Untergründen funktionieren.
|
||||
|
||||
### 3.6 Konstrast-Mindestwerte
|
||||
|
||||
Jede Akzentfarbe muss mit ihrem definierten Kontrastpartner (siehe §3.7) WCAG AA erreichen:
|
||||
|
||||
- Body-Text auf Akzent-Background: ≥ 4.5:1
|
||||
- Large Text (≥18px bold oder ≥24px regular) auf Akzent-Background: ≥ 3:1
|
||||
- UI-Komponenten und Border: ≥ 3:1
|
||||
|
||||
Wenn eine Akzentfarbe diese Werte mit Standard-Schwarz/-Weiß nicht erreicht, ist die definierte Text-on-Accent-Farbe aus §3.7 verbindlich.
|
||||
|
||||
### 3.7 Text-on-Accent (Vordergrund auf farbigem Hintergrund)
|
||||
|
||||
| Marke | Text-on-Accent (Hex) | Begründung |
|
||||
|---|---|---|
|
||||
| digiFORMER (`#06D8FF`) | `#003845` | Cyan ist hell — schwarzer Text wirkt zu hart, dunkles Petrol harmoniert |
|
||||
| SlimCore (`#FF6B2C`) | `#2A0F02` | Electric Persimmon ist heller als der ursprüngliche Wert — weißer Text fällt unter WCAG-AA. Dunkles Persimmon-Schwarz erreicht 9:1 (AAA) und macht den Button visuell entschiedener |
|
||||
| trendscout (`#E91E63`) | `#FFFFFF` | Magenta ist dunkel genug für weißen Text |
|
||||
| SlimSafe (`#A3E635`) | `#2A3D08` | Lime ist sehr hell — schwarzer Text zu hart, dunkles Olivgrün harmoniert |
|
||||
| R1 Acid Yellow (`#FACC15`) | `#3D2E00` | Yellow extrem hell — dunkles Braun |
|
||||
| R2 Mint (`#14B8A6`) | `#FFFFFF` | dunkel genug für Weiß |
|
||||
| R3 Cobalt (`#2D52FF`) | `#FFFFFF` | dunkel genug für Weiß |
|
||||
| R4 Violet (`#7C3AED`) | `#FFFFFF` | dunkel genug für Weiß |
|
||||
|
||||
---
|
||||
|
||||
## 4. Typografie (familienweit)
|
||||
|
||||
Identisch über alle Marken-Oberflächen.
|
||||
|
||||
### 4.1 Font-Stacks
|
||||
|
||||
```css
|
||||
--font-serif: "Source Serif 4", Georgia, serif;
|
||||
--font-sans: "Inter", system-ui, sans-serif;
|
||||
--font-mono: "JetBrains Mono", ui-monospace, monospace;
|
||||
```
|
||||
|
||||
Alle drei Schriften sind unter SIL OFL lizenziert und werden **self-hosted** ausgeliefert (keine Google-Fonts-CDN — DSGVO).
|
||||
|
||||
### 4.2 Hierarchie
|
||||
|
||||
| Rolle | Familie | Größe | Gewicht | Letter-Spacing | Line-Height |
|
||||
|---|---|---|---|---|---|
|
||||
| Display (Hero) | Serif | 48–56px | 500 | -0.015em | 1.05 |
|
||||
| H1 | Serif | 32–40px | 500 | -0.015em | 1.10 |
|
||||
| H2 | Serif | 24–32px | 500 | -0.005em | 1.20 |
|
||||
| H3 | Serif | 20px | 500 | 0 | 1.30 |
|
||||
| Body Lead | Sans | 17px | 400 | 0 | 1.55 |
|
||||
| Body | Sans | 16px | 400 | 0 | 1.65 |
|
||||
| Body small | Sans | 13px | 400 | 0 | 1.55 |
|
||||
| Eyebrow | Mono | 11px | 500 | 0.08em | 1.20 (uppercase) |
|
||||
| Caption | Mono | 11px | 400 | 0.04em | 1.35 |
|
||||
|
||||
### 4.3 Regeln
|
||||
|
||||
- **Sentence case** überall. Niemals Title Case. ALL CAPS nur für Mono-Eyebrows.
|
||||
- **Maximal zwei Gewichte:** 400 regular + 500 medium. Niemals 600 oder 700.
|
||||
- **Niemals mid-sentence bolding.** Hervorhebungen sind Sache der Akzentfarbe oder kursiver Schrift.
|
||||
- **Maximale Zeilenbreite:** 60–70 Zeichen (`max-w-[65ch]`) für Fließtext.
|
||||
- **Mono für „technisch":** Stack-Bezeichnungen, Status-Labels, Sektions-Nummern (`01`/`02`), Versions-Marker, Timestamps.
|
||||
- **Serif für „inhaltlich":** Headlines, eventuell Pull-Quotes, Editorial-Pull-Outs.
|
||||
|
||||
---
|
||||
|
||||
## 5. Status-Glyphen (familienweites visuelles Vokabular)
|
||||
|
||||
Diese vier Glyphen sind das wichtigste sekundäre Marken-Asset — sie ziehen sich durch jede Marken-Site und schaffen Wiedererkennbarkeit auch dann, wenn die Akzentfarbe wechselt.
|
||||
|
||||
| Glyph | CSS | Bedeutung | Farbe |
|
||||
|---|---|---|---|
|
||||
| ● | gefüllter Kreis | Verfügbar / live / produktiv | `--color-text-primary` |
|
||||
| ◐ | halbgefüllt (Opacity 0.45) | In Entwicklung / aktiv im Bau | `--color-text-primary` mit α 0.45 |
|
||||
| ○ | solider Outline-Kreis | Geplant / feste Roadmap | `--color-text-tertiary` |
|
||||
| ◌ | gestrichelter Outline-Kreis | Vision / Richtung | `--color-text-tertiary`, dashed |
|
||||
|
||||
**Wichtig:** Status-Dots sind **monochrom**, nicht in der jeweiligen Markenfarbe. Sie sind Teil des familienweiten Vokabulars und sollen über alle Marken hinweg identisch lesbar sein. Die Markenfarbe lebt anderswo (CTAs, Hover, Hervorhebungen).
|
||||
|
||||
Implementierung als CSS — niemals Emoji oder Bibliotheks-Icons.
|
||||
|
||||
---
|
||||
|
||||
## 6. Surface-Token (familienweit)
|
||||
|
||||
Auf allen Marken-Oberflächen identisch:
|
||||
|
||||
```css
|
||||
--color-bg-base: oklch(0.99 0.005 90); /* ~#FBFAF7 — warm off-white */
|
||||
--color-bg-surface: oklch(1.00 0 0); /* white für Karten */
|
||||
--color-bg-inverse: oklch(0.18 0.01 270); /* ~#1A1B22 — fast schwarz, leicht kühl */
|
||||
|
||||
--color-text-primary: oklch(0.20 0.01 270); /* ~#1F2128 */
|
||||
--color-text-secondary: oklch(0.45 0.01 270); /* ~#5C5F6B */
|
||||
--color-text-tertiary: oklch(0.60 0.01 270); /* ~#8B8E97 */
|
||||
|
||||
--color-border: oklch(0.90 0.005 90); /* ~#E2E0DA */
|
||||
--color-border-strong: oklch(0.80 0.005 90);
|
||||
```
|
||||
|
||||
Dark Mode invertiert die Surface- und Text-Token, behält aber die Markenfarben unverändert (sie sind in OKLCH so gewählt, dass sie in beiden Modi funktionieren).
|
||||
|
||||
---
|
||||
|
||||
## 7. Vendor- und Stack-Politik
|
||||
|
||||
Diese Sektion ist verbindlich für alle Repos, Marken-Oberflächen und produktiven Systeme unter dem digiFORMER-Dach. Sie hat die gleiche Verbindlichkeit wie die Farbsystem- und Typografie-Regeln — ein Verstoß ist kein Stil-Lapsus, sondern ein Bruch der Markenbotschaft.
|
||||
|
||||
### 7.1 Harte Regel
|
||||
|
||||
> **Jeder Vendor im kritischen Daten- oder Anwendungspfad muss eine Hauptniederlassung in DE, CH, AT oder EU haben UND in EU-Rechenzentren operieren. Keine Ausnahmen.**
|
||||
|
||||
Konsequenzen, die jedes Projekt-Briefing reflektieren muss:
|
||||
|
||||
- Personenbezogene Daten — auch IP-Adressen, User-Agents, Browser-Fingerprints — dürfen nicht an US-Anbieter übermittelt werden, auch nicht über deren EU-Töchter. Die CLOUD-Act-Exposition wird durch Tochter-Strukturen nicht aufgehoben.
|
||||
- Build-Pipelines, Deployment-Infrastruktur, CDN, DNS und Bot-Schutz folgen derselben Regel — was die Site ausliefert, den Build orchestriert oder Traffic terminiert, ist Teil des Pfades.
|
||||
- Schriftarten, Icons, JS-Libraries werden self-hosted ausgeliefert, niemals von US-CDNs eingebunden.
|
||||
- Wenn eine Funktion nur über einen US-Anbieter verfügbar wäre, fällt die Funktion weg oder wird selbst gebaut.
|
||||
- Open-Source-Komponenten von US-Entwicklern oder US-Firmen (z. B. React, Next.js, Tailwind, Source Serif 4) sind erlaubt, solange sie self-hosted ausgeliefert werden und keine Telemetrie an die Mutter-Org senden.
|
||||
|
||||
### 7.2 Whitelist — bestätigte aktive Vendors
|
||||
|
||||
| Vendor | Sitz | Rechenzentren | Funktion |
|
||||
|---|---|---|---|
|
||||
| Hetzner Online GmbH | DE (Gunzenhausen) | DE, FI | Hosting, VPS, DBs, Object Storage |
|
||||
| OVHcloud SA | FR (Roubaix) | EU-weit | Hosting-Alternative |
|
||||
| Brevo (Sendinblue SA) | FR (Paris) | FR | Transactional Mail |
|
||||
| Vivid Money S.A. | LU (Luxemburg) | LU, DE | Geschäftskonto, Payments |
|
||||
| Adyen N.V. (via Vivid) | NL (Amsterdam) | EU | Karten-Acquiring (indirekt über Vivid) |
|
||||
| Zitadel | CH (Zürich) | EU | Auth |
|
||||
| Coolify / Dokploy | OSS (selbst gehostet) | — | Deployment-Layer auf Hetzner/OVH |
|
||||
| Garage | OSS (selbst gehostet) | — | Object Storage (Multi-DC-Cluster) |
|
||||
| PostgreSQL | OSS | — | Datenbank |
|
||||
| PostgREST | OSS | — | API-Schicht |
|
||||
|
||||
### 7.3 Greylist — geprüft EU-konform, aber Rolle noch nicht final entschieden
|
||||
|
||||
Diese Vendors erfüllen die harte Regel und kommen für eine konkrete Anforderung in Frage. Bei jeder neuen Anforderung wird hier geprüft, bevor eine externe Suche gestartet wird.
|
||||
|
||||
| Vendor | Sitz | Mögliche Rolle |
|
||||
|---|---|---|
|
||||
| Friendly Captcha GmbH | DE (München) | Bot-Schutz (kommerziell) |
|
||||
| Altcha | OSS (kein Drittanbieter) | Bot-Schutz (self-hosted) |
|
||||
| mCaptcha | OSS (kein Drittanbieter) | Bot-Schutz (self-hosted) |
|
||||
| Pirsch Analytics GmbH | DE | Web-Analytics |
|
||||
| Plausible Insights OÜ | EE (Estland) | Web-Analytics |
|
||||
| Mollie B.V. | NL (Amsterdam) | Subscription-Billing für Phase 3 |
|
||||
| Bunny.net (BunnyWay d.o.o.) | SI (Slowenien) | CDN |
|
||||
| Mailgun EU / Postmark EU | EU-Region | Mail-Alternative falls Brevo nicht reicht |
|
||||
| INWX GmbH / united-domains | DE | Domain-Registrar |
|
||||
|
||||
**Aktuell offene Greylist-Entscheidungen:**
|
||||
- Bot-Schutz: Friendly Captcha (kommerziell, einfach zu integrieren) vs. Altcha (self-hosted, keine Drittpartei) vs. nur Honeypot + Rate-Limit (kein Captcha)
|
||||
- Analytics: Pirsch vs. Plausible vs. keiner (Privacy-Premium)
|
||||
- CDN: Bunny vs. Hetzner-direkt-Auslieferung (für statische Sites oft ausreichend)
|
||||
|
||||
### 7.4 Blacklist — ausdrücklich ausgeschlossen
|
||||
|
||||
Diese Anbieter sind nicht in den Stack aufzunehmen. Auch ihre EU-Töchter sind ausgeschlossen, weil die Mutter-Konzern-Struktur die CLOUD-Act-Exposition nicht aufhebt.
|
||||
|
||||
| Anbieter | Grund |
|
||||
|---|---|
|
||||
| Vercel Inc. | US-Headquarter |
|
||||
| Netlify Inc. | US-Headquarter |
|
||||
| Cloudflare Inc. | US-Headquarter — DNS, CDN, Pages, R2, Turnstile, alle Produkte |
|
||||
| Amazon Web Services | US-Headquarter |
|
||||
| Google Cloud Platform | US-Headquarter |
|
||||
| Microsoft Azure | US-Headquarter (außer Übergangs-Realität GitHub, siehe §7.5) |
|
||||
| Stripe Inc. | US-Headquarter |
|
||||
| Supabase Inc. | US-Headquarter |
|
||||
| Firebase / Firestore | Google-Mutter, US |
|
||||
| HubSpot Inc. | US-Headquarter |
|
||||
| Pipedrive | mehrheitlich US-übernommen |
|
||||
| Twilio / SendGrid | US-Headquarter |
|
||||
| Mailchimp / Intuit | US-Headquarter |
|
||||
| Google reCAPTCHA | US-Headquarter |
|
||||
| hCaptcha (Intuition Machines) | US-Mutterkonzern |
|
||||
| Google Analytics | US-Headquarter |
|
||||
| Google Fonts (als CDN) | US-Headquarter — Schriften self-hosten erlaubt |
|
||||
| Calendly | US-Headquarter (siehe §7.5 Übergang) |
|
||||
| Typeform | ursprünglich ES, mehrheitlich US-Investoren — Fall-by-Fall-Prüfung; Default ausgeschlossen |
|
||||
| Notion / Airtable | US-Headquarter |
|
||||
| Slack | Salesforce-Mutter, US |
|
||||
|
||||
### 7.5 Übergangs-Realitäten
|
||||
|
||||
Manche Vendors sind heute im Einsatz, weil sie historisch gewachsen sind oder noch keine geeignete EU-Alternative für die exakte Funktion existiert. Diese Übergänge sind explizit dokumentiert und mit einem Auflösungs-Pfad versehen. Sie tauchen nicht in der Whitelist auf und sind kein Präzedenzfall für neue Entscheidungen.
|
||||
|
||||
| Übergang | Heute | Ziel | Auflösung bis |
|
||||
|---|---|---|---|
|
||||
| Calendly | Termin-Buchung über externen Link (kein Embed) | SlimCore-eigenes Termin-Modul | Phase 2 SlimCore-Roadmap |
|
||||
| GitHub | Code-Hosting für öffentliche / leichtgewichtige Repos | Forgejo / Gitea selbst gehostet auf Hetzner | offen, vor erstem Production-Secret-Rollout |
|
||||
| GitHub Actions | CI für die Marketing-Site und SlimCore-App | Forgejo Actions + Self-hosted-Runner auf Hetzner | parallel zur GitHub-Migration |
|
||||
|
||||
Wenn weitere Übergänge entdeckt werden, gehören sie hierher — nicht stillschweigend in den Stack.
|
||||
|
||||
### 7.6 Anwendung in Briefs
|
||||
|
||||
Jedes Repo-CLAUDE.md, jede neue Marken-Site, jedes neue Produkt-Briefing referenziert §7.1–7.4 als verbindlich. Bei jeder Default-Empfehlung („nimm Vercel", „nimm Stripe") muss der Brief diese gegen die Listen prüfen, bevor sie übernommen wird. Bei Konflikt zwischen einer einzelnen Empfehlung und dieser Politik gewinnt diese Politik.
|
||||
|
||||
---
|
||||
|
||||
## 8. Implementierung
|
||||
|
||||
### 8.1 Heutige Lösung (Phase 1)
|
||||
|
||||
Jedes Repo definiert die benötigten Marken-Token in seinem eigenen `global.css` als Tailwind-v4-`@theme`-Block. Werte werden aus diesem Dokument kopiert.
|
||||
|
||||
### 8.2 Mittelfristig (Phase 2)
|
||||
|
||||
Geplant: ein npm-Paket `@digiformer/design-tokens`, das alle Marken-Token, Surface-Token, Typografie-Variablen und Status-Glyph-CSS exportiert. Jede Marken-Site importiert nur die für sie relevanten Marken-Token, plus alle familienweiten Token.
|
||||
|
||||
Repo-Struktur (Vorschlag):
|
||||
|
||||
```
|
||||
@digiformer/design-tokens/
|
||||
├── package.json
|
||||
├── README.md
|
||||
├── src/
|
||||
│ ├── colors.css ← alle Marken + Surfaces als CSS-Variables
|
||||
│ ├── typography.css ← Font-Stacks + Skalen
|
||||
│ ├── glyphs.css ← Status-Dot-Klassen
|
||||
│ └── tokens.json ← maschinenlesbar für Tooling
|
||||
└── dist/ ← gebaut
|
||||
```
|
||||
|
||||
### 8.3 Langfristig (Phase 3, Vision)
|
||||
|
||||
Token-Studio-Anbindung an Figma, automatische Sync zwischen Design-Files und Code.
|
||||
|
||||
---
|
||||
|
||||
## 9. Wann diese Datei aktualisiert wird
|
||||
|
||||
- Bei jeder Belegung eines Reserve-Slots durch ein neues Produkt — Eintrag von §3.3 nach §3.2 verschieben, Rolle dokumentieren
|
||||
- Bei jeder Re-Tonung einer aktiven Markenfarbe — alte Werte als Kommentar erhalten, Migration-Datum notieren
|
||||
- Bei jeder Erweiterung der Reserve (z. B. zweite Acht-Slot-Schicht für einen zweiten Saturationslevel) — ist heute nicht geplant, kommt nur falls die ersten 8 Slots belegt sind
|
||||
|
||||
---
|
||||
|
||||
## 10. Referenzen
|
||||
|
||||
- digiFORMER-Site (Mutterbrand-Tonalität): https://digiformer.lovable.app
|
||||
- SlimCore-Marketing-Site: in Entwicklung, Repo `slimcore-marketing`
|
||||
- trendscout-Marketing-Site: noch nicht begonnen
|
||||
- SlimSafe-Marketing-Site: noch nicht begonnen
|
||||
|
||||
---
|
||||
|
||||
**Ende des Brand-System-Dokuments.** Bei Konflikten zwischen diesem Dokument und einer einzelnen Repo-Konfiguration gewinnt dieses Dokument.
|
||||
407
docs/produktbeschreibung.md
Normal file
407
docs/produktbeschreibung.md
Normal file
|
|
@ -0,0 +1,407 @@
|
|||
---
|
||||
title: "SlimCore — Produktbeschreibung & Marketing-Briefing"
|
||||
subtitle: "Stand 2026-05-04 · Autor Pascal Oelmann"
|
||||
---
|
||||
|
||||
# SlimCore — Produktbeschreibung & Marketing-Briefing
|
||||
|
||||
**Stand:** 2026-05-04
|
||||
**Adressaten:** Marketing-Team, Webseiten-Texter, Vertriebsvorbereitung, Tester-Briefing
|
||||
**Autor:** Pascal Oelmann
|
||||
**Zweck:** Grundlage für Teambesprechung und Single Source of Truth für Marketing-Inhalte.
|
||||
|
||||
> **SlimCore ist die schlanke, modulare Geschäftssoftware für Solo-Selbstständige und kleine Teams — souverän in Europa gehostet, ohne Abhängigkeit von US-Konzernen, ohne Vendor-Lock-in. Schlank starten. Grenzenlos wachsen.**
|
||||
|
||||
---
|
||||
|
||||
## Inhaltsverzeichnis
|
||||
|
||||
1. Kurzfassung (Elevator Pitch)
|
||||
2. Zielgruppe
|
||||
3. Positionierung & Abgrenzung
|
||||
4. Das große Versprechen: Digitale Souveränität
|
||||
5. Architektur-Prinzipien
|
||||
6. Modul-Landschaft
|
||||
7. Plattform-Highlights
|
||||
8. Was SlimCore bewusst NICHT tut
|
||||
9. Geschäftsmodell
|
||||
10. Briefing für Tester-Akquise
|
||||
11. Sprache, Tonalität, Wording
|
||||
12. Roadmap-Zusammenfassung
|
||||
13. Schnell-Argumentarium
|
||||
|
||||
---
|
||||
|
||||
## 1. Kurzfassung (Elevator Pitch)
|
||||
|
||||
**Schlank starten. Grenzenlos wachsen.**
|
||||
|
||||
SlimCore vereint die Bereiche, die kleine und mittlere Unternehmen wirklich täglich brauchen — Kundenverwaltung, Belegfluss, Aufgaben und Workflows, Lager und Versand, Team-Kommunikation — auf einer einzigen, modular aufgebauten Plattform.
|
||||
|
||||
Solo-Selbstständige und Mikroteams aktivieren am Anfang nur, was sie heute brauchen — meistens CRM, Belege und Aufgaben. Wenn aus zwei Personen drei werden, dann zehn, dann fünfzehn, schalten sie weitere Module zu, ohne die Software zu wechseln. Bestehende Werkzeuge (Buchhaltung, Shop, Telefonie) bleiben — SlimCore orchestriert, statt zu vereinnahmen.
|
||||
|
||||
Statt Mitarbeitende durch ein Mammut-ERP zu schleifen, bleibt SlimCore dort einfach, wo Einfachheit reicht — und wird genau dort tief, wo Tiefe nötig ist.
|
||||
|
||||
---
|
||||
|
||||
## 2. Zielgruppe
|
||||
|
||||
### 2.1 Primärgruppe — Solo-Selbstständige und kleine Teams (1–10 Personen)
|
||||
|
||||
Beratungen und Coaches, Handwerksbetriebe, kleine Agenturen, freiberufliche Architekt:innen, Photovoltaik-Installateur:innen, Hebammen mit Praxis, Heilpraktiker:innen, kleine Manufakturen, IT-Dienstleister:innen, Texter:innen und Übersetzer:innen, Steuerkanzleien bis 5 MA.
|
||||
|
||||
Was sie verbindet: Sie haben echte Geschäftsprozesse, aber kein Personal für IT-Verwaltung. Sie brauchen Software, die am ersten Tag funktioniert und nicht vier Wochen Einrichtung braucht.
|
||||
|
||||
### 2.2 Sekundärgruppe — Wachsende KMU bis ~30 Mitarbeitende
|
||||
|
||||
Unternehmen, die heute klein sind und in zwei bis drei Jahren mit derselben Software weiterarbeiten wollen. Das größte Argument: nicht zweimal migrieren müssen. Wer heute mit zwei Personen ein CRM einführt und in drei Jahren mit fünfzehn da ist, soll nichts wechseln müssen.
|
||||
|
||||
### 2.3 Tertiärgruppe — eCommerce-Händler mit B2C/B2B-Mix
|
||||
|
||||
Online-Shop-Betreiber:innen, Multichannel-Händler:innen, Hersteller mit Direktvertrieb. Hier kommen die Module Lager, Versand und Verkaufskanäle voll zum Tragen. Wichtige Zielgruppe, aber nicht die erste, an die SlimCore sich richtet.
|
||||
|
||||
### 2.4 Typische Schmerzpunkte
|
||||
|
||||
- Sie verwalten Kunden in Excel, Termine im Kalender, Aufgaben in Notion oder Trello, Belege in lexoffice und Kommunikation im Mail-Postfach — und keiner der Stränge spricht mit dem anderen
|
||||
- Tools wie HubSpot oder Pipedrive sind in der Tiefe Overkill und im Preis schwer zu rechtfertigen, wenn Sie noch zu zweit sind
|
||||
- US-Software wie HubSpot, Pipedrive oder Salesforce ist DSGVO- und souveränitätstechnisch heikel
|
||||
- Sie wissen nicht, ob die Software, die heute reicht, in drei Jahren noch passt — und Migrationen kosten immer mehr als geplant
|
||||
- Excel-Templates aus dem Internet sind kostenlos, halten aber nicht durch, wenn echte Prozesse entstehen
|
||||
- Bestehende Lösungen erzwingen häufig den Wechsel des gewohnten Steuerberater-Tools oder Lieblings-Shops
|
||||
- Custom-Entwicklungen sind teuer, schwer zu warten und binden ans Entwicklungsstudio
|
||||
|
||||
**SlimCore-Versprechen:** Best Practices der großen Tools, aber bedienbar wie ein modernes SaaS — und erweiterbar, ohne in eine Sackgasse zu führen.
|
||||
|
||||
---
|
||||
|
||||
## 3. Positionierung & Abgrenzung
|
||||
|
||||
| SlimCore ist… | SlimCore ist NICHT… |
|
||||
|---|---|
|
||||
| Multi-Tenant-SaaS für Geschäftsprozesse | Buchhaltung — die bleibt extern (DATEV, sevDesk, Lexware, lexoffice) |
|
||||
| Plattform für Kundenkommunikation, Belege, Aufgaben, Lager, Workflow | Online-Shop-Ersatz — Shop bleibt WooCommerce/Shopify |
|
||||
| Skaliert von 1 Person bis ~50 | Enterprise-Plattform mit Mindestvolumen |
|
||||
| Modular und konfigurierbar pro Mandant | Off-the-shelf-Software „one size fits all" |
|
||||
| Self-hosted in Europa, unter eigener Kontrolle | Eine US-Cloud mit europäischen Datacentern |
|
||||
| Hybrid: Self-Service-SaaS + Setup-Service auf Wunsch | Reines Beratungsprodukt mit Software-Beigabe |
|
||||
|
||||
**Wichtig fürs Marketing:** SlimCore positioniert sich bewusst als Integration statt Ersatz. Belege gehen an die Buchhaltung. Bestellungen kommen aus dem Shop. Kommunikation läuft über das vorhandene MS365. SlimCore orchestriert — es vereinnahmt nicht.
|
||||
|
||||
---
|
||||
|
||||
## 4. Das große Versprechen: Digitale Souveränität
|
||||
|
||||
**Das ist das wichtigste Differenzierungsmerkmal und sollte im Marketing prominent platziert werden.**
|
||||
|
||||
### 4.1 Warum das jetzt zählt
|
||||
|
||||
Deutsche und europäische Unternehmen werden zunehmend sensibel für die Frage, wo ihre Daten liegen, wer sie einsehen kann und wer im Ernstfall den Hahn zudrehen kann. CLOUD Act, Schrems II, geopolitische Unsicherheit und Preissprünge bei US-SaaS-Anbietern haben gezeigt: Ein Produkt, das auf einer fremden Plattform sitzt, ist nur so souverän wie diese Plattform.
|
||||
|
||||
Für Solo-Selbstständige und kleine Teams kommt ein zweiter Effekt dazu: US-Anbieter ändern Pläne, Limits und Lizenzbedingungen oft kurzfristig. Wer als Einzelperson auf einem €15-Pipedrive-Plan sitzt, der nächstes Jahr €45 kostet oder Kernfunktionen aussortiert, hat keine Verhandlungsposition.
|
||||
|
||||
### 4.2 Wie SlimCore das löst
|
||||
|
||||
**Hosting:** SlimCore läuft auf Hetzner-Servern in Falkenstein und Nürnberg — deutsche Rechenzentren, deutsches Recht, DSGVO-konform per Default.
|
||||
|
||||
**Stack:** Ausschließlich Open-Source-Komponenten (PostgreSQL, PostgREST, Traefik, Docker, React). Keine proprietären Bausteine.
|
||||
|
||||
**Keine US-Abhängigkeiten in der Wertschöpfungskette:**
|
||||
|
||||
- **Datenbank:** PostgreSQL — Open Source, Community-getragen
|
||||
- **Authentifizierung:** Zitadel (Schweizer Open Source), in CH gehostet — aktiv, kein Migrations-Schritt mehr offen.
|
||||
- **E-Mail-Versand:** Brevo (französischer Anbieter)
|
||||
- **Adressvalidierung & Karten:** über austauschbare Adapter — nicht hartverdrahtet auf Google
|
||||
- **Object Storage:** Garage (selbst gehostet, Multi-DC-Cluster) — kein S3, kein AWS
|
||||
|
||||
**Kein Vendor-Lock-in im Kunden-Ergebnis:**
|
||||
|
||||
- Daten exportierbar in offenen Formaten (CSV, JSON, ZUGFeRD-XML)
|
||||
- Belege und Rechnungen in DATEV-CSV, sevDesk- und Lexware-API-Format
|
||||
- Kein proprietäres Datenmodell, das nur SlimCore lesen kann
|
||||
- Keine künstlichen API-Limits, die Kunden zwingen, im Produkt zu bleiben
|
||||
|
||||
**Optionaler Compliance-Layer (in Vorbereitung):**
|
||||
|
||||
- **Egress-Audit:** Mandanten können nachvollziehen, welche externen Dienste kontaktiert wurden
|
||||
- **Egress-Proxy:** Mandanten können einschränken, mit welchen Drittsystemen ihre Daten kommunizieren dürfen
|
||||
|
||||
### 4.3 Marketing-Botschaften
|
||||
|
||||
> „Ihre Geschäftssoftware. In Deutschland. Von Ihnen kontrolliert."
|
||||
|
||||
> „Open Source, EU-gehostet, austauschbar. SlimCore ist die Geschäftssoftware, die Sie nicht eingeschlossen lässt."
|
||||
|
||||
> „Kein CLOUD Act, kein Schrems-Risiko, keine US-Konzern-Lizenzbedingungen. Ein modernes Tool — endlich auf Ihrer Seite."
|
||||
|
||||
---
|
||||
|
||||
## 5. Architektur-Prinzipien (für Marketing übersetzbar)
|
||||
|
||||
| Technisches Prinzip | Marketing-Übersetzung |
|
||||
|---|---|
|
||||
| Modular: jedes Modul einzeln aktivierbar | „Sie zahlen nur für das, was Sie nutzen — und schalten Module zu, wenn Sie wachsen." |
|
||||
| Skaliert von 1 bis 50 ohne Migration | „Heute starten Sie mit drei Modulen für sich allein. In drei Jahren nutzt Ihr Team zehn. Es bleibt dieselbe Software." |
|
||||
| Multi-Tenant mit Row-Level-Security | „Strikte Mandantentrennung: Ihre Daten sind technisch von anderen Kunden isoliert." |
|
||||
| Generisch, nicht firmenspezifisch | „SlimCore passt sich an Ihren Prozess an — nicht umgekehrt." |
|
||||
| Konfigurierbar pro Mandant | „Belegfluss, Pipelines, Custom Fields — alles ohne Programmierung anpassbar." |
|
||||
| Integration statt Ersatz | „SlimCore ersetzt nicht, was funktioniert. Es verbindet, was zusammengehört." |
|
||||
| Workflow-Engine mit Event-Bus | „Wiederkehrende Abläufe automatisieren Sie selbst — vom Onboarding bis zum Mahnwesen." |
|
||||
| Mobile-First-Sync | „Auch unterwegs: alles dabei, auch ohne Empfang." |
|
||||
|
||||
---
|
||||
|
||||
## 6. Modul-Landschaft
|
||||
|
||||
SlimCore ist in vier inhaltliche Säulen plus eine unsichtbare Plattform-Schicht organisiert.
|
||||
|
||||
**Status-Glyphen:** ● Verfügbar · ◐ In Entwicklung · ○ Geplant · ◌ Vision
|
||||
|
||||
> **Einstiegs-Hinweis für Marketing:** Solo-Selbstständige und kleine Teams starten typischerweise mit den Modulen aus den Säulen 01 und 03 (Kunden & Kommunikation, Belege & Finanzen) — und Aufgaben aus Säule 04. Säule 02 (Handel & Logistik) wird erst relevant, wenn ein Online-Shop oder physischer Warenfluss dazukommt. Die Reihenfolge der Säulen sagt nichts über Wichtigkeit, sondern über Domäne.
|
||||
|
||||
### 6.1 Kunden & Kommunikation (Säule 01)
|
||||
|
||||
| Modul | Beschreibung | Status |
|
||||
|---|---|---|
|
||||
| CRM | Zentrale Kontaktverwaltung mit Firmen/Personen, Interaktions-Timeline, Vertriebs-Pipeline (Kanban), Tags, Custom Fields, Massenaktionen. | ● Verfügbar |
|
||||
| Team-E-Mail | Geteilte Postfächer über MS365 angebunden. Drei-Spalten-UI, automatische CRM-Zuordnung, Inbox-Übersicht. | ◐ In Entwicklung |
|
||||
| Helpdesk | Aus E-Mails werden Tickets. Zuweisung, Status-Workflow, SLA-Tracking. Kein Portal-Konto nötig. | ○ Geplant |
|
||||
| Telefonie | Yeastar P520-Anbindung. Echtzeit-Erfassung, CRM-Zuordnung, verpasste Anrufe als Widget. | ○ Geplant |
|
||||
| WhatsApp | WhatsApp Business API als Eingangskanal. Automatisches CRM-Matching, Timeline-Eintrag. | ○ Geplant |
|
||||
|
||||
**Designprinzip:** E-Mail, Telefon und WhatsApp folgen dem gleichen Muster — eigene Inbox, automatisches CRM-Matching, Timeline-Eintrag, Dashboard-Widget.
|
||||
|
||||
### 6.2 Handel & Logistik (Säule 02)
|
||||
|
||||
| Modul | Beschreibung | Status |
|
||||
|---|---|---|
|
||||
| Artikel | Stammdaten mit Varianten, Stücklisten/Bundles, Chargen-/MHD-/Seriennummern, Preislisten, EU-LMIV-Felder. | ◐ In Entwicklung |
|
||||
| Lager | Lagerorte, Bestandsführung, Wareneingänge, FIFO/FEFO, MHD-Tracking, Seriennummern, mehrere Lager. | ● Verfügbar |
|
||||
| Bestellungen | Alle Kanäle konsolidiert. Positionsverwaltung, Status-Workflow, Bezahlstatus-Tracking. | ● Verfügbar |
|
||||
| Verkaufskanäle | WooCommerce bidirektional, Amazon SP-API kurz davor, Shopify/Kaufland/Etsy später. | ◐ In Entwicklung |
|
||||
| Versand | Multi-Carrier: DHL zuerst, DPD/GLS/Hermes folgen. Label, Tracking, Shiptastic-Integration. | ◐ In Entwicklung |
|
||||
| Einkauf | Lieferanten als CRM-Kontakte, Einkaufsbestellungen, Wareneingang mit Bestandsbuchung. | ○ Geplant |
|
||||
|
||||
### 6.3 Belege & Finanzen (Säule 03)
|
||||
|
||||
| Modul | Beschreibung | Status |
|
||||
|---|---|---|
|
||||
| Belege | Konfigurierbarer Belegfluss: Angebot → AB → Lieferschein → Rechnung → Gutschrift → Mahnung. PDF-Erzeugung, Vorlagen pro Mandant. | ● Verfügbar |
|
||||
| Rechnungen | Aus Bestellungen, Zeiterfassung oder manuell. ZUGFeRD 2.0 und XRechnung. | ◐ In Entwicklung |
|
||||
| Zahlungen | Offene-Posten, Zahlungseingänge, Teilzahlungen, vierstufiges Mahnwesen, Liquiditäts-Widget. | ● Verfügbar |
|
||||
| BuHa-Export | DATEV-CSV produktiv, sevDesk-API, lexoffice-API und Lexware-API in Vorbereitung. | ● Verfügbar |
|
||||
|
||||
**Bewusste Abgrenzung:** SlimCore macht keine Buchhaltung, keine Kontierung, kein Hauptbuch. Der Belegfluss endet beim erzeugten Beleg. Mandanten behalten ihren Steuerberater und ihre gewohnte Software.
|
||||
|
||||
### 6.4 Team & Organisation (Säule 04)
|
||||
|
||||
| Modul | Beschreibung | Status |
|
||||
|---|---|---|
|
||||
| Aufgaben | Kanban oder Liste. Zuweisung, Fälligkeiten, Kommentare, Verknüpfung mit Kontakten/Bestellungen/Belegen. | ◐ In Entwicklung |
|
||||
| Projekte | Klammer um Aufgaben mit Meilensteinen und Budget-Tracking. | ○ Geplant |
|
||||
| Zeiterfassung | Stempeluhr + Projektzeiten. Erfasste Zeiten werden auf Wunsch zu Rechnungspositionen. | ○ Geplant |
|
||||
| Personal | Stammdaten, Arbeitsverträge, Urlaubsanträge mit Genehmigungs-Workflow, Abwesenheitskalender. | ○ Geplant |
|
||||
|
||||
### 6.5 Plattform-Schicht (unter der Haube)
|
||||
|
||||
| Komponente | Beschreibung | Status |
|
||||
|---|---|---|
|
||||
| Workflow-Engine | Visueller Regel-Builder, Template-Engine, 10+ Schritttypen, 4 Zuweisungsstrategien. | ● Verfügbar |
|
||||
| Pipeline | Kanban-Engine, im CRM produktiv, perspektivisch polymorph. | ● Verfügbar / ◌ Vision |
|
||||
| Dokumente | Zentrale Dateiablage, Versionierung, Berechtigungen, Volltextsuche. | ○ Geplant |
|
||||
| Dashboard | Modulspezifische KPI-Widgets, pro Benutzer konfigurierbar. | ◐ In Entwicklung |
|
||||
| Einstellungen | Benutzer-, Rollen-, Berechtigungsverwaltung (3 Stufen). Modul-Aktivierung pro Mandant. | ◐ In Entwicklung |
|
||||
| Feedback | Feature-Wünsche und Bug-Reports im Produkt. KI-Triage + Spec-Generierung. | ● Verfügbar |
|
||||
| Brands | Mehrmarken-Fähigkeit: eigene Listings, Preise, Belegvorlagen pro Marke. | ● Verfügbar |
|
||||
| Notizen | Kontextuelle Notizen + Audio-Memos mit serverseitiger Transkription (Whisper). | ◐ In Entwicklung |
|
||||
|
||||
---
|
||||
|
||||
## 7. Plattform-Highlights
|
||||
|
||||
### 7.1 Mobile-App (iOS zuerst, Android folgt)
|
||||
|
||||
Native Mobile-App auf React-Native-Basis, offline-first. iOS zuerst, Android 4–6 Wochen später. MVP-Module: CRM, Aufgaben, Notizen mit Audio-Memos, Pipeline, Lager-light, Artikel-lesen, Posteingang-lesen.
|
||||
|
||||
**Differenzierungs-Punkte:**
|
||||
|
||||
- **Echte Offline-Fähigkeit** — Daten lokal verschlüsselt, Sync bei nächster Verbindung.
|
||||
- **Diktiergerät-Ersatz** — Audio-Memo aufnehmen, Server transkribiert, Notiz hängt am Kontakt. Besonders wertvoll für Solo-Selbstständige im Außendienst.
|
||||
- **Sub-Sekunden-Logout** — Bei Geräteverlust: Zugriff binnen Sekunden gesperrt.
|
||||
- **Push-Benachrichtigungen direkt über Apple/Google** — kein Drittanbieter.
|
||||
|
||||
### 7.2 Workflow-Automatisierung — eingebaut, nicht aufgeschraubt
|
||||
|
||||
- Keine zusätzliche Integration, keine zweite Login-Wand, kein zweiter Anbieter im Datenfluss.
|
||||
- Workflows greifen direkt auf SlimCore-Daten zu — kein Umweg über öffentliche APIs.
|
||||
- Mandanten-Templates sind teilbar — eine Best-Practice-Bibliothek wird Teil des Marktplatz-Konzepts.
|
||||
|
||||
### 7.3 Just-Ship: KI-gestützte Selbstweiterentwicklung (Vision)
|
||||
|
||||
> **Dies ist eine Vision, kein heute verfügbares Feature.** Marketing kann sie als Roadmap-Highlight einsetzen — aber nicht als Verkaufsversprechen.
|
||||
|
||||
**Idee:** Ein Loop aus Feature-Wunsch → KI-Triage → Spec → Staging-Deployment → Review → Produktion.
|
||||
|
||||
**Warum eigenständig:** Der Loop ist Produkt-IP, kein Infrastruktur-Beiwerk. Ein Vendor-Lock-in genau an dieser Stelle würde dem Souveränitätsversprechen widersprechen.
|
||||
|
||||
### 7.4 Custom-Functions pro Mandant (Vision)
|
||||
|
||||
Mandanten beschreiben spezielle Anforderungen, KI generiert die passende Funktion, sie läuft in einer mandant-eigenen Sandbox. Langfristige Antwort auf „das hat keine Standard-Software".
|
||||
|
||||
### 7.5 Mehr-Region-Hochverfügbarkeit (geplant)
|
||||
|
||||
Patroni-basiertes synchrones Setup, Standby in Nürnberg, automatischer Failover.
|
||||
|
||||
### 7.6 Public API & Marketplace (geplant)
|
||||
|
||||
Öffentliche API mit Webhooks, Marktplatz für Workflow-Templates und Branchen-Erweiterungen.
|
||||
|
||||
---
|
||||
|
||||
## 8. Was SlimCore bewusst NICHT tut
|
||||
|
||||
Diese Abgrenzungen sind wichtig für die Kundenansprache, weil sie Erwartungen sortieren und Vertrauen schaffen:
|
||||
|
||||
- **Keine eigene Buchhaltung.** Steuerberater und Buchhaltungssoftware bleiben.
|
||||
- **Kein Online-Shop.** Shop-Systeme bleiben Shop-Systeme.
|
||||
- **Kein E-Mail-Server.** Microsoft 365 oder vergleichbar bleibt.
|
||||
- **Kein vollwertiges HR.** Lohnbuchhaltung gehört woanders hin.
|
||||
- **Keine Marketing-Automation à la HubSpot.** Pipeline und Workflow ja, Lead-Scoring auf 14 Achsen nein.
|
||||
- **Kein Customer Success Tool.** Tickets ja, Health-Score-Algorithmen nein.
|
||||
|
||||
Diese Schärfe ist das Gegenteil von „One-Stop-Shop für alles" — und genau der Grund, warum SlimCore funktioniert, wo Odoo überfordert.
|
||||
|
||||
---
|
||||
|
||||
## 9. Geschäftsmodell
|
||||
|
||||
**Hybrid:**
|
||||
|
||||
- Self-Service-SaaS für Standard-Funktionen, monatliche Abo-Stufen.
|
||||
- Setup-Service auf Wunsch: Einrichtung, Datenmigration, Schulung.
|
||||
- Multi-Tenant auf gemeinsamer Infrastruktur. Dedizierte Instanzen auf Anfrage.
|
||||
|
||||
### 9.1 Preisstaffeln (indikativ, noch nicht final)
|
||||
|
||||
| Tier | Speicher | Module | Zielgruppe |
|
||||
|---|---|---|---|
|
||||
| Solo | ca. 500 MB | Basis (CRM, Belege, Aufgaben) | Solo-Selbstständige |
|
||||
| Tier 1 | ca. 5 GB | Basis + Workflow + Mobile | kleine Teams (2–10) |
|
||||
| Tier 2 | ca. 25 GB | mit Versand, Verkaufskanäle, Team-E-Mail | wachsende KMU + eCommerce |
|
||||
| Tier 3 | ca. 100 GB | Alle Module, Priority-Support | etablierte KMU bis ~50 MA |
|
||||
|
||||
Die Preispunkte werden vor Tester-Phase 2 final festgelegt.
|
||||
|
||||
---
|
||||
|
||||
## 10. Briefing für Tester-Akquise
|
||||
|
||||
> Dieser Abschnitt kann als eigenständiges Dokument extrahiert und an Tester-Kandidaten versendet werden.
|
||||
|
||||
### 10.1 Wer wird gesucht (Phase 1)
|
||||
|
||||
Wir suchen ein breites Spektrum an Solo-Selbstständigen und kleinen Teams — nicht zu spezifisch, weil wir verschiedene Nutzungsmuster sehen wollen:
|
||||
|
||||
- **Inhaber:innen, die heute ein Tool-Sammelsurium nutzen** und es ordnen wollen
|
||||
- **Solo-Selbstständige und Mikroteams** (1–5 Personen) aus Beratung, Handwerk, Dienstleistung, Manufaktur
|
||||
- **Wachsende KMU bis ~30 Mitarbeitende**, die heute klein starten und in 3 Jahren noch dieselbe Software nutzen wollen
|
||||
- **Online-Händler mit WooCommerce oder Shopify** — willkommen, aber kein Muss
|
||||
- **Unternehmen, die heute eine US-Cloud nutzen und unzufrieden sind** — wegen Preisen, Limits oder Souveränitäts-Bedenken
|
||||
|
||||
### 10.2 Was Tester bekommen
|
||||
|
||||
- Eigene SlimCore-Instanz (Mandant) auf Staging oder Produktion
|
||||
- Persönlicher Onboarding-Termin (1–2 h) mit dem Produktverantwortlichen
|
||||
- Direkter Draht ins Entwicklungsteam über das eingebaute Feedback-Modul
|
||||
- Mehrere Monate vergünstigter oder kostenfreier Nutzung
|
||||
|
||||
### 10.3 Was Tester geben
|
||||
|
||||
- 1–2 Stunden pro Woche aktiv mit dem Produkt arbeiten
|
||||
- Bereitschaft, echte Daten in geschützter Testumgebung zu nutzen
|
||||
- Strukturiertes Feedback über das eingebaute Feedback-Modul
|
||||
- Erfahrungs-Gespräch nach 4 und nach 12 Wochen
|
||||
- Toleranz für Bugs, Zwischenstände und Updates
|
||||
|
||||
### 10.4 Worauf Tester sich einstellen sollten
|
||||
|
||||
- SlimCore ist kein fertiges Produkt — reife Plattform mit klarer Roadmap.
|
||||
- Manche Module sind in Tester-Phase 1 noch nicht verfügbar.
|
||||
- Mobile-App kommt im Verlauf der Tester-Phase.
|
||||
- Tester-Feedback verändert die Roadmap. Das ist gewollt.
|
||||
|
||||
### 10.5 Botschaft an Tester
|
||||
|
||||
> „Sie kennen die Lücken in Ihrer aktuellen Software besser als jeder Berater. Helfen Sie uns, eine Geschäftssoftware zu bauen, die in Deutschland gehört, gehostet und verstanden wird — und die nicht morgen einem US-Konzern gehört, weil eine Übernahme passiert ist."
|
||||
|
||||
---
|
||||
|
||||
## 11. Sprache, Tonalität, Wording
|
||||
|
||||
### 11.1 Marken-Tonalität
|
||||
|
||||
- **Klar, nicht großspurig.** Keine Buzzwords ohne Substanz.
|
||||
- **Selbstbewusst, nicht arrogant.** Ein gutes Werkzeug, kein Heilsbringer.
|
||||
- **Pragmatisch, nicht idealistisch.** Souveränität ist ein Nutzen, kein moralisches Argument.
|
||||
- **Deutsch zuerst.** Englische Texte folgen, aber die Marke spricht primär Deutsch.
|
||||
- **Direkt, aber nicht plump.** Die neue Primärgruppe (Solos und kleine Teams) liest schneller als Beratungs-Entscheider:innen — kürzere Sätze sind erlaubt, aber kein Marketing-Slang.
|
||||
|
||||
### 11.2 Wording-Regeln
|
||||
|
||||
- „Mandant" statt „Tenant" oder „Workspace"
|
||||
- „Belegfluss" statt „Document flow"
|
||||
- Umlaute schreiben. Immer ä/ö/ü/ß, nie ae/oe/ue.
|
||||
- „KMU" für die Zielgruppe
|
||||
- „Solo-Selbstständige" und „kleine Teams" — bevorzugte Bezeichnungen für Primärgruppe
|
||||
- „Setup-Service" statt „Onboarding-Paket"
|
||||
- „DSGVO-konform" ist Mindestanforderung, kein Verkaufsargument für sich.
|
||||
- „SlimCore" — niemals „Cockpit" oder „digiFORMER Cockpit"
|
||||
|
||||
### 11.3 Was nicht passieren darf
|
||||
|
||||
- Keine US-Marketing-Klischees (kein „supercharge", „rocket", „game-changer")
|
||||
- Keine Versprechen für Vision-Features — Vision benennen, nicht als verfügbar verkaufen
|
||||
- Keine echten Kundennamen ohne Freigabe
|
||||
- Keine Vergleiche per Markenname ohne juristische Vorprüfung
|
||||
- Keine Annahmen über die technische Affinität der Zielgruppe — Solo-Selbstständige sind nicht zwingend Tech-Skeptiker, aber auch nicht zwingend Power-User. Texte erklären statt voraussetzen.
|
||||
|
||||
---
|
||||
|
||||
## 12. Roadmap-Zusammenfassung
|
||||
|
||||
| Phase | Label | Inhalt |
|
||||
|---|---|---|
|
||||
| **Heute** | Verfügbar | CRM, Belege, Lager, Bestellungen, Workflow, Zahlungen, DATEV-Export, WooCommerce |
|
||||
| **Q3/Q4 2026** | Kurzfristig | Team-E-Mail, Aufgaben, Versand (DHL), ZUGFeRD, Mobile-App (iOS), lexoffice-Export |
|
||||
| **2027** | Im Aufbau | Helpdesk, Telefonie, WhatsApp, Projekte, Zeiterfassung, Personal, Amazon, Android |
|
||||
| **Vision** | Wohin wir wollen | Just-Ship-Loop, Custom-Functions, Marktplatz, Multi-Region-HA |
|
||||
|
||||
---
|
||||
|
||||
## 13. Schnell-Argumentarium
|
||||
|
||||
Ein-Satz-Antworten auf die häufigsten Einwände:
|
||||
|
||||
**„Wir sind nur zwei. Lohnt sich das überhaupt?"**
|
||||
> „Genau für Sie ist SlimCore gebaut. Sie aktivieren am Anfang drei Module — CRM, Belege, Aufgaben — und zahlen entsprechend. Wenn Sie wachsen, wachsen die Module mit. Sie kaufen heute nicht für übermorgen ein."
|
||||
|
||||
**„Was ist mit drei Jahren? Müssen wir dann wechseln?"**
|
||||
> „Nein. SlimCore skaliert von einer Person bis ~50 Mitarbeitende. Dieselbe Software, mehr aktivierte Module. Wer heute mit drei startet und in drei Jahren mit fünfzehn dasteht, behält seine Daten, seine Workflows und seine Berichte."
|
||||
|
||||
**„Wir nutzen schon HubSpot."**
|
||||
> „Dann kennen Sie den Schmerz, wenn die Pipeline funktioniert, aber Belege und Lager woanders liegen. SlimCore schließt diese Lücke — ohne dass Sie HubSpot ablösen müssen."
|
||||
|
||||
**„Wir haben Odoo getestet, war zu komplex."**
|
||||
> „Genau deshalb gibt es uns. SlimCore macht 80 Prozent von Odoo, ohne den Implementierungsoverhead."
|
||||
|
||||
**„Was passiert mit unseren Daten?"**
|
||||
> „Vollständiger Export jederzeit. Schema offen, Open-Source-Stack, PostgreSQL-Datenbank, die jeder Hosting-Anbieter weiterführen kann."
|
||||
|
||||
**„Warum nicht Dynamics oder Salesforce?"**
|
||||
> „Beide exzellent. Beide US-Konzerne mit allem, was das politisch und vertraglich bedeutet. Für viele unserer Kunden ist das genau der Grund zu wechseln."
|
||||
|
||||
**„Wann ist es fertig?"**
|
||||
> „SaaS wird nie fertig. Wir versprechen, dass die produktiven Module produktiv bleiben — und die neuen in einer Reihenfolge kommen, die Sinn ergibt."
|
||||
|
||||
---
|
||||
|
||||
*Bei Rückfragen, Wortlaut-Abstimmungen oder vertiefenden Auszügen: direkt bei Pascal melden.*
|
||||
BIN
docs/produktbeschreibung.pdf
Normal file
BIN
docs/produktbeschreibung.pdf
Normal file
Binary file not shown.
Loading…
Reference in a new issue