[Inhaltsverzeichnis]Inhaltsverzeichnis anzeigen
2016, mit Krzysztof P., Cupra-Händler in Krakau, auf einer Serviette: VIN-Tracker für 200k PLN in Excel. So begann Do More Soft. Heute: 12 eigene Produkte, ein Team von über einem Dutzend Spezialisten und mehr als 80 abgeschlossene Projekte. Der Weg verlief nicht linear — und gerade deshalb lohnt es sich, ihn zu erzählen.
Anfänge: Automotive als Überlebensschule
Das erste ernsthafte Projekt: ein System für einen Autohändler. Fabrikintegration, VIN-Tracking, Finanzierungsrechner. Die Automobilbranche brachte uns zwei Lektionen bei: komplexe Geschäftsprozesse verlangen tiefes Domänenverständnis, und Kunden wollen keine „Software”. Sie wollen die Lösung ihres Problems. Diese Lektion definiert uns bis heute.
Die ersten 18 Monate: wir lieferten Projekte ab, das Geld war knapp, wir wussten nicht, was der Kunde mit dem Code anstellt. Es fühlte sich wie ein Misserfolg an, obwohl die Rechnungen Erfolg zeigten. Lineares, vorhersehbares Modell, aber begrenzt. Uns fehlte das Gefühl des Miteigentums an dem, was wir bauten.
Wendepunkt: die Entscheidung für eigene Produkte
2020 hatte ich ein Dilemma. Entwickler einstellen und Stunden verkaufen — oder ein Produkt bauen. Die Entscheidung fiel von selbst, als wir eine Ausschreibung über 300k PLN um Haaresbreite verloren. Damals begannen wir, eigene Produkte zu bauen. Nicht weil wir keine Kunden hatten. Sondern weil wir bei vielen Firmen wiederkehrende Probleme sahen und wussten, dass wir sie systematisch lösen können.
Riskanter Schritt. Eigene Produkte zu bauen verlangt Investition von Zeit, Geld und Energie, die sonst in kommerzielle Projekte geflossen wäre. Aber es gab uns etwas, das kein Auftragsprojekt liefern kann: Skin in the Game. Wer ein Produkt baut, das er selbst warten und weiterentwickeln muss, trifft andere architektonische Entscheidungen als jemand, der den Code abgibt und geht.
Worin unterscheidet sich ein Software House von einem Venture Builder?
Ein klassisches Software House hat einen versteckten Interessenkonflikt: je länger das Projekt dauert, desto mehr verdient es. Ein Venture Builder verdient am Produkterfolg, nicht an Stunden, die im Projekt verbrannt wurden. Ein fundamentaler Unterschied bei den Anreizen, der jede Entscheidung prägt — von der Technologiewahl bis zum MVP-Scope.
Wenn wir ein Produkt auf eigene Rechnung bauen, müssen wir schonungslos pragmatisch sein. Kein Overengineering, weil es unser Geld ist. Kein Ignorieren von Nutzerfeedback, weil es unsere Kunden sind. Kein Bauen-und-Verlassen, weil es unsere P&L ist. Diese Disziplin überträgt sich auf Kundenprojekte. Wir haben gelernt, wie Eigentümer zu denken, nicht wie Subunternehmer.
Venture Builder vs. Software House: die entscheidenden Unterschiede
| Dimension | Software House | Venture Builder |
|---|---|---|
| Umsatzmodell | Rechnungen für Stunden | Produkt-Miteigentum, Equity, Success Fee |
| Entscheidungshorizont | Bis zur Projektübergabe | 3-5 Jahre Produktivbetrieb |
| Architektur | Für Demo und Abnahme | Für Wartung und Skalierung |
| Schätzungen | Optimistisch (Tendergewinn) | Realistisch (wir haben Ähnliches gebaut) |
| Scope-Entscheidungen | „Kunde will es, wir bauen es” | „MVP oder Nice-to-have?” |
| Skin in the Game | Endet beim Deployment | Drei Jahre nach Deployment |
12 Produkte — was wir bauen und warum
MoreSales entstand aus Erschöpfung. MyCarApp, weil wir Händler von Cupra gelernt haben. OpenEZD, weil mich die öffentliche Verwaltung persönlich gequält hat. So entstehen die meisten Produkte im Ökosystem: nicht aus einem Research-Deck, sondern aus einem Schmerz, den jemand von uns aus der Nähe gesehen hat.
Das Ökosystem umfasst MoreSales und MoreCRM (CRM/ERP), Branchenplattformen — MyCarApp für Automotive, DailyHair für Beauty, CalMedic für MedTech, Kwadracik für Immobilien — Dokumentenfluss (OpenEZD, MoreGenerator), KI und Content (Textio) sowie die Tools MoreNFC, MoreMobile und GetMeCon.
DailyHair ist ein gutes Beispiel für Venture Building in der Praxis. Die Beauty-Branche brauchte ein Buchungssystem, das kein generisches Booksy ist. Ein System, das die Eigenheiten von Friseursalons und Barbershops versteht. Wir haben es gebaut, in Pilotsalons ausgerollt, anhand von Feedback iteriert und skalieren es als eigenständiges Produkt.
Was bedeutet Skin in the Game in Software-Partnerschaften?
Ein Kunde, der zu einem Software House kommt, bekommt ein Team, das Code geschrieben hat. Ein Kunde, der zu einem Venture Builder kommt, bekommt ein Team, das eigene Produkte gebaut, gestartet, gewartet und skaliert hat. Der Unterschied liegt in der operativen Erfahrung. Wir wissen, was nach dem Deployment passiert, weil wir von dem leben, was wir ausgeliefert haben.
Konkret heißt das: realistische Schätzungen (wir haben ähnliche Systeme auf eigene Rechnung gebaut, wir wissen, wie lange was dauert), Architektur für Wartung statt für Demos (wir warten Produkte selbst über Jahre) sowie pragmatische Scope-Entscheidungen (wir wissen, was MVP ist und was Nice-to-have, weil wir dieselben Entscheidungen für uns selbst vielfach getroffen haben).
Lehren aus einem Jahrzehnt des Bauens
Erste Lektion: Perfektion ist der Feind der Lieferung. Lieber solide 80% ausliefern als perfekte 100%, die nie in Produktion gehen. Zweite: Technologie ist ein Hebel, kein Selbstzweck. Den Kunden interessiert nicht, ob du React oder Vue nutzt. Ihn interessiert, ob das System sein Problem löst. Dritte: Das Team ist wichtiger als der Stack. Ein guter Entwickler in durchschnittlicher Technologie liefert bessere Ergebnisse als ein durchschnittlicher Entwickler in der neuesten.
Die schwierigste Lektion: Nein sagen. 2023, ein Kunde mit 500k Budget für ein Logistik-SaaS. Ich sagte nein. Wir haben keinen Domain Expert, wir haben keine Referenzen. Ein schlecht gewähltes Projekt kostet mehr als kein Projekt. Harte Lektion für ein Unternehmen, das wachsen will, und entscheidend für ein Unternehmen, das klug wachsen will.
Vision: was kommt als Nächstes
Wir wollen nicht das HR für Software sein. Wir wollen Produktbetreiber sein, die wissen, was im dritten Jahr passiert, weil wir längst dort sind. Modell: Venture Builder, der Risiko und Gewinn mit Partnern teilt, statt Rechnungen für Stunden zu stellen.
In den nächsten zwei Jahren wollen wir das Ökosystem auf 15-18 Produkte ausbauen, stärker in die DACH- und CEE-Märkte eintreten und eine Technologieplattform aufbauen, die es erlaubt, neue Produkte schneller zu starten — mit einer gemeinsamen Schicht für Authentifizierung, Zahlungen, Analytics und Infrastruktur. Wir bauen kein Software House. Wir bauen eine Maschine zur Schaffung digitalen Werts.
FAQ
Wie unterscheidet sich das Venture-Builder-Modell von klassischer Entwicklung?
Klassische Entwicklung sind Rechnungen für Stunden. Ein Venture Builder verdient am Produkterfolg — über Miteigentum, Equity oder Success Fee. Das verändert jede Entscheidung: vom Stack bis zum MVP-Scope, von der Architektur bis zum SLA.
Warum treffen Venture Builder bessere architektonische Entscheidungen?
Weil sie selbst mit den Konsequenzen leben. Ein Software House liefert Code ab und stellt die Rechnung. Ein Venture Builder pflegt das Produkt drei Jahre nach dem Deployment, also baut er nichts, was er nicht selbst pflegen will. Entscheidungen sind pragmatisch, nicht zur Schau gestellt.
Arbeitet Do More Soft auch im Auftragsmodell?
Ja, aber selektiv. Wir nehmen Projekte an, in denen wir Know-how aus eigenen Produkten einsetzen können — Automotive, Beauty, MedTech, GovTech, Immobilien. Projekte nach dem Motto „egal was, Hauptsache ein Entwickler” lehnen wir ab.