Agentic Ventures Wiki

Service-First, Produkt waechst aus Bausteinen — keine separate Plattform-Phase

6 Min. Lesezeit

Service-First, Produkt waechst aus Bausteinen

Kontext

Beim Design des Produkt-Bundles (produkt-bundle) entstand die Frage nach der Reihenfolge. Drei vergleichbare Pfade stehen zur Auswahl:

  1. Plattform-First — 3-6 Monate komplettes SaaS-Produkt bauen (Stripe-Onboarding, Multi-Tenant-Hosting, Self-Service-UI), dann am Markt anbieten
  2. Service-First — die ersten Kunden im Managed-Service betreuen, Bausteine extrahieren, dann SaaS-Tier daraus ableiten
  3. Hybrid Parallel — Service und SaaS-Frontend parallel aufbauen, gleicher Stack

Marvins Erfahrung mit Voit, HeyJulia, julia_v2, agentic-os (keine-eigene-plattform) hat Plattform-First explizit verworfen — alle archiviert weil Bauen ohne Kunden zu Build-without-Validation fuehrt. Memory hat zudem die Heuristik “feedback_dont_build_everything” mit der Anweisung, den Reflex “ich bau das” aktiv zu hinterfragen.

Aktuell zahlen zwei Kunden fuer Service:

  • Vibe Factory (Andre, aktiv produktiv mit mcp-vf-hosted auf Railway) — Eventveranstalter, Stack: M365 + Papierkram + TicketPAY + perspektivisch LexOffice + Teams + Sparkasse
  • Weingalerie Woehrle (Frau Woehrle, im Sales-Funnel) — Wein-Einzelhandel, Stack: TSE-konforme Kasse + LexOffice + Banking + Bestandsmanagement + Veranstaltungsbuchung

Plus weitere im Pipeline-Funnel. Real-money, Real-Feedback, Real-Validation ist da. Self-Service-Hypothesen-Validierung am Markt ist nicht das Engpass-Thema — Lieferqualitaet und Skalierbarkeit der Service-Bausteine ist es.

Optionen

Option A — Plattform-First

Komplettes SaaS-Produkt aufbauen vor erstem Self-Service-Kunden. Stripe-Frontend, Multi-Tenant-Backend, Marketing-Page, AVV-Auto-Generation. 3-6 Monate ohne Recurring Revenue.

Pro:

  • Eine Code-Basis, kein Custom-Drift
  • Saubere Marke “wir sind SaaS”

Contra:

  • Bewiesen-fuer-Marvin-eigenes-Bauen-Verhaltensmuster ineffektiv (siehe Memory + ADR keine-eigene-plattform)
  • 3-6 Monate ohne Cash-Flow bei UG-Bootstrapping
  • Validierungs-Schwarzloch: was ist das richtige Standard-Bundle? Welche MCPs zuerst? Welche Tier-Schwelle? Antworten kommen nur von echten Kunden, nicht aus Whiteboard-Sessions
  • Wettbewerb (Apideck, Composio, ggf. Anthropic First-Party) hat bei Lauffrist-Verlust Vorsprung

Option B — Service-First mit produktisierten Bausteinen

Sofort weiter Service verkaufen (Vibe Factory + Wöhrle + Folge-Kunden), dabei jeden Bau-Block als Wiederverwendung-faehig dokumentieren. Hosting-Pattern, MCP-Bundle, Onboarding-Runbook, Vault-Schema entstehen organisch. Wenn 5+ Kunden den gleichen Bundle haben, ist Standardisierung “natürlich gewachsen”, nicht “ausgedacht”.

Pro:

  • Sofort Cash-Flow
  • Real-Validation in jedem Setup
  • Konsistent mit ADR keine-eigene-plattform und ADR-Empfehlung “Service-Modell mit Brain + MCPs pro Kunde”
  • Wenn Self-Service-Tier kommt, ist das Produkt zu 80 % schon gebaut
  • Bootstrap-realistisch fuer UG ohne VC

Contra:

  • Disziplin noetig: Custom-Aufträge die nichts Wiederverwendbares produzieren droht “Service-Trap” (Kapazitaet voll, Marge mittel, keine Skalierung)
  • Branding-Ambivalenz “Berater oder Produkt-Anbieter” muss aktiv gesteuert werden
  • Self-Service-Tier kommt 6-12 Monate spaeter als bei Option A

Option C — Hybrid Parallel

Service betreuen UND parallel SaaS-Plattform bauen. Beide gleichzeitig priorisieren.

Pro:

  • Theoretisch schneller am SaaS-Tier
  • Beide Erloesschienen parallel

Contra:

  • Solo-Founder schafft das nicht ohne Personal — nicht ehrlich angesetzt fuer aktuelle Kapazitaet
  • Spaltet Aufmerksamkeit, beides leidet
  • Versucht das Beste aus zwei Welten, oft mit dem schlechtesten Ergebnis

Entscheidung

Option B — Service-First mit produktisierten Bausteinen. Drei Phasen mit klaren Uebergangs-Triggern.

Phase A — Service mit Standard-Bausteinen (jetzt bis ~Juli 2026)

Was passiert:

  • gsuite-hosted Phase 1 fertig als Pattern-Beweis (Container-Deploy, ECS Express, Cloudflare-Edge, Scalekit-OAuth)
  • Vibe-Factory-AWS-Migration als Referenz-Implementation des MCP-Bundle-Patterns
  • Wöhrle als zweiten Kunden onboarden — neue Branche (Einzelhandel/Wein) zwingt Stack-Erweiterung um Kassen-/POS-MCP, Wein-Bestandsmgmt, Veranstaltungs-Buchung
  • 1-2 weitere Kunden im Sales-Funnel onboarden
  • Setup-Runbook + AVV-Template + Onboarding-Skripte entstehen organisch
  • Vault-Pattern bei jedem Kunden eingebaut (siehe markdown-und-db-trennung)

Pricing: Setup-Fee 5-15k einmalig + 500-1500 €/Monat Recurring (Service-Tier).

Revenue-Ziel: 3-5k MRR aus 4-6 Service-Kunden bis Ende Phase A.

Uebergang zu Phase B ausgeloest wenn:

  • Mindestens 3 Kunden den gleichen oder ueberlappenden MCP-Stack haben
  • Setup-Zeit pro Kunde unter 2 Wochen liegt (heute ~1 Monat)
  • Hosting-Pattern stabil (kein neues Architektur-Problem pro Setup)

Phase B — Standardisierung (Juli-Oktober 2026)

Was passiert:

  • Standard-Bundle-Komposition fest definiert (welche MCPs, welches Vault-Default-Schema, welche Default-Skills)
  • Hosting-Pipeline als Skill (Phase 4 von _index): mcp-aws-deploy automatisiert Repo-Bau + CDK + Container-Push
  • Multi-Tenant-Backend in av-production mit DynamoDB+S3-Vault-Architektur (siehe markdown-und-db-trennung)
  • Onboarding-Wizard (intern, noch nicht Self-Service) der einen neuen Tenant in 2-3 Tagen aufsetzt
  • AVV-Template von Anwalt durchgesehen
  • Compliance-Paket konsolidiert (AGB, Datenschutz, EU-AI-Act-Risiko-Klassifizierung)

Pricing: unveraendert, aber Setup-Fee sinkt auf 3-8k weil schneller.

Revenue-Ziel: 6-8k MRR aus 6-10 Kunden.

Uebergang zu Phase C ausgeloest wenn:

  • Onboarding-Wizard vollstaendig “ohne Marvin im Loop” funktioniert
  • Marketing-Material steht (Landing-Page, Demo-Video, Pricing-Page)
  • Stripe-Setup mit Tax-Handling fertig
  • Anwalt-Review fuer Self-Service-AGB durch

Phase C — Self-Service-Tier dazu (Q4 2026)

Was passiert:

  • Solo-Tier mit Stripe geht live (49 €/User/Monat, 1-5 User, fest definierter Standard-Bundle)
  • Team-Tier mit Stripe geht live (99 €/User/Monat, bis 25 User, voller Standard-Bundle)
  • Custom-Tier bleibt Quote-only fuer alles ueber Standard-Schwelle
  • Bestehende Service-Kunden bleiben weiter, neu klassifiziert als Team oder Custom

Pricing-Mix: ~70 % Recurring aus Self-Service-Tiers, ~30 % aus Custom-Tier-Service-Kunden.

Revenue-Ziel: 10-15k MRR mit Mix aus Stripe-Solo + Team + 2-3 Custom-Kunden.

Konsequenzen

Sofort (Phase A):

  • Aktuelle Threads (_index Steps 1.3-1.6, VF-AWS-Migration, MCP-Erweiterungen, Wöhrle-Onboarding) sind alles Phase-A-Items unter dem Dach von produkt-bundle — nicht parallele unabhaengige Projekte
  • Bei jedem Setup explizit Bauzeit fuer “Bausteine wiederverwendbar machen” einplanen (10-20 % Aufschlag auf Setup-Fee)
  • Stripe NOCH NICHT als Customer-Frontend bauen — nur als Invoice-Tool fuer Service-Rechnungen (Stripe Invoice, kein Customer-Portal)

Mittelfristig (Phase B):

  • Standard-Bundle definiert sich selbst aus den haeufigsten Tool-Kombinationen der ersten 5-6 Kunden
  • Branchen-Templates entstehen wenn 2-3 Kunden derselben Branche dasselbe brauchen (heute: Eventveranstaltung VF, Einzelhandel/Wein Wöhrle — wenn weitere Eventveranstaltungs- oder Einzelhandels-Kunden dazukommen, wird das ein Template)

Anti-Patterns die wir aktiv vermeiden:

  1. Custom-Auftrag annehmen der nichts Wiederverwendbares produziert. Wenn ein Kunde eine Tool-Welt hat die nirgendwo sonst auftaucht und ein Setup-Aufwand ueber 20k brauchen wuerde — dann ablehnen oder als reinen Beratungs-Auftrag (ohne Hosting) annehmen
  2. Stripe-Frontend fruehzeitig bauen. Vor Phase C ist das verfruehte Optimierung — der Onboarding-Flow ist erst sinnvoll wenn der Standard-Bundle stabil ist
  3. Parallel zwei Hosting-Patterns. Wenn Phase 4 der Pipeline (mcp-aws-deploy als Skill) fertig ist, alle Bestandskunden-Hosting darauf migrieren
  4. Plattform-Branding vor Phase C. “Agentic Ventures” als Service-Marke, ein Produkt-Name fuer die SaaS-Tier kommt erst in Phase C — vorher Verwirrung
  5. Vergessen Bausteine zu dokumentieren. Jede Service-Implementierung muss in intern/wissen/prozesse/ ein Pattern hinterlassen ODER in intern/capabilities/skills/ einen Skill ODER in intern/capabilities/repos/ einen Repo-Eintrag — sonst war’s verlorene Zeit

Personal-Frage als Vorausschau:

Phase C mit Self-Service skaliert auf 30-50 Kunden bevor Support-Last anschlaegt. Phase B+C mit Custom-Tier-Vertrieb braucht entweder Marvin’s Vollzeit-Vertriebs-Engagement oder ein Sales-Profil im Team. Personal-Frage muss beantwortet sein wenn 8-10 Kunden aktiv sind (Phase B Endphase) — sonst entweder Wachstum bremst oder Support-Qualitaet sinkt.

Graphansicht

Backlinks