Für Entscheider — Eigentümer, Betreiber & Partner
Diese Seite ist nicht die Redaktions-Anleitung. Sie richtet sich an die Führungsebene und strategische Partner:
| Begriff (Branche) | Wer das meint |
|---|---|
| Asset Owner / Immobilieneigentümer | Eigentümer der Immobilie, Portfolio-Verantwortliche |
| Center-Betreiber | Geschäftsführung & Management des Centers (Hauptkunde) |
| Asset Manager | Institutionelle Verwalter der Fläche |
| Investoren (VC/PE) | Nur, wenn die Plattform-Firma CockpitOS finanziert wird — nicht der Shop-Mieter |
| Strategische Partner | Agenturen, Technologie-Partner, Integratoren |
Sie antwortet auf die Frage:
Ist das eine zusammengewürfelte Tool-Sammlung — oder eine Plattform, die sich für Betrieb und Digitalisierung des Centers lohnt?
Kurzantwort: CockpitOS ist als mandantenfähiges Betriebssystem für Shopping Center gebaut: ein Datenkern, viele Kanäle, modulare Freischaltung, öffentliche APIs und eine nachvollziehbare technische Basis. Nicht „WordPress plus ein paar Plugins“.
In 60 Sekunden
| Was | Plattform für Center-Betrieb: Content, Freigaben, Website, Signage, Social, Apps, Analytics — eine Pflege, viele Ausgänge. |
| Für wen | Betreiber, Eigentümer, Marketing-Organisationen, Agenturen (über APIs). |
| Technik | Monorepo, PostgreSQL, Dashboard als API- und Datenkern; Kanäle als Clients. |
| Differenz | End-to-End-Verzahnung (Redaktion → Freigabe → Website/Signage/Social) statt Insellösungen. |
Vertiefung: Plattform-Überblick · Modul-Landkarte: Core Features & Module.
Warum das keine „zusammengekloppte“ Software wirkt
1. Bewusste Architektur — ein Kern, viele Kanäle
- Nur das Dashboard spricht direkt mit der Datenbank (Prisma, zentrale Geschäftslogik).
- Website, Signage und Manager-App sind API-Clients — kein paralleles „Schatten-CMS“.
- Social-Publish, Workflow, Dispatch und Planner sind im selben Produkt verzahnt, nicht per Zapier nachgerüstet.
2. Produktreife sichtbar im Alltag
| Signal | Bedeutung für Entscheider |
|---|---|
| Modul-System | Mandanten schalten Mall Cockpit, Social, Signage, Analytics … pro Vertrag frei — Skalierung im Produktmodell, nicht nur im Code. |
| Rollen & Organisationen | Multi-Center, Multi-Mall, Rechte pro Rolle — Enterprise-taugliche Struktur. |
| Freigabe-Workflows | Website-Entwürfe und Social-Posts mit Audit-Spur, Benachrichtigungen, externem Freigabe-Link. |
| Öffentliche API + AgencyOS + MCP | Partner und moderne Frontends (v0) ohne Kern zu ersetzen — Plattform-Denken. |
| Template-System | Viele Center-Websites (ILG, MEC, Goldbeck, …) auf gemeinsamer Architektur, nicht 20 Einzelprojekte. |
| Diese Dokumentation | Hunderte Seiten, rollenbasierte Navigation, Changelog — Investition in Nachvollziehbarkeit, nicht nur Code. |
Details: Plattform-Reife & Betrieb.
3. Marktposition — Tiefe statt Einzelfeature
Am Markt dominieren Teillösungen (CMS, Signage, Social-Tool, Property-Software). CockpitOS adressiert die Lücke dazwischen: dieselben Shops und Events auf Website, Display, App und im KI-Assistenten — inklusive operativem Cockpit (Dispatch, Issues, Planner).
Vergleichstabelle: Plattform-Überblick → Abschnitt „Warum diese Tiefe selten kombiniert wird“.
Was finanzierbar skaliert
| Hebel | Beschreibung |
|---|---|
| Mehr Center pro Installation | Mandantenfähigkeit bereits im Datenmodell und in der Navigation. |
| Module / Upsell | Social Cockpit, Analytics, Digital Experience, Property … als Produktbausteine. |
| Agentur-Ökosystem | AgencyOS-API, Public API, dokumentierte Verträge — Umsatz über Integration statt nur Lizenzen. |
| Modernisierung Bestand | v0/Vercel-Frontends an stabilem Datenkern — Center modernisieren ohne Datenmigration pro Kanal. |
| KI als Prozess | MCP, v0-Instructions, Assistent mit Live-Daten — Differenzierung, nicht Chatbot-Deko. |
Keine Umsatz-, Kunden- oder Marktanteilszahlen in der öffentlichen Doku — die gehören in Pitch und Vertrag. Diese Seite belegt Produkt- und Architektur-Reife.
Technologie — seriös, nicht experimentell
| Bereich | Stand |
|---|---|
| Stack | TypeScript, Next.js (App Router), PostgreSQL, Prisma, Turborepo-Monorepo |
| Betrieb | Produktiv auf Render (u. a. Frankfurt), Medien CDN, dokumentierte Cron/Webhooks |
| Datenbank | Additive Migrationen, dokumentierte Sicherheitsregeln — kein „schnell mal Schema ändern“ |
| Sicherheit | Geheimnisse serverseitig; öffentliche APIs mit klar abgegrenzten Feldern (templatePublicContent ohne Keys) |
| Observability | Status-Setup (Better Stack), Analytics (Umami) — siehe Betrieb |
Technische Tiefe für Due Diligence: Developer Guide · Public API · Architektur-Notiz im Repo (Link unten).
Liefergeschwindigkeit — nachprüfbar
| Quelle | Was Sie sehen |
|---|---|
| Änderungsprotokoll | Größere Lieferungen mit Datum, Was/Warum, Links |
| GitHub | Monorepo, Commits, CI |
| Live-Produkte | dashboard.cockpit-os.de · signage.cockpit-os.de · docs.cockpit-os.de |
Das ist kein PowerPoint-Produkt: Dashboard, Signage, Doku und APIs sind öffentlich erreichbar und in der Dokumentation beschrieben.
Für wen diese Seite gedacht ist
| Rolle | Empfohlener Pfad |
|---|---|
| Investor (VC/PE) | Diese Seite → Reife & Betrieb → Due Diligence (Kurz) |
| Asset Owner / Center-Betreiber (GF) | Plattform-Überblick |
| Presse / Kommunikation | Pressemitteilung — Texte |
| Technischer Partner | Due Diligence (Kurz) → Developer Guide |
Redaktions-Onboarding: Navbar Redaktion → Start hier.
Nächster Schritt & Kontakt
- Demo / Gespräch: sb@schickma.de · +49 201 857 927 24
- Technische Architektur (Repo): COCKPITOS-SYSTEMARCHITEKTUR-VOLLSTAENDIG.md — bei Widerspruch: Code und Plattform-Überblick maßgeblich.
Nutzungsstatistik: Seitenaufrufe werden anonymisiert erfasst. Im Umami-Dashboard nach diesem Pfad filtern: /plattform/investoren-und-partner