18.05.2021

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

Von Lizenzbedingung bis Urheberrecht: Startups treten immer wieder in dieselben rechtlichen Fallen, wenn es um den Code ihres Produkts geht.
/artikel/5-rechtliche-fehler-die-startups-beim-programmieren-vermeiden-sollten
Programmieren, Code, Coding, Startup, Team
© Unsplash

GASTBEITRAG

„Das ist ein wirklich genialer Code, aber das Risiko, das wir uns damit einkaufen ist uns leider zu hoch. Wir haben uns daher für ein anderes Investment entschieden.“ Damit du bei der Verwertung deines Produktes oder einem Exit diesen oder einen ähnlichen Satz nicht hören musst, solltest du aus Legal-Sicht unter anderem die folgenden fünf Fehler beim Coding vermeiden. 

1. Vorsicht beim Einsatz von Open Source. 

Der Quellcode von Open Source Software wird kostenfrei zur Verfügung gestellt. Insbesondere für junge Programmier*innen ist diese daher interessant und wird häufig im eigenen Code integriert, doch hier ist Vorsicht geboten. 

Lizenzen für Open Source Software enthalten oft sogenannte „Copyleft“ Klauseln. Durch solche Klauseln werden Lizenznehmer*innen verpflichtet Bearbeitungen des Quellcodes ebenfalls kostenlos zur Verfügung zu stellen. Die bekannteste Copyleft-Lizenz ist GNU General Public License (GPL)

Wenn du deinen Code also auf Open Source, die zB unter GPL steht, aufbaust, ist der Copyleft Effekt auf deinen Code anwendbar. Du müsstest deinen Quellcode daher kostenfrei zur Verfügung stellen und könntest Schwierigkeiten bei der Verwertung des Codes (zB beim Verlangen von Lizenzgebühren) bekommen.

Key Takeaway: Drum prüfe, wer (Open Source) Code in die eigene Software integriert.  

Don’t forget: Selbstverständlich musst du auch bei bezahlter Software, die Lizenzbedingungen prüfen, um herauszufinden, ob eine Verwertung möglich ist.  

2. Code documentation – mehr als nur „comments“ 

Ja, die Hauptsache ist, dass dein Code funktioniert, aber für Investor*innen oft genauso relevant ist eine exakte Dokumentation des Codes. 

Um potentielle Investor*innen zu beeindrucken, empfiehlt es sich nicht nur comments zum Code hinzuzufügen, sondern die einzelnen Coding-Schritte ausführlicher zu dokumentieren, etwa in einem README file. Abhängig davon, was das Einsatzgebiet deines Codes ist, kann auch eine API Dokumentation angebracht sein. 

Key Takeaway: Documentation is key – auch aus Legal-Sicht.

3. Coding together – ein smarter Move? 

Gemeinsam Programmieren, ob in einem Angestelltenverhältnis oder als Business Partner – was so nett klingt, ist aus Legal-Sicht ohne „Sicherheitsvorkehrungen“ nicht immer ein smarter Move. 

Das Urhebergesetz sorgt zwar grundsätzlich für Programmierer*innen vor, indem es (i) einen urheberrechtlichen Schutz für Computercode vorsieht und (ii) festlegt, dass, wenn Arbeitnehmer*innen für den Dienstgeber codieren, die Nutzungsrechte an dem Programmierten auf den Dienstgeber übergehen… Also alles easy? Leider nicht! 

Das UrhG – und somit auch diese, für den Dienstgeber günstige Stellung gilt nämlich nur, wenn der Dienstnehmer ein Computerprogramm iSd UrhG programmiert. Wird nur ein Teil davon oder nur einzelne Algorithmen programmiert, könnte diese Bestimmung nicht anwendbar sein. In diesem Fall ist es notwendig eine ergänzende Vereinbarung mit dem Mitarbeiter oder der Mitarbeiterin zu treffen (das kann bspw. im Dienstvertrag passieren).  

Wenn du mit deiner Business-Partnerin oder deinem Business Partner gemeinsam codierst, kann es möglich sein, dass ihr beide sogenannte „Miturheber“ des Codes seid. Den Code könntet ihr dann nur gemeinsam verwerten – das solltet ihr jedenfalls bedenken. Bei deiner Geschäftspartnerin oder deinem Geschäftspartner wird das häufig ohnehin so gewollt sein. Rechtlich tricky könnte es werden, wenn dir eine Freundin oder ein Freund beim Codieren maßgeblich hilft und ihr euch bis dahin keine Gedanken über die Zusammenarbeit/Rechte/Verwertung gemacht habt. 

Key Takeaway: Mache dir bereits frühzeitig Gedanken, wer welche Rechte an dem Code haben soll und sichere diese Rechtsposition vertraglich ab. 

4. Achtung im Zusammenhang mit Input-Daten

Für die Entwicklung und das Training von Algorithmen sind Daten erforderlich – nur durch Beispiele kann ein Algorithmus lernen, Muster in Daten zu erkennen.

Abhängig davon, welche Daten du deinem Code fütterst, musst du weitere Bestimmungen beachten. Sobald du zum Training personenbezogene Daten verarbeiten musst, sind die Bestimmungen der DSGVO anwendbar. 

Personenbezogene Daten sind alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen, wie zB Name, Alter, persönliche Vorlieben, E-Mailadresse oder Foto. Häufig ist nicht ganz klar, was alles ein personenbezogenes Datum darstellen kann (etwa hat der Europäische Gerichtshof vertreten, dass in bestimmten Fällen IP-Adressen auch personenbezogene Daten sind). Bevor ihr Daten verarbeitet ist es daher wichtig zu klären, ob diese Personenbezug aufweisen. 

Eine Datenverarbeitung ist nur unter bestimmten Voraussetzungen rechtmäßig, insbesondere bei Einwilligung der betroffenen Person oder zur notwendigen Erfüllung eines Vertrags. Zudem treffen den Verarbeiter umfassende Pflichten (Datenlöschung, Berichtigung, organisatorische Vorkehrungen, etc). Die Nichteinhaltung der DSGVO ist mit hohen Geldstrafen bedroht.

Bereits im Vorfeld der Entwicklung sollte daher berücksichtigt werden, welche Daten durch einen Algorithmus verarbeitet werden und wie die Vorgaben der DSGVO ohne zusätzlichen Aufwand eingehalten werden können (Vertragliche Grundlage, Einholung von Einwilligung, etc). Ansonsten drohen später zusätzliche Kosten durch die nachträgliche Anpassung oder sogar Strafzahlungen.

Key Takeaway: Checke bereits bei der Entwicklung welche Daten du deinem Algorithmus fütterst, um später böse Überraschungen und aufwändiges Umprogrammieren zu vermeiden. 

5. Vertragliche Geheimhaltung

Wie bereits zuvor gesagt, kann es sein, dass dein Code bzw Teile davon (etwa bloße Algorithmen) keinen urheberrechtlichen Schutz genießen; doch auch für solche Fälle gibt’s eine Lösung. 

Programmcodes können nämlich ein „Betriebsgeheimnis“ darstellen und dadurch wettbewerbsrechtlich vor Mitbewerber*innen geschützt sein – doch aufgepasst, auch hier ist es wichtig bereits frühzeitig an den Schutz zu denken. Damit Code ein Betriebsgeheimnis iSd UWG sein kann, muss er folgende Voraussetzungen erfüllen: mangelnde Offenkundigkeit, Geheimhaltungswille und Geheimhaltungsinteresse.

Mangelnde Offenkundigkeit bedeutet, dass Informationen nicht allgemein bekannt sind und auch tatsächlich geheim gehalten werden. Sie dürfen nur einem beschränkten Personenkreis bekannt gemacht werden (zB Arbeitnehmer*innen, Tester*innen). Daher sollten Geheimhaltungsvereinbarungen mit Personen getroffen werden, die Zugriff auf den Code haben, um eine weitere Verbreitung zu verhindern. Häufig reicht eine bloße Geheimhaltungsvereinbarung im Dienstvertrag dazu nicht aus; das ist aber im Einzelfall zu klären. 

Der Geheimhaltungswille muss aus den äußeren Umständen zum Ausdruck kommen. Geheimhaltungsvereinbarungen oder technische Schutzvorkehrungen (Zugangsbeschränkungen, etc) lassen den Geheimhaltungswillen erkennen. 

Vertragliche oder technische Schutzvorkehrungen lassen auch das Geheimhaltungsinteresse erkennen.

Was bringt der Schutz als Betriebsgeheimnis? Die unlautere Verwertung von Betriebsgeheimnissen zu Wettbewerbszwecken ist strafbar. Zusätzlich können gegen Mitbewerber Schadenersatz- und Unterlassungsansprüche geltend gemacht werden. Gerade wenn Codes nicht die Voraussetzungen für urheberrechtlichen Schutz oder ein Patent erfüllen, ist das Wettbewerbsrecht von besonderer Bedeutung. Dafür sollten neben technischen Vorkehrungen auch vertragliche Geheimhaltungspflichten vorgesehen werden. 

Key Takeaway: Insoweit du deinen Code (auch) als Betriebsgeheimnis schützen möchtest, überlege dir bereits frühzeitig, welche vertraglichen und nicht vertraglichen (zB technischen) Maßnahmen du setzen wirst, um einen solchen Schutz zu erreichen. 

Um deinen Code bestmöglich schützen und anschließend verwerten zu können, gilt es also einiges zu beachten, wobei das wichtigste natürlich weiterhin die Funktionalität deines Codes und der Spaß am Programmieren bleibt.

Über den Autor

Martin Hanzl © EY Law
Martin Hanzl © EY Law

Martin Hanzl ist Senior Associate bei EY Law Pelzmann Gall Größ Rechtsanwälte und betreut dort Mandant*innen unter anderem zu Fragen rund um neue Technologien. Zudem ist er in der Projektleitung des Blockchain and Smart Contracts Projektes des European Law Institute tätig und publiziert regelmäßig zu rechtlichen Themen rund um neue Technologien, Blockchain, Smart Contracts und Digitalisierung.

Deine ungelesenen Artikel:
06.08.2026

Public Venture Clienting: Der Staat als Startup-Kunde

Im Gastbeitrag behandelt Corporate-Venturing-Expertin Viktoria Ilger die Chancen, die Public Venture Clienting bieten kann.
/artikel/public-venture-clienting-der-staat-als-startup-kunde
06.08.2026

Public Venture Clienting: Der Staat als Startup-Kunde

Im Gastbeitrag behandelt Corporate-Venturing-Expertin Viktoria Ilger die Chancen, die Public Venture Clienting bieten kann.
/artikel/public-venture-clienting-der-staat-als-startup-kunde
Viktoria Ilger
Viktoria Ilger | Foto: Viktoria Ilger/Adobe Stock (Hintergrund)

Dieser Text ist zuerst im brutkasten-Printmagazin von Mai 2026 „Die nächste Stufe“ erschienen. Eine Download-Möglichkeit des gesamten Magazins findet sich am Ende dieses Artikels.


Österreich beschafft jährlich Güter, IT-Leistungen und Dienstleistungen im Wert von rund 67 ­Milliarden Euro – etwa 18 Prozent des BIP. Gleichzeitig erwirtschaften laut Austrian Startup Monitor 2023 gerade einmal fünf Prozent der heimischen Startups Umsätze mit öffentlichen Organisationen.

Dieses Missverhältnis ist kein Zufall und kein Versagen einzelner Akteure. Es ist das Ergebnis zweier Welten, die aneinander vorbeireden – und eine Chance, die Österreich systematisch liegen lässt.

Warum Innovation heute Partnerschaften braucht

Unsere Welt wird zunehmend komplexer: Neue Technologien entstehen schneller, als Organisationen sie intern entwickeln können. Lieferketten werden vernetzter, Kundenanforderungen anspruchsvoller, regulatorische Rahmenbedingungen vielschichtiger. In diesem Umfeld ist es weder möglich noch sinnvoll, alles selbst zu entwickeln. Was es braucht, sind smarte Partnerschaften – mit Unternehmen, die genau das lösen, wofür intern Zeit, Team, Ressourcen oder Kernkompetenzen fehlen.

Startups sind dafür prädestiniert: Sie arbeiten mit starkem Problemfokus, entwickeln schlanke Lösungen und bringen eine Geschwindigkeit mit, die etablierte Organisationen strukturell nur schwer erreichen. Viele große Unternehmen im DACH-Raum haben das längst erkannt.

Doch einfach bei Startups einzukaufen funktioniert nicht – klassische Einkaufsprozesse, Rechtsabteilungen und Risikomanagement-Strukturen sind auf Stabilität ausgelegt: bewährte Lieferanten, lange Referenzlisten, geprüfte Bilanzen. Ein Startup mit 18 Monaten Geschichte fällt durch dieses Raster; nicht, weil die Lösung schlecht ist, sondern weil die Prozesse keine Ausnahme kennen. Das Ergebnis: Startups scheitern nicht am Produkt, sondern an der Bürokratie.

Ein Modell, das in der Praxis bereits funktioniert

Venture Clienting wurde als strukturierte Antwort auf genau dieses Problem entwickelt. Kein Fördermodell, keine Beteiligung, kein Accelerator-Programm – sondern ein klarer Prozess: Problemstellungen aus den Fachabteilungen werden identifiziert, passende Startups gescoutet und strukturiert evaluiert. Dann folgt ein Pilotprojekt unter realen Bedingungen, mit definierten Hypothesen und messbaren KPIs. Das Ziel ist nicht das Pilotprojekt selbst, sondern die fundierte Entscheidung danach: skalieren, stoppen oder weiter iterieren?

BMW hat den Ansatz mit der Startup Garage salonfähig gemacht; mittlerweile setzen viele Unternehmen im DACH-Raum und darüber hinaus darauf. Gerade in einer Zeit knapper Budgets gewinnen Effizienzgewinne aus der Zusammenarbeit mit Startups strategisch an Bedeutung.

Public Venture Clienting überträgt diesen Prozess auf die öffentliche Hand: Öffentliche Organisationen und staatsnahe Unternehmen treten als frühe zahlende Kund:innen auf. Die öffentliche Organisation bekommt eine funktionierende Lösung für ein konkretes Problem, das Startup bekommt das Wertvollste, was es in einer frühen Phase bekommen kann: einen zahlenden Kunden, einen Markttest, eine Referenz; und damit offene Türen zu weiteren Märkten und Investoren.

Warum Public Venture Clienting gerade jetzt an Bedeutung gewinnt

Die öffentliche Hand steht unter Druck: Digitalisierung, Klimawende, Versorgungssicherheit und Effizienzsteigerung müssen gleichzeitig vorangetrieben werden – bei begrenzten Ressourcen und steigenden Erwartungen von Bürger:innen und Politik. Startups liefern hier schnelle, digitale und nutzerzentrierte Lösungen für Verwaltung, Mobilität, Klima, Energie und Bürgerdienste; Lösungen, die der öffentliche Sektor in dieser Geschwindigkeit oft nicht selbst entwickeln kann.

Startups stehen unter einem anderen, aber gleichwertigen Druck – Risikokapital-Finanzierungen sind zurückgegangen, der Druck von Investor:innen wegen früher Umsätze ist gestiegen. Hier liegt ein fundamentales Paradox: Österreich hat einen der größten potenziellen Märkte direkt vor der Haustür (67 Milliarden Euro Beschaffungsvolumen), und doch ist dieser Markt für die meisten Startups praktisch nicht zugänglich. Ein öffentlicher Pilotkunde ändert das schlagartig: Cashflow, Stabilität – und eine Referenz, die kein Investor kaufen kann.

Hinzu kommt die dritte Dimension: der Standort. Ein Ökosystem, in dem öffentliche Organisationen systematisch als frühe Kunden auftreten, stärkt heimische Startups auf dem Weg zur Skalierung – und macht Österreich als Innovationsstandort attraktiver. Nicht als Schlagwort, sondern als messbarer Wettbewerbsvorteil im europäischen Vergleich.

Österreich hat eine sehr gute öffentliche Frühphasenfinanzierung für Startups geschaffen und mit dem Dachfonds entsteht Wachstumskapital für Skalierung und Internationalisierung. Das ist richtig und wichtig – und reicht trotzdem nicht. Denn Kapital allein macht aus einer guten Idee noch keine Innovation. Was eine Idee zur Innovation macht, ist die Marktannahme: der Moment, in dem ein echter Kunde echtes Geld bezahlt. Erst dieser Beweis macht aus einem Produkt ein skalierbares Unternehmen. Public Venture Clienting ist damit eine notwendige Ergänzung. Die Kombination aus Kapital und Marktzugang ist der entscheidende Hebel.

Wo die Zusammenarbeit heute an ihre Grenzen stößt

Für das Whitepaper „Public Venture Clienting“ wurden ausführliche Gespräche mit Führungskräften und Mitarbeitenden aus Verwaltung, staatsnahen Unternehmen und der Startup-Szene geführt. Die Herausforderungen sind strukturell tiefer verwurzelt als oft angenommen – und lassen sich in vier Bereiche unterteilen.

Kulturelle Unterschiede

Startups agieren schnell, iterativ und mit hoher Fehlertoleranz. Öffentliche Organisationen sind durch strenge Regulierungen, formale Prozesse und Verantwortlichkeit geprägt – jede Entscheidung muss öffentlich verantwortet werden können. Diese unterschiedlichen Betriebssysteme erzeugen täglich Reibung und Missverständnisse. Ohne bewusste Brückenbauer:innen auf beiden Seiten führt das zu Stillstand.

Fehlende Schnittstellen und Silostrukturen

Für Startups ist oft unklar, wer innerhalb der Organisation zuständig ist, wer entscheidet, wer Budget hat. Bedarfsträger:innen, Einkauf und Rechtsabteilung agieren in Silos mit unterschiedlichen Zielsystemen und ohne gemeinsame Verantwortung für Innovationsprojekte. Diese Fragmentierung erzeugt Reibungsverluste und macht es schwer, eine Tür zu finden, die wirklich aufgeht.

Unterschiedliche Budgethorizonte

Startups operieren mit begrenzter Liquidität und brauchen rasche Entscheidungen sowie zeitnahe Zahlungen. Öffentliche Organisationen planen in Jahreshaushalten. Selbst kleine Beträge für erste Pilotierungen unterliegen langen internen Freigabeprozessen – ein strukturelles Missverhältnis, das Kooperationen abbremst, noch bevor sie begonnen haben.

Rechtliche Unsicherheit und Vergaberecht

Das Vergaberecht ist komplexer, als es auf den ersten Blick scheint – in beide Richtungen. Für Startups ist es eine strukturelle Hürde: Vergabeverfahren verlangen Eignungsnachweise wie Mindestumsätze, Bonitätsnachweise oder Referenzprojekte, die junge Unternehmen kaum erfüllen können. Ein überzeugendes MVP reicht formal nicht aus. Auf der anderen Seite existieren Spielräume: funktionale Leistungsbeschreibungen, Innovationspartnerschaften, Direktvergaben bis 143.000 Euro. Das Problem ist oft nicht das formale Erlaubtsein, sondern die Prüfrealität dahinter: Vergabeentscheidungen müssen ex post gegenüber Kontroll- und Prüfstellen – insbesondere dem Rechnungshof – tragfähig begründet werden können. Diese Anforderung prägt das tatsächliche Entscheidungshandeln oft stärker als der gesetzliche Spielraum selbst. Das Ergebnis: Innovative Beschaffungsansätze werden vor allem dort genutzt, wo sie in standardisierte, intern abgestimmte Prozesse eingebettet sind. Wo das fehlt, entscheiden Einkauf, Recht und Fachabteilungen mit unterschiedlichen Zielen und ohne gemeinsame Verantwortung für das Innovationsprojekt als Ganzes.

Vom Einzelfall zur Struktur

Public Venture Clienting ist ein Lernprozess für alle Beteiligten. Öffentliche Organisationen entwickeln ein besseres Verständnis für iterative Innovationsprozesse; Startups lernen, wie Vergabe- und Entscheidungslogiken im öffentlichen Bereich funktionieren. Beide Seiten gewinnen Sicherheit in der Zusammenarbeit.

Was es dafür braucht, zeigen die Interviews deutlich: klare Zuständigkeiten. Wer ist verantwortlich für die Zusammenarbeit mit Startups? Wer begleitet den Übergang vom Pilotprojekt in die Skalierung? Öffentliche Organisationen, die das intern klar regeln – mit einer zentralen Anlaufstelle, interdisziplinären Teams aus Bedarfsträger:innen, Einkauf und Recht sowie definierten Prozessen –, schaffen die Grundlage, auf der alles andere aufbaut.

Das Vergaberecht muss dabei kein Feind sein. Statt Einzelentscheidungen fallweise abzusichern – oft mit externen Gutachten, die Zeit und Geld kosten –, braucht es standardisierte Schablonen: Begründungstexte für Direktvergaben, Checklisten für funktionale Ausschreibungen, klare Pilotklauseln.

Wenn öffentliche Beschaffung konsequent als Innovationsinstrument verstanden wird, verwandelt sie sich vom bürokratischen Pflichtprogramm in einen Motor für Fortschritt, Digitalisierung und Standortentwicklung. Nicht vom Einzelfall zur Ausnahme – sondern vom Einzelfall zur Struktur.

Wie das konkret gelingen kann – mit Handlungsempfehlungen, Best Practices und einem detaillierten Blick auf das Vergaberecht –, zeigt das vollständige Whitepaper, das im Juni erschienen ist.


Dieser Text ist ein Sneakpeek aus dem Whitepaper „Public Venture Clienting“, veröffentlicht in Kooperation mit Viktoria Ilger und Venture Clienting Austria (VCA).

Viktoria Ilger unterstützt mit ihrem Unternehmen Sustainable Transformers Organisationen dabei, Innovation strukturiert in die Anwendung zu bringen – mit besonderem Fokus auf Corporate Venturing und der Zusammenarbeit mit Startups. Zuvor hat sie über mehrere Jahre die Open-Innovation-Aktivitäten eines internationalen Technologieunternehmens aufgebaut. Sie ist Mitgründerin und Vorstandsmitglied von Venture Clienting Austria (VCA), einem Verein, der den Austausch rund um Venture Clienting in Österreich fördert und Best Practices zwischen Unternehmen, öffentlicher Hand und Startups sichtbar macht.

Toll dass du so interessiert bist!
Hinterlasse uns bitte ein Feedback über den Button am linken Bildschirmrand.
Und klicke hier um die ganze Welt von der brutkasten zu entdecken.

brutkasten Newsletter

Aktuelle Nachrichten zu Startups, den neuesten Innovationen und politischen Entscheidungen zur Digitalisierung direkt in dein Postfach. Wähle aus unserer breiten Palette an Newslettern den passenden für dich.

Montag, Mittwoch und Freitag

AI Summaries

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Welche gesellschaftspolitischen Auswirkungen hat der Inhalt dieses Artikels?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Welche wirtschaftlichen Auswirkungen hat der Inhalt dieses Artikels?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Welche Relevanz hat der Inhalt dieses Artikels für mich als Innovationsmanager:in?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Welche Relevanz hat der Inhalt dieses Artikels für mich als Investor:in?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Welche Relevanz hat der Inhalt dieses Artikels für mich als Politiker:in?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Was könnte das Bigger Picture von den Inhalten dieses Artikels sein?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Wer sind die relevantesten Personen in diesem Artikel?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten

AI Kontextualisierung

Wer sind die relevantesten Organisationen in diesem Artikel?

Leider hat die AI für diese Frage in diesem Artikel keine Antwort …

5 rechtliche Fehler, die Startups beim Programmieren vermeiden sollten