- **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) |
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.
-`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
Keine Google Fonts CDN. Alle Fonts liegen in `public/fonts/` und werden über `@font-face` mit `font-display: swap` geladen. Latin + Latin-Ext jeweils per `unicode-range` getrennt, damit Latin-Ext nur bei Bedarf geladen wird.
| 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.
- 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.
- Headlines (`h1`, `h2`): Sans (Outfit), weight 500 (NICHT 600 oder 700), `letter-spacing: -0.01em` bei H1+, `line-height: 1.10–1.20`. Bei Hero-Highlight (Background-Stempel) darf `font-weight: 550` genutzt werden, um optische Verdünnung dunkler Schrift auf Persimmon auszugleichen.
- Body: Sans (Outfit), weight 400, `line-height: 1.65`.
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 `·`.
- **`NavBar`** — sticky-on-scroll. Standardmäßig auf hellem Body-Hintergrund. **Auf der Home-Seite bei Scroll-Position 0 läuft die NavBar visuell IM dunklen Hero mit** (gleicher `#0E0F14`-Hintergrund, Logo und Links in Off-White). Sobald der Tech-Strip vorbei ist und der helle Body-Bereich beginnt, wechselt die NavBar in den hellen Modus zurück. Implementierung: NavBar als `position: sticky` mit `top: 0`, der Hero-Hintergrund läuft hinter der transparenten NavBar durch — beim Scrollen wird die NavBar dann von der hellen Body-Sektion „ausgewaschen". Alternative-Implementierung: NavBar wechselt Hintergrund-Farbe per IntersectionObserver, sobald der Hero den Viewport verlässt. Beide Wege sind ok, Hauptsache: kein Hard-Cut zwischen NavBar und Hero-Hintergrund.
**Sticky-Verhalten:** NavBar ist sticky on scroll. Auf der Home-Seite ist sie bei `scrollY=0` im dunklen Hero-Modus (siehe NavBar-Komponenten-Spec in §5.6); der Übergang zum hellen Modus passiert beim Verlassen des Hero-Bereichs. Der `border-b` erscheint nur im hellen Modus und nur bei `scrollY > 8px`.
**1. Hero — DUNKLER HERO MIT PERSIMMON-HIGHLIGHT (verbindlich)**
> **Diese Spezifikation ist verbindlich, nicht optional.** Frühere Brief-Versionen ließen die Hero-Variante offen, was zu einer hellen Standard-Implementierung geführt hat. Die finale Entscheidung ist die dunkle Variante mit Background-Highlight auf „Grenzenlos". Bitte nicht zur hellen Variante zurückrationalisieren — die dunkle Variante ist Teil der Marken-Persönlichkeit „seriös, aber Revoluzer", und der Bruch zwischen dunklem Hero und hellen Folge-Sektionen ist gewolltes Lese-Architektur-Element.
- Headline-Text: `#F5F5F0` (warmes Off-White, kein reines Weiß — passt zum cremefarbenen Body-Hintergrund der restlichen Site)
- NavBar in der Hero-Region läuft mit dunklem Hintergrund mit; Logo, Nav-Links und Sprachwahl in Off-White mit reduzierter Opacity (0.65–0.85). Übergang zum hellen Body unterhalb des Tech-Strips.
- Hero hat KEIN Border, KEIN Frame — nahtlos voll-bleed in die Container-Breite
**Eyebrow:**
- Text: `▸ GESCHÄFTSSOFTWARE FÜR SOLO-SELBSTSTÄNDIGE UND KLEINE TEAMS`
- Größe: clamp(38px, 5vw, 56px) — responsive, aber nicht kleiner als 38px im Hero
- Farbe: `#F5F5F0` für „Schlank starten." und „wachsen."
- **Das Wort „Grenzenlos" ist verbindlich als Background-Highlight gesetzt:**
- Background: `#FF6B2C` (Electric Persimmon)
- Vordergrund-Text auf dem Highlight: `#2A0F02` (dunkles Persimmon-Schwarz, nicht reines Schwarz)
- Padding: `0.04em 0.2em 0.08em` (em-relativ, skaliert mit der Schriftgröße)
-`display: inline-block`, `line-height: 0.95`, `font-weight: 550`, `vertical-align: baseline` — der Block hugt die Buchstaben eng, kompensiert die optische Verdünnung dunkler Schrift auf hellem Persimmon
- KEINE rounded corners (border-radius 0) — das Persimmon-Rechteck soll wie ein Marker-Stempel wirken, nicht wie ein Pill-Button
**Lead-Paragraph:**
- Text: „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."
- 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)
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)
- 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.
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
- ❌ 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.
- 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:
Astro liefert das mit Bordmitteln, solange wir keine Bilder ohne Optimierung einbauen. Alle eingebundenen Bilder über Astro's `<Image>` mit AVIF-Output.
- **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`
- **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, ...) |
| 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.
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.
