Technischer Mitgründer oder Dienstleister: Was passt zum Startup?
Ein Startup braucht einen technischen Mitgründer, wenn die Software selbst das Produkt ist und laufend neu entschieden wird, was gebaut wird. Für einen klar umrissenen ersten Wurf oder eine Phase mit festem Ende genügt ein Entwicklungsdienstleister, sofern Code, Zugänge und Nutzungsrechte von Anfang an beim Startup liegen.
Die Frage stellt sich meist früh: Die Idee steht, erste Kunden sind interessiert, vielleicht laufen Gespräche mit Geldgebern, und niemand im Gründerteam programmiert. Dann gibt es zwei Wege. Jemand mit Technikverstand steigt als Gesellschafter ein und trägt das Risiko mit, oder ein Dienstleister baut gegen Bezahlung.
Ein Mitgründer entscheidet mit, was gebaut wird. Ein Dienstleister setzt um, was entschieden ist, und berät dabei. Welches Modell passt, hängt von der Phase des Startups ab. In beiden Fällen müssen die Rechte am Code geklärt sein; dafür enthält dieser Beitrag eine Prüfliste.
Rolle 1 · Mitgründer
Was ein technischer Mitgründer leistet
Ein technischer Mitgründer übernimmt die Rolle, die später ein CTO hat: Er entscheidet über Architektur und Technik, schätzt Aufwände ein, sagt Nein zu Funktionen, die das Produkt nicht braucht, und stellt die ersten Entwickler ein. In Gesprächen mit Geldgebern beantwortet er die technischen Fragen selbst.
Sein Vorteil ist die Nähe zum Produkt. Wenn sich das Geschäftsmodell nach den ersten Kundengesprächen dreht, baut er um, ohne dass ein neues Angebot verhandelt werden muss. Er bezahlt mit Zeit und bekommt Anteile.
Dem stehen Nachteile gegenüber. Einen passenden Mitgründer zu finden dauert, und die Anteile sind vergeben, auch wenn sich die Zusammenarbeit als Fehlgriff erweist. Steigt er aus, gehen Wissen und oft ein Teil der Anteile mit. Viele Gründerteams regeln deshalb in der Gesellschaftervereinbarung, wie Anteile über die Zeit erdient werden und was beim Ausstieg passiert. Und ein guter Entwickler ist nicht automatisch jemand, der ein Team führen oder Investoren überzeugen will.
Ein Mitgründer passt, wenn die Software der Kern des Geschäfts ist, also wenn ein SaaS-Produkt verkauft wird, über Jahre wächst und laufend Produktentscheidungen verlangt.
Rolle 2 · Dienstleister
Wann ein Dienstleister die bessere Wahl ist
Ein Dienstleister passt, wenn der Umfang beschreibbar ist und ein Ende hat: ein erster Wurf, mit dem echte Nutzer arbeiten, ein Modul neben einem bestehenden Produkt, eine Schnittstelle. Ebenso, wenn die Software das Geschäft unterstützt, aber nicht selbst verkauft wird.
Ein Beispiel ist die Case Study REST-API und HR-Frontend für ein Münchner Tools-Portal-Startup. Der Auftrag lag in zwei Schichten, zuerst eine REST-API, dann zwei Frontends darauf. Die Case Study nennt rund zehn Monate Auftragszeit mit rund 50 Stunden im Monat. Bei acht Stunden je Personentag sind das gut sechs Personentage im Monat, über zehn Monate rund 62 Personentage. Am Ende stand eine Übergabe an das interne Team mit API-Dokumentation, Testsuite und Protokollen der größeren Architekturentscheidungen, danach blieb der Dienstleister nur für punktuelle Erweiterungen Ansprechpartner.
Das Risiko liegt in der Abhängigkeit. Wenn nur eine Person beim Dienstleister das System kennt, steht das Startup bei deren Ausfall genauso da wie mit einem einzelnen angestellten Entwickler, wie der Beitrag zum Bus-Faktor zeigt. Und wer Hosting, Datenbank und Anmeldung auf proprietäre Dienste eines Anbieters baut, bindet sich zusätzlich an diesen Anbieter. Warum das auch bei Cloud-Diensten gilt, beschreibt Vendor-Lock-in: Auch Cloud ist eine Falle.
Rolle 3 · Mischformen
Interims-CTO, Teamverstärkung und geplante Übergabe
Zwischen beiden Modellen liegen drei Mischformen, die vor allem in Übergangsphasen passen.
Interims-CTO. Eine erfahrene Person übernimmt die CTO-Rolle für eine begrenzte Zeit, meist an einigen Tagen pro Woche: Architektur festlegen, Dienstleister steuern, Bewerber prüfen, den ersten festen Entwickler einarbeiten. Ziel ist die eigene Besetzung. MARCODES bietet diese Rolle als Interims-CTO an; auf unserer Seite zur Projektbegleitung heißt das: „Wir füllen technische Vakanzen interim. Bis Sie besetzt haben.“
Teamverstärkung. Das Startup hat schon Entwickler, braucht aber für eine Etappe mehr Kapazität. Die Case Study FinTech-Backend für eine Versicherungs-App beschreibt so einen Fall: ein Konzern-Startup, das während der Beauftragung in eine eigene Gesellschaft überführt wurde. Über viele Monate, mit wechselndem Umfang, arbeitete Marco Hochmuth im Sprint-Takt des internen Teams mit. Mit Abschluss der Roadmap-Etappe ging die Verantwortung wieder vollständig an das interne Team über, dokumentiert mit Architecture Decision Records und kurzen Übergabenotizen je Modul.
Geplante Übergabe. Ein Dienstleister baut die erste Version, das Startup stellt parallel ein, und die Übergabe ist von Beginn an Teil des Auftrags. Dann gehören Dokumentation, Tests und gemeinsame Arbeitswochen mit dem neuen Team in den Vertrag, nicht in ein späteres Nachtragsangebot.
UrhG § 69b und §§ 31 ff.
Wem der Code gehört, und wie Sie das prüfen
Das Urheberrecht am Code entsteht bei der Person, die ihn schreibt, und ist nach § 29 UrhG nicht übertragbar. Übertragen werden Nutzungsrechte, und hier unterscheiden sich die Modelle deutlich.
Angestellte Entwickler: Nach § 69b UrhG ist bei einem Computerprogramm, das ein Arbeitnehmer in Wahrnehmung seiner Aufgaben oder nach Anweisung schafft, ausschließlich der Arbeitgeber zur Ausübung aller vermögensrechtlichen Befugnisse berechtigt, sofern nichts anderes vereinbart ist.
Dienstleister und freie Entwickler: Für sie gilt § 69b nicht. Das Startup bekommt nur die Nutzungsrechte, die der Vertrag einräumt (§ 31 UrhG). Nennt der Vertrag die Nutzungsarten nicht einzeln, richtet sich der Umfang nach dem gemeinsamen Vertragszweck (§ 31 Absatz 5 UrhG), und das kann enger sein als gedacht.
Gründer ohne Anstellungsvertrag: § 69b spricht von Arbeitnehmern und Dienstverhältnissen. Wer als Gesellschafter mitarbeitet, ohne angestellt zu sein, oder vor der Gründung einen Prototyp geschrieben hat, fällt nicht ohne Weiteres darunter. Eine schriftliche Rechteeinräumung an die Gesellschaft schließt diese Lücke.
Für eine spätere Finanzierung oder einen Verkauf zählt außerdem § 34 UrhG. Nach Absatz 1 kann ein Nutzungsrecht grundsätzlich nur mit Zustimmung des Urhebers an Dritte übertragen werden. Absatz 3 macht eine Ausnahme: Ohne Zustimmung geht das Nutzungsrecht über, wenn das ganze Unternehmen oder ein Unternehmensteil veräußert wird; der Urheber kann es dann aber zurückrufen, wenn ihm die Ausübung durch den Erwerber nach Treu und Glauben nicht zuzumuten ist, und dasselbe gilt bei einer wesentlichen Änderung der Beteiligungsverhältnisse. Werden nur Anteile verkauft, bleibt die Gesellschaft ohnehin Inhaberin der Rechte. Die Ausnahme hilft deshalb nicht in jedem Fall, etwa wenn nur der Code an einen Käufer übertragen werden soll; ein vertraglich vereinbartes Recht zur Weiterübertragung schafft Klarheit. Diese Prüfliste geht die Punkte in der Reihenfolge durch, in der sie im Gründungsalltag anfallen:
Prototyp vor der Gründung: Wer hat ihn geschrieben? Rechte schriftlich an die Gesellschaft einräumen lassen.
Gründer ohne Anstellung: ausschließliche, zeitlich und räumlich unbeschränkte Nutzungsrechte an allem, was für die Gesellschaft entsteht, im Gesellschaftervertrag oder einer eigenen Vereinbarung.
Arbeitsverträge: § 69b greift; ergänzend regeln, was mit Code aus der Zeit vor der Anstellung und aus Nebenprojekten geschieht.
Dienstleistervertrag: ausschließliche Nutzungsrechte für alle bekannten Nutzungsarten, das Recht zur Bearbeitung, das Recht zur Weiterübertragung ohne erneute Zustimmung, Zeitpunkt des Rechteübergangs (zum Beispiel mit Bezahlung) und die Herausgabe des Quellcodes.
Fremdcode: Liste der verwendeten Open-Source-Pakete mit ihrer Lizenz, damit klar ist, welche Pflichten beim Weitergeben gelten.
Repository: Der Code liegt in einer GitHub- oder GitLab-Organisation des Startups, der Dienstleister ist dort Mitglied. Wie das aussieht, zeigt das Projekt KIWI Health: Das dort gebaute Plugin ist im Namespace des Kunden veröffentlicht, sodass der Kunde es weiterentwickeln und weitergeben kann, und die Wartung liegt inzwischen hauptsächlich beim Kunden.
Konten und Domains: Domain, Hosting, App-Store-Konten, Zahlungsanbieter, Mail-Versand und Analyse laufen auf das Startup, nicht auf den Dienstleister oder eine Privatperson.
Zugangsdaten: in einem Passwortmanager des Startups, mit eigenen Zugängen je Person statt geteilter Passwörter.
Übergabefähigkeit: Kann jemand, der das Projekt nicht kennt, anhand der Dokumentation eine neue Version ausliefern? Testen Sie das einmal im Jahr.
Entscheidung
Vier Fragen für die Wahl des Modells
Vier Fragen helfen bei der Entscheidung:
Ist die Software das Produkt? Dann gehört Technik langfristig in den Kreis der Gesellschafter oder in eine feste CTO-Stelle.
Lässt sich der nächste Abschnitt beschreiben? Ein beschreibbarer Umfang mit Ende spricht für einen Dienstleister.
Wer entscheidet in sechs Monaten über die Technik? Steht dafür niemand fest, ist ein Interims-CTO die Brücke.
Liegen Code, Konten und Rechte beim Startup? Diese Frage gilt für jedes Modell.
Ein Startup kann das Modell mehrfach wechseln: erst ein Dienstleister für den ersten Wurf, dann eine CTO-Besetzung, später Teamverstärkung für eine Etappe. Was wir für Softwarehersteller in diesen Phasen bauen, von der ersten Version bis zur mandantenfähigen Plattform, steht auf unserer Seite für Softwarehersteller und SaaS-Startups. Wer früh weiß, dass mehrere Kunden auf einer Installation arbeiten werden, sollte außerdem den Beitrag zur Mandantenfähigkeit lesen, bevor der erste Datensatz gespeichert wird.
Kurz beantwortet
Häufige Fragen
-
Sobald absehbar ist, dass die Software über die erste Version hinaus laufend weiterentwickelt wird und jemand im Haus die Entscheidungen tragen muss. Davor kann ein Dienstleister den ersten Wurf bauen, idealerweise mit einer geplanten Übergabe an die erste feste Stelle. Wer zu früh einstellt, zahlt Gehalt für Wochen ohne klare Aufgaben, wer zu spät einstellt, hängt vom Wissen Externer ab.
-
Der Monatsbetrag ergibt sich aus Personentagen mal Tagessatz. Zwei Tage pro Woche ergeben bei durchschnittlich 4,33 Wochen im Monat rund 8,7 Personentage; beim Standard-Tagessatz von 1.500 Euro netto sind das 8,7 x 1.500 = 13.050 Euro netto im Monat. Ein Umfang wie im Tools-Portal oben, rund 50 Stunden im Monat, sind bei acht Stunden je Tag 6,25 Personentage, also 6,25 x 1.500 = 9.375 Euro netto im Monat. Den tatsächlichen Satz legt das Angebot fest, je nach Art der Arbeit und Einsatz vor Ort. Holen Sie zwei Angebote mit demselben Umfang und derselben Laufzeit ein, damit die Tagessätze vergleichbar sind.
Das passende Modell für die nächste Etappe
Ein paar Sätze zu Produkt, Team und nächstem Abschnitt genügen für ein erstes Gespräch. Darin klären wir, ob ein Dienstleister, eine Teamverstärkung oder eine Interimslösung passt und welche Rechte und Zugänge vorher geregelt sein sollten.
Nachweise
Quellen und Stand
Stand: 24.07.2026. Urheberrechtliche Regeln laut Urheberrechtsgesetz in der Fassung auf gesetze-im-internet.de, Projektangaben laut den verlinkten Case Studies und Projektseiten. Die Hinweise zum Urheberrecht sind keine Rechtsberatung; Verträge über Nutzungsrechte sollte ein Anwalt prüfen.
Weiterlesen: Welche Anforderungen große Kunden an SaaS-Produkte stellen, beschreibt SaaS für Großkunden: SSO, Rollen und Audit-Log einplanen (09.09.2026).
Artikel teilen