DailyHair bauen — von null zu 200 betreuten Veranstaltungen in 12 Monaten

Im zweiten Quartal 2025, auf der Cupra-Konferenz in Warschau mit 47 Medienpartnern, bekamen wir um 22:47 eine Mail von der Koordinatorin: „Zum vierten Mal diese Woche verschiebt Forbes den Deadline. Wyborcza will ein anderes Briefing als TVN24. Ich habe das alles in einem Excel mit drei Reitern, aber um 6:00 morgen muss ich 47 separate Zusammenfassungen rausschicken und weiß schon nicht mehr, wer bei was steht.” Im Anhang ein Screenshot des Sheets, in dem sie die telefonisch vereinbarten Deadlines mit Strichen markiert hatte. Zwei Stunden später kam die Branchenkonferenz, die wir mitorganisierten — die erste, auf der wir denselben Pattern bei drei weiteren Kommunikationsmanagerinnen sahen. In derselben Woche begannen wir, DailyHair zu bauen.

Die Zahl „47 Medienpatrone” war für sich nicht beeindruckend. Sie war Symptom einer operativen Architektur, die kein generisches Event-Tool abbildet. Die Kommunikationsmanagerin organisierte keine Veranstaltung — sie löschte Brände zwischen zwei Welten: dem Veranstalter, der maximale Sichtbarkeit will, und den Medien, die maximalen Wert für ihren Patronat erwarten.

Bei DailyHair fielen von Anfang an drei Bedingungen zusammen, die wir in jeder Venture-Building-Partnerschaft suchen. Erste: eine Expertin mit 12 Jahren in Event-PR und einer Liste von 30 befreundeten Veranstaltern, die bereit waren, das Produkt zu testen — das war keine Hypothese, sondern Distribution zum Start. Zweite: ein Markt von 1.500 polnischen Konferenzen jährlich, die Medienpatronate bedienen, von denen 15% bereits 200+ SaaS-Kunden ausmachen. Dritte, die schwerste: null Toleranz der Partnerin für Software, die ein zweistündiges Onboarding mitten im Event-Sprint verlangt — operativ hieß das, jedes Feature musste in 5 Minuten funktionieren oder gar nicht existieren. Diese drei Bedingungen sahen operativ wie ein seltener Moment aus, in dem Idee, Distribution und Scope-Disziplin in einem Paar Händen liegen.

Warum wir kein weiteres Eventbrite gebaut haben

Eventbrite, Evenea, Konfeo sind gut für die Masse. Pragmatische Werkzeuge für Veranstalter, die „Online-Ticketing haben” und sich darüber hinaus nicht differenzieren wollen. Doch der Markt, der uns interessierte — Branchenveranstaltungen und Konferenzen mit Budgets ab 200.000 PLN aufwärts, in denen Medienpatronate und Sponsoring einen wesentlichen Teil der Finanzierung darstellen — hat spezifische Bedürfnisse, die eine generische Ticketing-Plattform nicht adressiert.

Erstens: Medienpatronatsverwaltung als Erstrang-Objekt. Ein Patronat ist kein „FREE-Kategorie-Ticket”. Es ist ein Vertrag mit einem Medium, in dem beide Seiten Verpflichtungen haben (Veröffentlichung einer Vorschau, Social-Media-Post, Banner auf der Konferenz im Tausch gegen Logo-Platzierung, Erwähnung und ein Ticketkontingent). Jedes Patronat hat sein eigenes Briefing, sein eigenes Asset-Paket, seine eigenen Deadlines, seinen eigenen Post-Event-Bericht. Es fehlte ein Werkzeug, das diesen zweiseitigen Vertrag nativ versteht.

Zweitens: Patronatspakete. Hauptmedienpatron plus Pressepatron plus Radiopatron plus Online-Patron sind keine vier separaten Verträge, sondern eine Veranstaltung mit variantenreichen Paketen pro Stufe. Eventbrite handhabt das schwach — die Plattform erzwingt einen starren Rollenkatalog, der nicht zu realen Hierarchien medialer Partnerschaft passt.

Drittens: Medien-Regeln. „Wyborcza” veröffentlicht Vorschauen nur 21 Tage vor dem Event, „Forbes” verlangt ein exklusives Interview mit einem Sprecher, ein regionaler Radiosender braucht einen fertigen MP3-Spot. In einem generischen Werkzeug bekommt jedes Medium dasselbe Briefing. Im echten Patronatsmanagement hat jeder Partner eigenen Rhythmus, Format und eigene Deliverables-Checkliste. Wir brauchten ein System, das diese Regeln nativ versteht — nicht eines, das sie über Tabellenkommentare umgeht.

Viertens: Patronatswert in EAV (Equivalent Advertising Value) abrechnen, nicht in Tickets. Ein Medienpatron kehrt zum Veranstalter zurück, der ihm 4-6× Wert in Form von Veröffentlichungen, Vor-Ort-Präsenz und Post-Event-Daten zurückgegeben hat. Nicht zu einem, der ihm ein Ticketkontingent gegeben hat. Wertabrechnung ist Fundament der Patronatserneuerung. Praktisch bedeutete dies ein anderes Datenmodell als typische Event-SaaS: Medium als Erstrang-Objekt mit ROI-Historie, Veranstaltung als Container.

Venture Builder vs. Software House — was Scale-ups wählen

Dimension	Software House	Venture Builder
Abrechnungsmodell	Stunden- / Scope-Rechnung	Reduzierte Pauschale + Equity an der Gesellschaft
Entscheidungshorizont	Bis zur Projektabnahme	5+ Jahre, gemeinsame P&L
Optimierung auf	Scope und Budget	Retention, MRR, ARR
Wer trägt das Produktrisiko	Kunde	Beide Seiten — Anteilseigner
Feature-Entscheidung	„Kunde fragt, wir bauen”	„Bewegt das die Retention?”
Was passiert nach Deploy	Rechnung, stündlicher Support	Team bleibt — es ist ihre Firma
Partnerprofil	Jeder mit Budget	Branchenexperte + Distribution + Skala

Scale-ups mit Distribution zum Start (Liste von 30+ befreundeten Nutzern, Pilotverträge auf Konferenzen, Nischenvalidierung) wählen Venture Builder, weil Scope-Disziplin und gemeinsame Upside 24 Monate auf 12 komprimieren. Der Rest — Software House, Rechnung, klare Grenze. Den vollständigen Rahmen haben wir in den Venture-Builder-Services beschrieben.

Modell: Venture Building, kein Auftragsprojekt

Die Klientin kam mit einer Idee, zwölf Jahren Erfahrung in PR und Eventkommunikation und einer Liste von 30 befreundeten Branchenveranstaltern, die versprochen hatten, das Produkt zu testen. Wir kamen mit Technologie, Erfahrung im Aufbau und Skalieren von SaaS und der Geschäftsarchitektur, die wir bei 11 anderen Produkten im Ökosystem Do More Soft Venture Builder gelernt haben.

Wir hätten das Projekt als kundenspezifische Software beziffern können — etwa 380.000-420.000 PLN für das MVP plus Wartung. Wir hätten es im T&M-Modus mit zweimonatigem Puffer und gewöhnlicher Rechnung machen können. Wir hätten einen klassischen Fixed Price mit Vertragsstrafen bei Verzug vorschlagen können. Wir hätten sogar ablehnen können, weil der polnische Eventmarkt kleiner ist als die meisten Ideen, die auf unserem Schreibtisch landen.

Stattdessen schlugen wir eine Gesellschaftsstruktur vor, in der wir Mitgesellschafter wurden und unsere Vergütung für die ersten 12 Monate auf die Deckung der Kernteam-Kosten reduziert wurde. Die Differenz zwischen Marktbewertung und tatsächlich ausgezahltem Betrag wurde unsere Equity-Investition.

Das ist eine Entscheidung, die alles ändert. Ein Software House optimiert auf Projekt-Scope und Budget. Ein Venture Builder optimiert auf Retentionskennzahlen, MRR und ARR. Du baust keine Features auf Vorrat, weil jede überflüssige Stunde den Wert deiner Investition mindert. Du ignorierst kein Nutzerfeedback, weil das deine Kunden sind. Du gehst nicht weg, nachdem die Rechnung bezahlt ist, denn es gibt keine Rechnung — nur eine gemeinsame P&L. Skin in the Game ist kein Slogan, sondern ein Werkzeug der Scope-Disziplin.

Bauphasen — vom Konzept zu 200 Veranstaltungen

Der gesamte Zyklus — vom ersten Gespräch mit der Klientin bis zu 200 betreuten Veranstaltungen — dauerte 12 Monate. Wir teilten ihn in vier disjunkte Phasen mit klaren Übergangskriterien.

Phase 1: Discovery (4 Wochen)

Vier Wochen mit Veranstaltern und Medien, bevor die erste Codezeile fiel. 22 Interviews — mit Kommunikationsmanagerinnen von Branchenkonferenzen, mit Sektion-Redakteuren bei Portalen, mit Marketingdirektoren regionaler Medien. Jedes Interview waren zwei Stunden Workflow-Beobachtung plus eine Stunde strukturierter Fragen.

Aus diesen 22 Interviews ging etwas hervor, das wir in keinem Pre-Discovery-Brainstorm angenommen hätten: Kommunikationsmanagerinnen brauchen keine „bessere Event-Plattform”. Sie brauchen ein System, das ihnen die Rolle der lebenden API zwischen 47 Redaktionen abnimmt. Diese eine Beobachtung definierte die Architektur — und schnitt drei Module aus der Roadmap, die vorher selbstverständlich schienen.

Das Ergebnis war in einer anderen Dimension überraschend. Die drei größten Schmerzpunkte betrafen weder das Ticketing selbst noch die Event-Website. Der erste war Kanalfragmentierung in der Kommunikation mit Patronen (Mail + Messenger + externer Slack + WeTransfer + Telefon). Der zweite — fehlende Echtzeit-Sicht auf den Status patronaler Materialien (der Veranstalter weiß nicht, ob „Wyborcza” die Vorschau schon verschickt hat, ob sie im Redaktionspuffer liegt oder ob die Redaktion auf ein korrigiertes Foto wartet). Der dritte — fehlende harte Daten zur Abrechnung des Patronatswerts post-Event (wie viele Personen aus welchem Medium kamen, wie viele Veröffentlichungen erschienen, wie hoch die Gesamtreichweite gegenüber dem Marktwert des Pakets war).

Diese Erkenntnis definierte die Produktarchitektur. DailyHair sollte keine „Ticketing-Plattform” sein — es sollte ein operatives System für Patronatsmanagement und Kommunikation rund um eine Veranstaltung sein. Dieses Reframing sparte uns drei Monate Arbeit an einem Umfang, der für Nutzer keine Bedeutung gehabt hätte. Unser Discovery-Prozess ist ein Filter — und dieses Mal funktionierte er wie geplant.

Phase 2: MVP (8 Wochen)

Acht Wochen für drei Dinge: Medienpatronatsverwaltung (CRUD für Partner, Pakete, Deliverable-Deadlines), Materialcenter (Briefings, Assets, Entwürfe, Freigaben) und Status-Dashboard (wer was, bis wann, in welchem Status). Kein Ticketing. Keine Mobile App. Keine Analytik außerhalb der grundlegenden Produktmetriken. Keine Integrationen mit externen Kommunikationswerkzeugen.

Acht Wochen sind kein Tempo — sie sind ein Filter. Wenn es dir in dieser Zeit nicht gelingt, Nutzern etwas zu liefern, das sie bewerten können, hat das Projekt ein strukturelles Problem — entweder im Scope, in der Architektur oder im Team. Bei DailyHair passte der Scope in acht Wochen, weil wir alles abschnitten, was nicht für den ersten realen Test mit einer Konferenz unverzichtbar war.

Den Stack wählten wir pragmatisch: React im Frontend, Node.js mit Express im Backend, PostgreSQL als Datenbank, Deployment auf AWS ECS mit S3 für Patronats-Assets (Logos, Fotos, Banner, Audio-Dateien für Radiospots). Keine Technologieexperimente, kein Overengineering. Ziel war der erste reale Nutzer, nicht eine Plattform für zehn Jahre.

Phase 3: Pilot (3 Monate)

Acht Branchenkonferenzen im ersten Quartal 2025 — von kameralen Tech-Meetups in Krakau (200-400 Teilnehmer) bis zu zwei großen Marketingkonferenzen in Warschau (1500-2000 Teilnehmer), darunter die erwähnte Cupra-Konferenz mit 47 Medienpartnern. Jede Veranstaltung mit direktem Onboarding, das die Co-Gründerin des Produkts persönlich leitete. 48-Stunden-Feedback-Loop — jede gemeldete Anmerkung erhielt innerhalb von zwei Werktagen eine Antwort (auch wenn sie „das machen wir nicht” lautete), und eine von fünf landete im Backlog mit einer Wochenpriorität für die Implementierung.

Der Pilot deckte drei Dinge auf, die wir durch keine Menge an Discovery vorhergesehen hätten. Die erste: Kommunikationsmanagerinnen wollen sich nicht in die Plattform einloggen, um Materialien freizugeben — sie wollen über einen Link in einer Mail freigeben, ohne Konto. Das stellte unsere UX-Annahmen auf den Kopf und erzwang die Konzeption eines „Magic-Link-Approval-Flows” für Patronen. Die zweite: Veranstalter wollen das gesamte EAV (Equivalent Advertising Value) aller Patronate live sehen, nicht erst im Post-Event-Bericht — denn das ist Argument für kommerzielle Sponsoren zur Aufstockung ihres Vertrags. Die dritte: Redakteure in Medien verlangen vom Veranstalter fertige „Press-Kits” innerhalb von 24 Stunden nach Patronatsbestätigung — die frühere MVP-Version hatte diesen Flow nicht, wir lieferten ihn im dritten Pilotsprint nach.

Drei Monate Pilot waren die wertvollste Investition im gesamten Projekt. Ohne sie hätten wir ein Produkt skaliert, das nicht auf reale Nutzerbedürfnisse antwortet.

Phase 4: Skalierung (6 Monate)

Von acht Pilotveranstaltungen zu 200 betreuten. In dieser Phase starteten wir eine Mobile App in Flutter (eine Codebasis für iOS und Android) für Onsite-Eventmanager, Integration mit Google Calendar und Outlook zur Synchronisation patronaler Deadlines, automatische Post-Event-Reports im PDF für jeden Patron und Integration mit Medienmonitoring-Plattformen (Press-Service, Newspoint) zum automatischen Zählen von Veröffentlichungen. Wachstum verlief in zwei Kanälen: Word-of-Mouth zwischen Veranstaltern (im Schnitt verwies jede betreute Veranstaltung 1,7 weitere Veranstalter im ersten Quartal nach dem Event) und ein Empfehlungsprogramm unter Kommunikationsmanagerinnen (eine Managerin, die den Arbeitgeber wechselte, brachte ihre DailyHair-Erfahrung mit und bewarb die Plattform natürlich beim neuen Veranstalter).

Über sechs Monate Skalierung gaben wir keinen Złoty für bezahlte Werbung aus. Word-of-Mouth-ROI war so hoch, dass jede Ausgabe für Paid Marketing suboptimal gewesen wäre — verglichen mit der Investition in Onboarding-Qualität und Support-Antwortzeit. Diese Entscheidung erforderte Disziplin — der Druck „lasst uns auf LinkedIn werben” kehrte monatlich zurück — aber die Mathematik rechtfertigte es nicht.

Technologie als Hebel, nicht als Ziel

Der Tech-Stack von DailyHair sind bewusst konservative Entscheidungen. React, Node.js und PostgreSQL ist die Kombination, in der das Team die meiste Expertise hat und das Bibliotheks- und Tooling-Ökosystem am tiefsten ist. Wir suchten keinen Vorteil in der Technologieebene — wir suchten Vorteil in Liefertempo und UX-Qualität. Denselben Entscheidungsrahmen wandten wir in der Cupra mycarapp an, in der die Technologieebene unsichtbar bleiben sollte und das Produkt an Retention gemessen wurde.

Magic-Link-Approval (statt vollständigem Login für Patronen) ist eine Entscheidung, die die größte Reibung in der Adoption durch Medien entfernte. Ein Redakteur erhält einen Link in einer Mail, klickt, gibt das Material frei oder lehnt mit Kommentar ab, fertig. Wir sparten so mindestens drei Monate Arbeit am Rollen- und Berechtigungssystem und steigerten gleichzeitig die Patronen-Antwortrate von ~40 Prozent auf über 80 Prozent im ersten Quartal.

Flutter statt nativer iOS- und Android-Apps ist eine mathematisch begründete Entscheidung: eine Codebasis, ein Mobile-Team, ein Iterationstempo. Wir verlieren etwa 15 Prozent nativer UI-Perfektion, gewinnen den doppelten Entwicklungszyklus und die halben Wartungskosten. In der Wachstumsphase mit 40 Prozent monatlich ist Tempo wichtiger als native Perfektion.

AWS S3 für Patronats-Assets ist offensichtlich — Storage ohne Infra-Eigentum, eingebautes CDN (CloudFront), marginale Kosten pro Event. Dasselbe Argument: baue keine Infrastruktur, die du nicht bauen musst. Die detaillierte Stack-Auswahl-Logik haben wir im Kontext kundenspezifischer Software beschrieben — es ist derselbe Entscheidungsrahmen, den wir in jedem Venture-Building-Projekt anwenden.

Erstes Jahr — was funktionierte, was nicht

Eine brutal ehrliche Abrechnung über 12 Monate.

Was funktionierte. Word-of-Mouth zwischen Veranstaltern erwies sich als deutlich stärkerer Kanal, als wir angenommen hatten — die Eventbranche ist dicht vernetzt, Kommunikationsmanagerinnen kennen sich persönlich, und eine Empfehlung von einem befreundeten Veranstalter wiegt mehr als Case-Study und Demo zusammen. Das Materialcenter mit Magic-Link-Approval — ein Feature, das die Konkurrenz überhaupt nicht hatte — wurde zum Hauptverkaufsargument; über 70 Prozent der Veranstalter erklärten in einer Umfrage nach dem ersten Event, dass gerade diese Funktionalität die Entscheidung für DailyHair ausgemacht hat. EAV-Post-Event-Reports liebten Marketingdirektoren — sie deckten den Bedarf an hartem Beweis für den Wert eines Medienpatronats, den kein anderes Werkzeug liefert (eine händisch nach dem Event ausgewertete Excel-Tabelle überzeugt niemanden).

Was nicht funktionierte. Die erste Version der Patronen-E-Mail-Benachrichtigungen hatte eine Open-Rate von 24 Prozent — deutlich unter B2B-Benchmark. Nach Analyse stellte sich heraus, dass das Template wie eine Transactional Notification aus einem SaaS-System aussah, nicht wie eine persönliche Nachricht von einer Kommunikationsmanagerin. Wir gestalteten die Templates ins „persönliche E-Mail mit Link”-Format um, Open-Rate sprang auf 62 Prozent. Erstes Try-and-Buy für kleine Events (bis 300 Teilnehmer) mit dem ersten Event gratis generierte keine Konversionen — es zeigte sich, dass dieses Segment zu wenige Medienpatrone hat (1-2 pro Event), als dass das Werkzeug Sinn ergäbe. Wir zogen diesen Plan zurück und konzentrierten uns auf Events ab 8 Patronen aufwärts. Der teuerste Misserfolg war der Cross-Sell-Versuch zu Full-Service-Eventagenturen — andere User-Persona (Account Manager, der gleichzeitig 5 Events bearbeitet), anderes Preismodell, Per-Seat-Pricing statt Per-Event. Nach zwei Monaten zogen wir uns zurück und parkten dieses Segment in einer separaten Produktlinie. Kosten dieser Lektion: etwa sechs Wochen Teamarbeit plus Opportunitätskosten.

Metriken nach 12 Monaten

Drei dieser Zahlen sind Scope-Disziplin, eine ist Netzwerk-Distribution. Skalierung ohne Rescue-Modus mitten im Jahr — weil nichts zu retten war, Entscheidungen fielen wöchentlich, nicht quartalsweise.

40 Prozent Monat zu Monat ist realistisch in den ersten sechs Monaten, wenn die Startbasis niedrig ist — danach stabilisiert es sich bei 10-15 Prozent monatlich, was bei einer Basis von 200 Veranstaltungen 20-30 neue Events pro Monat bedeutet. NPS 64 unter Eventmanagern ist außergewöhnlich hoch für B2B-SaaS (Branchen-Benchmark liegt bei 30-40) und wir interpretieren ihn als Signal, dass die Plattform real das Problem löst, nicht nur genutzt wird. ARR im Bereich „low 7-stellig” bedeutet ein Niveau, das bei aktueller Kostenstruktur Einheitsrentabilität ergibt — jede neue Veranstaltung hat positive Marge ab erster Nutzung dank Self-Service-Onboarding (anfangs assistiert, heute starten 75 Prozent der Veranstalter ohne Support-Kontakt).

Lektionen für andere Venture Builder

Drei Beobachtungen, die wir aus DailyHair in nachfolgende Projekte des Ökosystems mitnahmen.

Erste: Skin in the Game verändert Entscheidungen auf einem Niveau, das vor Eintritt in dieses Modell schwer vorhersagbar ist. Wenn du Anteilseigner bist, baust du keine Features auf Vorrat, nimmst keine Nebenaufträge an, die das Team ablenken, versprichst keine Deadlines, die du nicht einhalten kannst. Scope-Disziplin entsteht aus der Vertragsstruktur selbst, nicht aus guten Absichten.

Zweite: Industry-Specific gewinnt immer gegen Generic, wenn die Branche groß genug ist. Der polnische Markt für Branchenveranstaltungen und Konferenzen umfasst über 8.000 aktive Events jährlich, davon betreuen etwa 1.500 Medienpatronate in einem Maßstab, der eine Plattform rechtfertigt. Wenn du 15 Prozent bedienst, hast du 200+ SaaS-Kunden — eine Größe, bei der ein Industry-Specific-Produkt bessere Stückkosten als ein generisches Werkzeug mit großer Basis und niedrigem ARPU hat. Dieselbe Gleichung gilt in jeder großen Vertikalbranche: Legaltech, Automotive, Medtech, Real Estate.

Dritte, die schwerste: MVP in 8 Wochen ist kein Start, sondern ein Filter. Wenn das Team nicht in der Lage ist, Nutzern in acht Wochen eine Testversion zu liefern, liegt das Problem nicht in der Zeit — es liegt im Scope, in der Architektur oder im Team. Das Framework MVP in 8 Wochen ist kein Tempoversprechen; es ist ein Werkzeug der Verifikation, ob ein Projekt überhaupt eine Skalierungschance hat.

Was kommt als Nächstes für DailyHair

Die nächsten 18 Monate haben eine Logik, keine Checkliste. Der polnische Markt für Branchenveranstaltungen nähert sich der Adressierbarkeitsgrenze bei der aktuellen Wertversprechen — 200+ Kunden sind bereits 13% Nischenanteil, und die marginale Akquisekostenkurve wird steigen, wenn wir nicht einen der drei Vektoren ändern. Daher die Reihenfolge.

Geographische Expansion ist zuerst, weil die Unit Economics von DailyHair stark sind (positive Stückmarge ab erstem Event) und der DACH-Markt 2,3× höheren ARPU als der polnische bei derselben Patronatsstruktur aufweist. Q3 2026 — Deutschland und Österreich, Q4 2026 — Tschechien, Ungarn, Rumänien. Vor jedem Eintritt geht ein Discovery vor Ort voraus, denn das polnische Playbook ist nicht 1:1 übertragbar: der deutsche Markt für Branchenkonferenzen hat eine stärkere Präsenz vertikaler Medien (Heise, c’t, Computerwoche) und einen anderen Veröffentlichungsrhythmus als der polnische.

Neue Segmente — Kulturfestivals und B2B-Messen — sind Erweiterung der bestehenden Plattform ohne Änderung der Core-Architektur. Festivals wegen längerem Patronatszyklus (3-6 Monate statt 4-8 Wochen) und größerem Gewicht regionaler Medien. Messen wegen des Sponsorenstand-Verwaltungsmoduls, das 70% Logik mit dem Medienpatronatsmodul teilt. Beide Pfade sind günstiger als der Eintritt in einen neuen geografischen Markt, liefern aber geringeren marginalen ARR.

Die Datenebene als Produkt — das ist der Hebel. Bei 200+ Veranstaltungen verfügen wir über anonymisierte Daten zu Markttrends im Medienpatronat (Durchschnittspaketwerte pro Branche, Veröffentlichungs-Deadlines nach Medientyp, Retentionsraten medialer Partner zwischen Event-Editionen). Ein Asset, das mit angemessener Produktverpackung zu einem zweiten Einnahmestrom wird: Branchenreport für Eventagenturen, Benchmarks für neue Veranstalter, Referenzdaten für Medien, die Patronatspakete bewerten. Die Marge dieses Produkts wäre anständig, weil die Daten bereits existieren — die Kosten sind Distribution und Wartung der Reporting-Ebene.

Diese drei Vektoren starten wir parallel, nicht sequenziell. Sequenz ist das Privileg von Startups mit 36-Monats-Runway. Wir haben eine P&L und Konkurrenz, die noch nicht auf unseren Lead reagiert hat, aber innerhalb von 12-18 Monaten reagieren wird.

Hast du ein Produkt und suchst einen Partner, keinen Vendor?

Wenn du Branchenerfahrung hast, ein lösenswertes Problem und bereit bist, Risiko mit einem kompetenten Technologiepartner zu teilen, statt eine Stundenrechnung auszustellen — sprechen wir über Venture Building. Beschreibe das Projekt im Konfigurator oder schreibe direkt an office@domoresoft.com mit dem Betreff „Venture building partnership”. Scoping dauert 2-4 Wochen, das erste Gespräch ist kostenlos, aber nicht ohne Konkretes. Wenn du das Modell verstehen willst, bevor du dich meldest, lies, wie Do More Soft zum Venture Builder wurde und schau auf die Seite Über uns.

FAQ

Was ist Venture Building in Software? Ein Partnerschaftsmodell, in dem das Tech-Team Anteile an der Produktgesellschaft übernimmt im Tausch gegen einen reduzierten Satz, der die Grundkosten deckt. Skin in the Game verändert jede Scope-Entscheidung — denn jede unnötige Arbeitsstunde mindert den Wert der eigenen Investition.

Wie lange dauert ein SaaS-MVP? Acht Wochen für den Scope eines einzelnen Problems mit klarem Validierungsfilter. Das ist kein Tempo, das ist ein Filter — wenn das Team nicht in 8 Wochen liefert, liegt das Problem im Scope, in der Architektur oder im Team.

Was unterscheidet ein Software House von einem Venture Builder? Ein Software House optimiert auf Scope und Budget, nimmt die Rechnung und geht. Ein Venture Builder optimiert auf Retention, MRR und ARR, ist Anteilseigner, bleibt 5+ Jahre. Dieser Unterschied filtert 90% der Vorschläge, die auf unserem Schreibtisch landen.

Wie viel Equity behält man in einer Venture-Building-Partnerschaft? Die Mehrheit — typisch 60-75% für den Branchenpartner, der Rest für das Tech-Team. Die Verhältnisse hängen von Produktphase, Technologierisiko und operativem Beitrag ab. Bei DailyHair haben wir den Satz um ~40% der Marktbewertung reduziert im Tausch gegen Anteile.