Bootstrap statt VC: Wie wir propgen zu zweit bauen — und was Kunden davon haben
Werkstattbericht aus dem propgen-Team: Warum wir komplett aus Eigenmitteln finanzieren, wie zwei Personen mit KI-Tools das leisten, was vor zwei Jahren ein 30er-Team gebraucht hätte — und welche Grenzen wir nicht beschönigen.
propgen ist seit Januar 2026 in den ersten Maklerhäusern produktiv. Wir sind zu zweit — Robert als propgen Gründer dabei, der Rest des Teams ist Software. Und genau so soll es bleiben, bis das Kundenvolumen etwas anderes verlangt. Das ist kein Notbehelf, sondern eine Entscheidung mit klarer Logik dahinter.
Warum kein VC
Sieben Jahre als CEO eines etablierten Makler-CRMs haben mich gelehrt, was Investoren-Kapital in einem Software-Geschäft bedeutet — und was es kostet. Es bedeutet Wachstum, das in der Bilanz sichtbar werden muss. Es bedeutet Quartalsmetriken, die in Entscheidungen schwerer wiegen als die Frage „Was hilft dem einzelnen Kunden im Alltag?". Und es bedeutet, dass Entscheidungen, die in fünf Jahren richtig wären, in fünf Monaten begründet werden müssen.
Bei propgen wollte ich das nicht reproduzieren. Nicht aus Romantik, sondern weil das Produkt nur dann wirklich gut wird, wenn die Entscheidungen, die es prägen, in einer langen Zeitachse gedacht werden dürfen. Welche Funktion bauen wir? Welchen Kunden nehmen wir an, welchen lehnen wir ab? Wenn diese Antworten von einer nächsten Funding-Runde getrieben werden, optimiert das Produkt nicht für die Praxis. Es optimiert für die Pitch-Story.
Komplett aus Eigenmitteln finanziert bedeutet: Robert und ich entscheiden, was richtig ist, und tragen die Folgen selbst. Kein Board, kein Term-Sheet, kein Exit-Druck. Heute ist die Frage nicht, ob man Geld braucht — sie ist, wofür. Und für die Art Produkt, die wir bauen, ist die Antwort: für nichts, das wir nicht aus dem laufenden Geschäft selbst tragen können.

„Werden die Entscheidungen von der nächsten Funding-Runde getrieben, optimiert das Produkt nicht für die Praxis — es optimiert für die Pitch-Story."
Warum zwei Personen heute reichen
Vor zwei Jahren hätte propgen ein Team aus rund 30 Menschen gebraucht — Frontend, Backend, KI/ML, Produkt, Design, QA, DevOps, Customer Success, Sales, Marketing, Support. Heute reichen zwei — vorerst. Der Hebel ist nicht heroischer Arbeitseinsatz, sondern dass moderne KI-Tools einen großen Teil dessen übernehmen, wofür früher dedizierte Rollen nötig waren.
Konkret: Ich schreibe Code mit einem KI-Coding-Assistenten als Pair-Programmer. Der Assistent recherchiert Bibliotheken, schreibt Erstentwürfe, prüft Sicherheits-Aspekte, fängt Konventions-Brüche im Code. Was menschlich bleibt: Architektur-Entscheidungen, das Review, das Urteil, ob ein Vorschlag wirklich zur Codebasis passt — und das Verständnis dafür, was Makler im Alltag eigentlich brauchen. Die Distanz zwischen Idee und produktivem Code hat sich auf ein Niveau verkürzt, das vor zwei Jahren ein größeres Team gebraucht hätte. Wer das im eigenen Arbeiten nicht erlebt hat, wird es uns nicht abnehmen — wer es erlebt hat, weiß genau, was ich meine.
Robert macht das Gegenstück: Kunde, Branche, Roadmap-Validierung. Er steht in hunderten Maklergesprächen pro Jahr, betreibt seit zwei Jahren einen monatlichen Makler-CRM-Vergleich, und ist als Juror beim Deutschen Immobilienpreis tief in den realen Anforderungen der Branche. Jede Roadmap-Entscheidung bei uns wird daran gemessen, ob sie diese Realität trifft. Ein interner Maßstab, der schwer durch ein Sales-Team zu ersetzen wäre.
Zusammengefasst: Wir denken und prüfen — KI setzt um. Die gleiche Aufgabenteilung, die wir Maklern für ihren eigenen Alltag empfehlen, ist die Grundlage unseres eigenen Bauens.
Wie wir die Rollen verteilen
Ein zwei-Personen-Team funktioniert nur mit klarer Aufgabenteilung. Bei uns sieht das so aus:
Silab (Gründer & CEO). Produkt, Engineering, Architektur, KI-Integration. Verantwortlich für das, was technisch und produktseitig entsteht — mit KI-Coding-Tools als tägliches Tooling.
Robert (propgen Gründer). Kunden, Branche, Positionierung, Vertrieb. Mit seinem Branchen-Netzwerk und der monatlichen CRM-Vergleichs-Disziplin als Quelle. Verantwortlich dafür, dass das, was wir bauen, im Markt wirklich ankommt.
Was wir beide tragen. Kundengespräche, Onboarding der Pilotkunden, strategische Roadmap-Entscheidungen. Wir wollen, dass jedes Maklerhaus, das mit propgen arbeitet, mit beiden von uns gesprochen hat — nicht mit einem Sales-Mitarbeiter, der das Produkt vom Datenblatt kennt.
Was wir bewusst nicht haben. Kein Sales-Team, kein dediziertes Marketing-Team, kein QA-Team, kein Support-Tier. Was ein klassisches CRM-Unternehmen mit dedizierten Teams anstellt, machen wir in dieser Phase selbst — mit KI als stiller Verstärkung in jedem Schritt.
Was wir bewusst nicht tun
Disziplin entsteht durch Knappheit. Wenn ein Team klein ist, wird jede Entscheidung, in welche Aufgabe Energie fließt, automatisch ehrlicher. Drei Dinge, die wir bewusst nicht tun — und wahrscheinlich nicht tun würden, auch wenn wir zehn Personen wären:
Wir nehmen keinen Kunden an, der nicht passt. Lieber sagen wir „aktuell nicht", als ein halbes Jahr in unsinnige Sonderfunktionen zu versinken. Klarheit darüber, mit wem wir arbeiten wollen, ist wichtiger als kurzfristiger Umsatz. Wer mit uns arbeitet, muss zu unserer Art zu bauen passen — und umgekehrt.
Wir verkaufen nicht, was wir noch nicht haben. Die Versuchung, eine fehlende Funktion mit „kommt nächsten Monat" zu überspielen, ist klassisch — und genauso klassisch enttäuscht sie den Kunden. Wir zeigen, was funktioniert, und sagen klar, was noch nicht da ist. Das gehört zu unseren Werten und ist keine Marketing-Floskel.
Wir bauen nicht alles für jeden. Wir bauen kein Marketing-Tool, kein Buchhaltungssystem, keine Maklerverwaltung von A bis Z. Wir bauen das CRM, das eine bestimmte Generation von Maklern wirklich nutzt — und integrieren uns sauber mit dem Rest. Fokus ist die wertvollste Ressource eines kleinen Teams.
Was Kunden davon haben
Bootstrap ist intern eine Entscheidung über Eigentum und Unabhängigkeit. Aber sie wirkt auch nach außen — auf Kunden, die mit uns arbeiten. Vier Punkte, die sich konkret auswirken:
1. Du redest mit denen, die das Produkt bauen. Nicht mit einem Account-Manager, nicht mit einem Sales-Vertreter, nicht mit Support-Tier-1. Wenn du eine Anfrage hast, landet sie direkt bei Robert oder mir. Je nach Thema antworten wir noch am selben Tag — mit dem, was wirklich machbar ist, nicht mit dem, was sich gut anhört.
2. Entscheidungen mit langer Halbwertszeit. Welche Funktion eingebaut wird, welche Datenstruktur wir wählen, welche Integration wir priorisieren — diese Entscheidungen sind nicht durch eine Funding-Runde getriggert. Sie sind durch das getrieben, was Kunden über Jahre tragen müssen.
3. Keine Bewertungs-getriebenen Preissprünge. Bootstrap heißt: Wir müssen nicht plötzlich eine Bewertung rechtfertigen. Kein Quartalsdruck treibt uns dazu, die Marge in einem halben Jahr zu verdoppeln. Was wir verlangen, ist, was die Software tatsächlich braucht — nicht, was ein Investor-Brief verlangt.
4. Roadmap-Stabilität. Bootstrap-Unternehmen werden seltener verkauft, seltener pivotet, seltener auf neue Märkte umgepolt. Was du heute anfängst, ist mit hoher Wahrscheinlichkeit auch in fünf Jahren noch das, was du nutzt.
Wann und wie wir wachsen werden
Bootstrap heißt nicht „für immer zu zweit". Es heißt: Das Wachstum ist kundengetrieben, nicht investor-getrieben. Wir stellen ein, wenn eine konkrete Funktion zur Engstelle wird — nicht, weil ein Pitch-Deck einen „Team von 30" verspricht.
Konkret: Die nächste Rolle wird wahrscheinlich Customer Success / Onboarding sein — sobald wir mehr Häuser haben, als Robert und ich persönlich onboarden können. Danach Engineering, wenn der Backlog an Features wächst, die nicht KI-beschleunigbar sind. Und so weiter. Jede Stelle wird begründet aus dem, was Kunden in akzeptabler Zeit nicht mehr bekommen können — nicht aus einem Wachstums-Narrativ.
Wer Lust hat, dabei zu sein, wenn die Zeit reif ist: Wir haben eine offene Initiativbewerbungs-Tür. Mehr dazu auf der Jobs-Seite.
Was wir nicht beschönigen
Damit kein falscher Eindruck entsteht: Bootstrap als Zweier-Team ist kein Optimum für alles. Drei ehrliche Grenzen:
Wir sind nicht überall gleich schnell. Wenn ein Konkurrent mit 40 Mann ein Feature in zwei Wochen rausschickt, brauchen wir vielleicht vier. Wir kompensieren das mit Auswahl — wir bauen nicht alles, sondern das, was wirklich zählt. Aber auf der reinen Feature-Breite werden wir nie an einem Konzern-CRM vorbei sein.
Wir sind nicht 24/7 erreichbar. Wenn um 23 Uhr in der Maklerverwaltung eine Frage aufkommt, antworten Robert oder ich nicht innerhalb einer halben Stunde. Wir sind ein Zweier-Team in der Aufbauphase — Realität, nicht Marketing-Hülle. Was wir versprechen: Jede Anfrage wird gelesen, und wir antworten persönlich, meist innerhalb von 24 Stunden.
Wir sind abhängig von KI-Anbietern. Unser Tempo basiert darauf, dass aktuelle KI-Modelle zuverlässig verfügbar sind. Wenn ein Anbieter ausfällt oder Konditionen drastisch ändert, betrifft uns das. Wir kompensieren mit Mehrgleisigkeit (mehrere Anbieter, fallback-fähige Integrationen), aber 100% unabhängig sind wir an diesem Punkt nicht — wie ehrlicherweise niemand, der heute KI-nativ baut.
Wer mit propgen arbeitet, sollte diese Grenzen kennen. Wir blenden sie nicht aus — und wer sie nicht tragen kann, ist bei einem etablierten CRM mit größerem Team vermutlich besser aufgehoben. Es ist eine bewusste Wahl, kein versteckter Mangel.
Fazit
Wir bauen propgen zu zweit, weil es heute geht — und weil es das Produkt besser macht. Die Unabhängigkeit, die wir uns selbst leisten, geben wir an die Kunden weiter: kein VC-Druck, keine Quartals-Verzerrungen, keine plötzlichen Strategiewechsel.
Was sich verändert hat, ist nicht, dass zwei Personen plötzlich mehr leisten als früher. Es ist, dass KI-Tools die Distanz zwischen Idee und Umsetzung so weit verkürzt haben, dass das, was früher ein Team gebraucht hätte, jetzt eine Disziplin und einen guten Werkzeug-Stack braucht. Das ist der gleiche Hebel, den wir auch unseren Kunden geben — eingebaut in propgen.
Mehr darüber, wer hinter propgen steht und wie wir arbeiten, steht auf Über uns. Was im Produkt konkret aus diesem Arbeitsmodus entstanden ist, findest du in den Release Notes.