Solid GmbH — Debrief & Working Sheet
Internes Arbeitsdokument zur Nachbereitung des Termins und zur laufenden Pilot-Vorbereitung. Wächst mit — Findings, offene Punkte, To-dos.
Internes Arbeitsdokument zur Nachbereitung des Termins und zur laufenden Pilot-Vorbereitung. Wächst mit — Findings, offene Punkte, To-dos.
Er hat alle 36 Punkte auf „brauchen wir" gesetzt — die Wichtigkeit differenziert:
Seine „eine Sache": „Das Projekt-Tool! Um den Überblick über die vielen Kleinprojekte zu behalten und im Feed Infos festzuhalten." → #1 glasklar bestätigt.
Freitext-Gold: (1) Zeit wird „nach Gefühl" eingetragen, Start-Stopp kaum genutzt (Bitrix unübersichtlich) → Hebel = „Tool zu komplex", nicht „keine Erfassung" → ungenaue Abrechnung. (Beantwortet unsere offene Zeiterfassungs-Frage.) (2) Stundennachweis: tagesaktuell + Optik ans Rechnungsformular. (3) Urlaub/Krank: nur für ihn, übersichtlich, gern % + Tortendiagramm.
Fachprogramme (aus seiner Mail): ArchiCAD · RIB iTwo + Sirados (Ausschreibungstexte) · MS Office 365 · MS Project (Terminpläne) · ChatGPT Free (→ KI-affin, niedrigschwellig). Seine 2 Hinweise: „Isildur-Mail unprofessionell" (→ Michael @flowphase.ai) + „Anmerkungsfeld" (→ Label-Fix Checkliste).
#27 Urlaub/Krank · #26 Stundennachweis · #23 X-Rechnung = dieselbe Maschine: strukturierte Daten (CSV) → n8n + Claude → fertiges Dokument in seiner Optik. Einmal gebaut, dreimal genutzt.
Weitere Lücken: Kalender-Merge (★5, abgegrenzter Quick-Win) · Foto/Sprache → Bautagebuch/Mängelprotokoll (Flagship-Wow) · Anruf-Notiz → Projekt-Feed.
Grundhaltung: neutraler Berater. Custom-Framing = „wir könnten voll custom bauen — für ein Büro deiner Größe wäre das rausgeworfenes Geld, deshalb raten wir bewusst ab" (nicht „zu teuer für dich"). Preis nur auf Nachfrage (= Signal hoher Investitionsbereitschaft).
Magic-Moment (Scharnier von Weg 2): „DIY/Magic" = KI-für-seinen-Alltag (Angebotstext/Bericht in Sekunden = zeit-sparend), NICHT Software/n8n selbst bauen (hat er abgelehnt, zeit-kostend). Michael liefert ein Aha-Erlebnis → Signal lesen statt pushen: zündet → Builder/Vertikale; zündet nicht → Adopt/Done-for-you.
Umsatz-Caveat: Bei Weg 2 wird Solid ein Strategie-/Community-Bet — NICHT die erste echte Rechnung. „Solid landen" ≠ „erste Rechnung" → Erst-Cash muss von woanders kommen (HM, YourCoaches, SprING).
↓ Ausführliche Herleitung (Pilot-Optionen, Pricing, Delivery-Szenarien A–E, technische Sicht) in den Sektionen ①–⑬ unten.
Termin gelaufen, sehr warm (Co-Creation-Modus). Daniel ist voll dabei (engagiert, will die Entlastung, offen fürs Tag-Team). Das Modell (50/50 · Referenz · Blueprint/Kickback) hat Jan vorgeschlagen, Daniel war sehr empfänglich. = weit mehr als ein Pilot-Lead.
Quellen: Transkript SOLID-Transkript-2026-06-26_clean.txt · Roh SOLID-Transkript-2026-06-26.txt · offene Zeiterfassungs-Fragen solid-klaerungsfragen-zeiterfassung.md · Use-Case-Checkliste solid-checkliste/index.html.
Zwei gleichwertige, schlanke Einstiege — finale Wahl mit Michael nach Daniels Checklisten-Antworten. Beide eignen sich als Demo-Funke für die Enablement-Session. (Cockpit = Ausbau danach.)
Option A — Projekt-Stundennachweis (UC 25 + 26)
Option B — Normen-/Verordnungs-Radar (UC 9-eng)
Make-or-break = einfaches Frontend. Daniel hat ~10× betont „wie sieht die Oberfläche aus?" — kann mit Repo/CLI nichts anfangen („iPhone statt Samsung mit 58 Knöpfen"). Referenz-UX: das Tool „unterm Strich".
Leitplanke: nur schlank Umsetzbares anbieten. Einheitliche Bausteine statt Einzellösungen.
Lesehilfe (szenario-abhängig, s. ⑪): Bei A Custom / B Done-for-you bauen wir Core-App + Automationen selbst · bei E Adopt+Augment liefert das Commodity-Tool den Kern, wir bauen nur die Lücken · bei D Enablement baut Daniel mit unserer Hilfe. „Core-App" = der Eigenbau-Kern (v. a. in A/B relevant).
Komplexität: 🟢 niedrig (schlank/schnell) · 🟡 mittel (etwas Setup) · 🔴 hoch / tool-abhängig / später.
| # | Use Case | Technischer Ansatz / Bausteine | Kompl. |
|---|---|---|---|
| Box 1 · Büro-Flow & Zusammenarbeit | |||
| 1 | Schlankes Projekt-/Büro-Tool | Core-App: Datenmodell (Projekte/Aufgaben/Kontakte/Feed) + Rollen. Das Fundament. | 🟡 |
| 2 | Aufgaben verteilen & Überblick | Core-App: Aufgaben-Tabelle + Zuweisung + Kanban/Status-View. | 🟢 |
| 3 | Anruf-Notiz → Hinweis + Feed | Core-App: Notiz am Projekt + n8n-Benachrichtigung (in-app/E-Mail). | 🟢–🟡 |
| Box 2 · Akquise & öffentliche Vergabe | |||
| 4 | Ausschreibungen finden | n8n: Portal-Feeds/Scraping → Claude-Relevanzfilter → Digest. | 🟡 |
| 5 | Bewerbungsunterlagen vorbereiten | Stammdaten-DB + Vorlagen → Claude befüllt Formblätter. | 🟡 |
| 6 | Fristen-Tracking | Core-App: Fristen-Tabelle + n8n-Reminder. | 🟢 |
| 7 | Referenz-/Projektdatenbank | Core-App: strukturierte Tabelle (v. a. Erfassungsaufwand). | 🟢 |
| Box 3 · Planung & Genehmigung | |||
| 8 | Normen nachschlagen | RAG über Bauordnung/Normen + Claude-Q&A mit Quellen. (Quellen-Pflege beachten.) | 🟡 |
| 9 | Normen-/Formular-Änderungs-Radar | Scope eng (Pre-Submission-Check / 1 Quelle): aktuelle Form/Erlass fetchen → Claude mappt gg. Daniels Version → Lücken. ~3–6 PT. · Scope breit (viele Portale dauerhaft monitoren): + laufende Pflege. | 🟢 eng 🟡 breit |
| 10 | Bauantrag-Vollständigkeitscheck | Anforderungs-Checkliste je Behörde + Claude prüft Unterlagen-Set. | 🟡 |
| 11 | Entwurfs-Visualisierungen | externes KI-Bildtool aus Skizzen. Tool-Nutzung, neben Kern. | 🟡 opt. |
| Box 4 · Ausschreibung & Vergabe der Gewerke | |||
| 12 | Leistungsverzeichnisse vorentwerfen | Bausteinbibliothek + Claude (Text). AVA-Integration (ORCA/California) = Grenze. | 🟡–🔴 |
| 13 | Angebotsprüfung / Preisspiegel | Angebots-PDFs → Claude normalisiert → Preisspiegel-Tabelle. | 🟡 |
| Box 5 · SiGe & Bauüberwachung | |||
| 14 | Begehungs-/Mängelprotokoll | Capture-Pipeline → Protokoll-Vorlage. (Demo-Funke.) | 🟡 |
| 15 | Fachberichte/Konzepte aus Foto+Sprache | = Capture-Pipeline, andere Vorlagen (Sanierungskonzept/Stellungnahme). | 🟡 re-use |
| 16 | Bautagebuch | = Capture-Pipeline → Tagebuch-Vorlage. | 🟢 re-use |
| 17 | SiGe-Plan / Vorankündigung | Vorlagen + Projektdaten-Mapping + Claude. | 🟢–🟡 |
| 18 | SiGeKo-Berichte | koppelt an Begehungsdaten → Berichts-Vorlage. | 🟢 re-use |
| Box 6 · Projektsteuerung & Controlling | |||
| 19 | Bauherren-Reporting / Dashboard | Core-App-Daten → Report-Template (Claude-Text) / Dashboard-View. | 🟡 |
| 20 | Nachtrags-/Rechnungsprüfung (VOB) | Soll (Vertrag/LV) vs. Ist (Rechnung) → Claude-Abgleich → Hinweise. (Vertragsdaten strukturieren.) | 🟡–🔴 |
| 21 | Soll-Ist-Terminplan | Core-App: Terminplan-Daten + Abweichungs-Alerts. | 🟢–🟡 |
| Box 7 · Büro & Backoffice | |||
| 22 | Honorarabrechnung (HOAI) | Honorar-/Zahlungsplan-Logik + Projektdaten → Entwurf. DATEV-Anbindung = Grenze. | 🟡 |
| 23 | X-Rechnung-konform | XRechnung/ZUGFeRD-XML-Generator (Standard-Libs). Deterministisch, kein LLM. | 🟡 |
| 24 | Rechnungseingang erfassen | n8n: Postfach → OCR/Claude-Extraktion → DB/DATEV. | 🟢–🟡 |
| 25 | Zeiterfassung MA (rechtssicher) | Core-App: Start/Stop oder manuelle Erfassung + Rollen, nachvollziehbare Logs. | 🟢 |
| 26 | Projekt-Stundennachweis | aus Zeit-Daten → Sofort-Report + saubere Vorlage (deterministisch). ⭐ Pilot. | 🟢 |
| 27 | Urlaub & Krank + Wandkalender | Core-App: Tabelle + Resturlaub-/Krankquote-Berechnung + Kalender-View. | 🟢 |
| 28 | Verträge/Angebote private Bauherren | Vorlagen + Parameter + Claude. | 🟢–🟡 |
| 29 | E-Mail-/Posteingang sortieren | n8n + Claude-Klassifizierung (Pattern hast du schon). | 🟢 |
| 30 | Besprechungs-Protokoll | Audio → Whisper → Claude → Protokoll + To-dos. | 🟢 |
| 31 | Termin-Briefing | n8n zieht Kontext (Mail/Akten) → Claude-Briefing. | 🟡 |
| 32 | Kalender zusammenführen | Sync via n8n/CalDAV bzw. Sync-Tool (Google↔Outlook). | 🟢–🟡 |
| Box 8 · Wissen, Daten & System | |||
| 33 | Kunden-/Projekt-Kontext + Stammkunden | Abfrage über Core-DB + Quellen → Claude-Summary. (Stammkunden = Core-App-Tabelle.) | 🟡 |
| 34 | Dokumenten-/Wissenssuche | RAG über die Ablage, mit Quellenangabe. | 🟡 |
| 35 | Wissenssicherung / Onboarding | strukturierte Ablage + RAG. | 🟢–🟡 re-use |
| 36 | Sprachassistent unterwegs | Voice-Interface auf bestehende Funktionen. | 🔴 später |
🔎 Spike 2026-06-28 (UC9): Zentrale Quelle wirtschaft.hessen.de (Bauvorlagen/Erlass) ist sauber fetchbar und trägt das Änderungs-Signal direkt (Erlass „gültig ab 19.08.2025", „letzte Änderung 18.12.2025"; Formular-PDFs mit Jahres-Stand im Dateinamen, z. B. 2025_bab_01.pdf). → Normen-/Formular-Check (eng) = GRÜN & pilot-tauglich. Vergabe-Portale (HAD/RIB, Login) bleiben der härtere, separate Teil.
Fazit: Der Großteil läuft auf einer schlanken Architektur (Core-App + n8n/Claude/Whisper + RAG). Pilot UC 26 (Stundennachweis) baut auf der Core-App + Zeiterfassung (25) auf — danach decken dieselben Bausteine ~20 weitere UCs ab. Das ist die Blueprint-Logik fürs Ausrollen.
Die Use Cases sind keine Insellösungen — die meisten sitzen auf fünf gemeinsamen Fundamenten. Einmal gebaut, wird jedes weitere UC billig. Das ist die Blueprint-Logik (und das Argument für „klein starten, dann ausrollen").
Blueprint-Hebel: Fundamente A–E einmal sauber bauen → über die 5+ Ingenieurbüros wiederverwenden; pro Büro nur Daten, Vorlagen und Quellen anpassen. Genau das macht den 20 %-Kickback-Rollout wirtschaftlich.
Leitsprache: Wir rechnen in gesparten Stunden — „du bist Freitags früher daheim", nie in ROI/Umsatz. Daniels Antrieb = Zeit für sich + Familie. „Zeit statt Geld" ist der wertvollste Satz des Termins.
Logik: Fundament einmal bauen, dann ist jedes weitere UC ein kleiner Aufschlag (PT = Personentage).
| Cluster (UCs) | grobe Ersparnis | Daniel-Satz |
|---|---|---|
| Doku aus Foto/Sprache (14·16·30) | ~8–16 h/Mon | „Kein Abend-Abtippen mehr." |
| Zeit/Stundennachweis/Urlaub (25·26·27) | ~3–8 h/Mon | „Rechnung sofort fertig — und keine Steuerberater-Gebühr für Krankentage." |
| E-Mail-Triage / Briefing (29·31) | ~2–5 h/Mon | „Der Posteingang sortiert sich selbst." |
| Bewerbungsunterlagen (5) | ~1–3 h/Vergabe | „Bewerbung in Minuten statt Stunden." |
| Büro-Flow (1·2·3) | eher Nerven | „Nichts geht verloren, kein Nachtelefonieren, keine Doppelarbeit." |
📌 Konkreter Einzel-Beleg (Michael): Bürofahrten ~400 Min/Monat ≈ fast ein Arbeitstag. ⚠️ Vor externer Verwendung verifizieren — nicht eindeutig im Transkript (evtl. Michaels Schätzung).
Zeit zurück (h/Monat) — Annahme, via Volumina verifizieren
Betriebskosten / Monat
Beispiel-Rechnung (Annahmen): Pilot einmalig ~€3–8k · Betrieb spart ~€150–300/Mon ggü. Bitrix · Vollausbau bringt geschätzt ~15–30 h/Mon zurück (≈ ein halber Tag pro Woche).
Cash allein rechtfertigt es nicht schnell: Pilot amortisiert sich über die reine Bitrix-Ersparnis erst in ~1,5–3 Jahren → Cash ist nicht das Hauptargument.
Der echte Return = zurückgewonnene Zeit (Daniels Währung): ~0,5 Tag/Woche. Genau das verkaufen wir — „du bist Freitags früher daheim", nicht „du sparst €X".
Die einmaligen Bau-Kosten gehören in die Rechnung — die Story muss sie tragen.
| Posten | Betrag | Hinweis |
|---|---|---|
| Pilot-Option A: Stundennachweis (UC 25 + 26) | ~€3–8k einmalig | sicher — hängt nur an eigenen Daten |
| Pilot-Option B: Normen-/Verordnungs-Radar (UC 9-eng) | ~€3–6k einmalig | tieferer Schmerz + Demo-Funke; Quelle fetchbar (Spike ✓ 2026-06-28) |
| Cockpit-Ausbau (Büro-Flow / Bitrix-Ablöse) | ~€8–20k einmalig | auf der Core-App, gestaffelt |
| Smart-Features (Capture/n8n/RAG, je Bedarf) | inkrementell | schrittweise, nur was Wert bringt |
| Betrieb laufend | ~€20–70/Mon | statt Bitrix ~€200–360 |
⚠️ Förderung NICHT auf den Bau einrechnen: Beratungsförderung (z. B. BAFA) deckt nur die initiale Beratung ab, nicht die Umsetzung/Implementierung. Die Bau-Kosten werden normal bezahlt.
Die Story (warum es sich für Daniel lohnt) — in Zeit-Sprache:
Backup-Zahl — nur falls Daniel auf Geld zielt (sonst weglassen): ~15–30 h/Mon zurückgewonnene Kapazität entsprechen real mehrere Hundert bis über €1.000/Mon Wert. Aber das ist nicht, warum er es macht — Headline bleibt Zeit/Lebensqualität.
Interner Pricing-Hebel (NICHT an Daniel): Pilot bewusst günstig, weil Solid = Referenz + Referral + Blueprint (50/50 mit Evert). Rechtfertigt einen niedrigen Erst-Preis, der für andere Büros nicht gilt.
Falle: „günstigeres Tool" ist kein Wechselgrund. „Setup-Kosten + weiter monatlich" wirkt teurer als „nur Bitrix-Abo". So gewinnt man nie.
Hebel: nicht draufsatteln, sondern das bestehende Bitrix-Budget umleiten. O-Ton Daniel: „Die 200 € im Monat — ob ich die denen oder euch gebe, ist mir egal." = Greenlight.
💡 Keine AI-Lizenz pro Kopf: Automationen laufen zentral (1 n8n-Instanz, 1 API-Key); die Leute gehen über Mail / simple Maske / bestehende Tools rein → per-Seat-Kosten entfallen. (Die „Lizenz pro Mitarbeiter" war nur ein Artefakt der „Cockpit-für-jeden-mit-Cowork"-Idee.)
| Modell | Für Daniel | Für FlowPhase | Wann passend |
|---|---|---|---|
| B · Done-for-you monatlich ⭐ | ~€/Mon ≈ heutiges Bitrix-Budget, 18–24 Mon, enthält Bau + Hosting + Wartung; danach Absenkung ~€80–120/Mon. Kein Upfront. | wiederkehrender Umsatz + Bindung; trägt den Bau über die Laufzeit (Cashflow beachten) | leichtester Wechsel — gleicher Modus wie Bitrix |
| A · Projekt / Einmalkauf | Bau einmalig + Mini-Hosting ~€20–70/Mon. „Gehört mir", günstigster Langfrist-TCO. | sofortiger Cashflow, klarer Schnitt | für seinen „raus aus Abo"-Wunsch; Hürde = Upfront im schwachen Jahr |
| C · Hybrid | kleiner Setup + kleiner monatlicher Care | Mittelweg: etwas Cash + etwas Recurring | Kompromiss, wenn beides teils gewünscht |
Empfehlung: Good-Better-Best — A und B anbieten, Daniel wählt sein Modell, beide gegen dasselbe Budget verankert. B nimmt die „warum Setup oben drauf"-Hürde raus; A bedient die Abo-Müdigkeit. Beispiel B: heutiges Bitrix-Budget (~€280/Mon) × 24 Mon ≈ €6,7k → deckt Pilot + Cockpit-Bau + Hosting + Care + Marge; kein zusätzliches Geld für Daniel.
Haken bei flat „€200 ab Tag 1": er zahlt voll, obwohl die Funktionen erst nach Wochen gebaut sind (Wert-Lag) — und Bitrix läuft bis 30.09. parallel (Doppelkosten-Risiko). Deshalb „klappt's nicht so richtig".
Nach Konsolidierung (Checkliste + Klärungsfragen) bekommt Daniel ein Szenario-Menü A–E (von Full Custom Build bis Adopt+Augment) zur Wahl. Quer darüber: eine Inspiration-/Working-Session, die ihn in unsere Welt holt — entlang seiner Use Cases.
| # | Szenario | Wer baut / betreibt | Für wen / Pricing-Andock |
|---|---|---|---|
| A | Full Custom Build | wir bauen alles selbst: Self-Built-App + n8n + Core-App (System-of-record + Automationen) | maximaler Eigenbau, volle Kontrolle/IP · teuerste Option (Economics-Caveat, s. u.) |
| B | Done-for-you (managed) | wir richten Commodity (untermStrich) + zentrale Automationen ein und betreiben/warten; er nutzt nur | wenn er gar nichts selbst will · Pricing A/B/C (⑩) |
| C | Co-Pilot / Hybrid | wir Kern + Hartes, er/jemand Einfaches, wir supporten | wenn er teils selbst Hand anlegen will · Bau + Care |
| D | Enablement / DIY + Support ⭐ | er baut/adaptiert selbst (VS Code · Claude Code · Repo/Cloud-Zugriff · Workflows · Artifacts), wir = Stundenberater + kleine Automations | ⭐ jetzt fokussiert: erster Schritt = Enablement-Session → inspirieren + befähigen; stundenweise Begleitung + Community (Multiplikator-Spiel) |
| E | Adopt + Augment | fertiges Branchentool (untermStrich, sein Abo) als Kern + wir bauen nur die Lücken, die kein SaaS verkauft (Notiz→Bericht, offene Posten, Ausschreibungs-Radar) — zentral | billig + zentral baubar, niedrigstes Bau-Risiko |
ℹ️ Spektrum von A (max. Eigenbau) bis E (Commodity + Lücken) — bewusst alle Optionen als Arbeitsgrundlage; Daniel wählt. Economics-Caveat zu A (Full Custom): SaaS amortisiert seine Entwicklung über 100k Kunden, wir über einen → die 20–30k sind eher der Preis vom Überbauen als der Preis der Use Cases (= Punkt-Automationen + dünne Übersicht). Bleibt als Option drin, aber mit offenen Augen wählen.
Strategischer Preis: Multiplikator/Community. Ein inspirierter Daniel in der Ingenieur-/Architekten-Vertikale = Word-of-Mouth („sprecht mit den Jungs, die haben mir das gebaut") — potenziell mehr wert als der Solid-Deal selbst, deckt sich mit dem Blueprint-/Referral-/Builder-Community-Play.
whatsapp-daniel-checkliste.html).