28.05.2019

Interne Teams vs. externe IT-Dienstleister: Man kann nicht alles selber entwickeln

Soll man in der Software-Entwicklung im Unternehmen ein eigenes Entwickler-Team beschäftigen, oder einen externen Dienstleister heranziehen? Wir sind dieser Frage mit Ralph Harreiter, Gründer und CEO der Grazer Software-Schmiede Parkside, auf den Grund gegangen.
/artikel/interne-externe-it-dienstleister-parkside
Parkside: CEO Ralph Harreiter zum Thema interne Teams vs. externe IT-Dienstleister
(c) Parkside: CEO Ralph Harreiter
sponsored

Nicht einmal mehr die kleine Bäckerei von nebenan kommt heute um einen Online-Auftritt herum. Das ist nur ein Beispiel, bei dem auch dezidierte Offline-Firmen auf Software angewiesen sind. Mag der Software-Aufwand bei kleinen Offline-Businesses noch überschaubar sein, steigt mit der Unternehmensgröße der Bedarf exponentiell. Man denke neben der obligatorischen Website nur an Verwaltungs-, Buchhaltungs- und Datenbanksysteme. Doch nicht für alles gibt es Fertig-Software-Produkte. Da stellt sich früher oder später die große Frage: Soll man Know-How und Teams aufbauen, oder externe IT-Dienstleister beauftragen? Dabei sind einige Kriterien zu bedenken.

+++ Drei Hebel für die Unternehmenskultur +++

Vertrauen als entscheidender Faktor

„Rein prinzipiell kann man sagen: Es kommt auf die Produkt-Kernkompetenz an. Wenn das Kernprodukt eines Unternehmens digital ist, braucht es dafür natürlich interne Teams. Auch dann kann man sich aber für gewisse Zwecke externe Verstärkung holen. Wenn die Kernkompetenz nicht im IT-Bereich liegt, kann es sinnvoll sein, die gesamte Software extern bauen zu lassen“, sagt Ralph Harreiter, Gründer und CEO der Grazer Software-Schmiede Parkside. Entscheidend sei dabei aber der Faktor Vertrauen. „Sonst kann es langfristig nicht funktionieren“, sagt Harreiter.

Rechtliche Absicherung

Und bei allem Vertrauen müsse man sich dennoch rechtlich entsprechend absichern. „Gerade bei Anwendungen, die für das Unternehmen ‚mission critical‘ sind, sollte man sich vertraglich alle Rechte bzw. überhaupt Exklusivrechte sichern“, sagt der Parkside-Gründer. Denn im schlimmsten Fall könne man sonst auf einer Nutzungslizenz „sitzen bleiben“, mit der man nicht weiterarbeiten könne. Doch Harreiter beruhigt: „Jeder seriöse Anwalt weiß, was in so einem Vertrag drinnen stehen muss“.

Frische Ansätze von außen

Auch für Großkonzerne, die prinzipiell Budget und Kapazitäten hätten, sämtliche Systeme inhouse entwickeln zu lassen, hätte die Beauftragung externer Software-Entwicklungspartner potenziell entscheidende Vorteile, sagt Harreiter. „Zum einen fällt es ihnen oft schwer, gute innovative Mitarbeiter zu finden. Es bestehen einfach viele Vorurteile gegenüber großen Corporates, die oft gar nicht stimmen. Gute externe IT-Dienstleister haben diese Leute. Zum anderen kommen von außen häufig frischere, innovativere Ansätze. Darüber hinaus gibt es Fälle, wo die Inhouse-Truppe ein Problem nicht aufgreifen kann oder will. Zum Beispiel weil die besten eigenen Leute an andere Stelle voll ausgelastet sind. Da kommt es öfters zu Situationen, wo wir als externer Spezialist hinzugezogen werden, um ein Projekt zu retten bzw. noch erfolgreich zu machen“.

Spezialisten auf Abruf

Und wie sieht es mit kleineren Unternehmen aus? „Dort ist es so, dass man viele Spezialrollen – seien das jetzt Software-Architekten, UI-Spezialisten oder iOS Developer – nicht in Vollzeit oder überhaupt nur sporadisch braucht. Bei einem externen Anbieter kann man dann, je nach Bedarf, auf ein ganzes Team von erfahrenen Spezialisten zurückgreifen“, sagt Harreiter.

Geschwindigkeit als Hauptargument

Das sei auch einer der potenziellen Vorteile, wenn Unternehmen, deren Kernprodukt digital ist, auf externe Hilfe setzen. „IT-Unternehmen müssen natürlich ihr eigenes Produkt selber im Griff haben. Das passiert aber häufig primär im Backend. Wenn es im Frontend etwa eine App-Oberfläche geben soll, können das externe Spezialisten vielleicht besser bauen, wenn sie auf einer entsprechenden API aufsetzen können“, erklärt der Parkside CEO. Das Hauptargument, warum auch IT-Unternehmen externe IT-Dienstleistungen einkaufen, sei Geschwindigkeit. Generell stelle sich dabei die Frage: Will man sein Team mit externen Kräften erweitern, also etwa Coding-Leistung ankaufen, oder ganze Produkte extern bauen lassen?

Mehr Aufträge für externe IT-Dienstleister in den USA

Mit Parkside hat sich Harreiter auf zweiteres spezialisiert: „Wir arbeiten sehr gerne an Gesamtpaketen, weil wir da eigenständig arbeiten können“. Dabei macht das Unternehmen mehr als 60 Prozent seiner rund fünf Millionen Euro Jahresumsatz in den USA – bislang von Graz aus. An einem möglichen US-Standort in San Francisco wird gearbeitet. Einer der größten US-Kunden ist die Plattform LinkedIn. „Dass man sich in den USA leichter tut, externe Software-Partner zu beauftragen, hat wohl mehrere Gründe. Erstens ist der Mangel an Spezialisten dort noch größer. Zweitens ist der Faktor Geschwindigkeit in den USA noch bedeutender. Und drittens ist es sicher auch eine Mindset-Sache“, sagt Harreiter.

Mitdenken statt Befehle empfangen – Outsourcing war gestern

Bemerkenswert ist zudem Parksides Ansatz. Man geht in Projekte mit selbstorganisierten Spezialistenteams, die sich eigenständig einarbeiten und gemeinsam mit dem Kunden die richtigen strategischen, gestalterischen und technischen Entscheidungen treffen. „Das ist keineswegs üblich“, sagt Harreiter. „Im Silicon Valley trifft man noch vielfach auf das klassische Outsourcing-Modell, wo der Kunde dem IT-Dienstleister genau sagt, was er zu tun hat. In vielen Gesprächen vor Ort lernen wir, dass dies für die Unternehmen nur bedingt gut funktioniert. Da können wir als bewegliche Truppe, die sich mit eigenen Ideen und Konzepten engagiert, viel zur Qualitätssteigerung beitragen“.

Parkside: “Überall, wo es etwas zu entdecken gibt, fühlen wir uns wohl”

Was seine Kunden anbelangt, bleibt Parkside im In- wie im Ausland seinen Prinzipien treu. „Es gibt auch Aufträge, die wir nicht annehmen, weil sie nicht zu unserer Unternehmenskultur und unseren Werten passen“, sagt Harreiter. Man baue beispielsweise keine Anwendungen im Glücksspiel-Bereich. Gerne nehme man hingegen Aufträge an, die besonders fordernd sind. „Überall, wo es etwas zu entdecken gibt und wo neue Technologien zum Einsatz kommen, fühlen wir uns wohl. Da haben unsere Leute Spaß und performen am besten, weil sie wirklich mitgestalten können“.

⇒ Zur Page der Grazer Software-Schmiede Parkside

Deine ungelesenen Artikel:
17.09.2026

Lovable-CEO Anton Osika: „Wir sind längst über Vibecoding hinaus“ – vom Hype zur Enterprise-Software

Erst vor etwa einem Monat holte Lovable 400 Mio. Dollar bei 13,3 Mrd. Bewertung: CEO Anton Osika erklärt nun im Interview, warum KI-Bau-Tools längst im Mainstream angekommen sind und wie aus Vibe-Coding echte Enterprise-Software wurde.
/artikel/lovable-ceo-anton-osika-wir-sind-laengst-ueber-vibecoding-hinaus-vom-hype-zur-enterprise-software
17.09.2026

Lovable-CEO Anton Osika: „Wir sind längst über Vibecoding hinaus“ – vom Hype zur Enterprise-Software

Erst vor etwa einem Monat holte Lovable 400 Mio. Dollar bei 13,3 Mrd. Bewertung: CEO Anton Osika erklärt nun im Interview, warum KI-Bau-Tools längst im Mainstream angekommen sind und wie aus Vibe-Coding echte Enterprise-Software wurde.
/artikel/lovable-ceo-anton-osika-wir-sind-laengst-ueber-vibecoding-hinaus-vom-hype-zur-enterprise-software
Lovable-CEO Anton Osika (r.) im Gespräch mit Times Senior Editorin Ayesha Javed. © brutkasten

Kaum ein Tool steht so sehr für den KI-Bauboom wie Lovable. Erst im August 2026 hat das schwedische Startup, wie brutkasten berichtete, eine Series-C-Runde über 400 Millionen US-Dollar abgeschlossen, angeführt von Menlo Ventures und mit dem EQT-gemanagten Scaleup Europe Fund als Co-Lead, bei einer Bewertung von 13,3 Milliarden US-Dollar.

Für Gründer und CEO Anton Osika ist das mehr als eine Finanzierungsrunde: Es sei ein Indikator dafür, dass KI-gestützte No-Code- und Low-Code-Plattformen die Nische verlassen hätten und im Mainstream angekommen seien.

Weg vom Entwickler-Monopol

Auf der Dreamforce in San Francisco erläutert Osika die zentrale These hinter Lovable: „Menschen mit Fachwissen über das jeweilige Problem sollten diejenigen sein, die Software bauen“, so Osika. Wer ein Problem am besten kenne, solle auch die Lösung bauen, egal ob in Marketing, HR, Finance oder Operations. Nicht die formale Qualifikation zähle, sondern die Nähe zum Problem.

Dass Lovable längst kein reines Anfänger-Werkzeug sei, belegt Osika mit einer internen Zahl: 55 Prozent der Lovable-Nutzer:innen brächten mehr als elf Jahre Berufserfahrung in ihrem Fachgebiet mit. Entscheidend sei laut dem Co-Founder nicht das klassische Programmieren, sondern die Fähigkeit, komplexe, unstrukturierte Probleme systematisch in funktionierende Systeme zu zerlegen.

Vom Nebenprojekt zur Unternehmenslösung

Besonders aufschlussreich sind die Praxisbeispiele, die Osika im Gespräch anführt. Bei einer Healthcare-Staffing-Firma habe ein Fachbereichsleiter eine komplette neue Produktlinie für die Zertifizierung von Pflegekräften aufgebaut, samt Verwaltung und Terminplanung, und anschließend mehr als zehn weitere interne Anwendungen vernetzt. In den nordischen McDonald’s-Filialen laufe mittlerweile ein auf Lovable gebautes Interface, über das rund 300 Standorte operative Anfragen abwickeln würden.

Solche Geschichten seien laut Osika keine Ausnahme: Bei knapp zwei Dritteln der Fortune-500-Unternehmen, darunter Adidas und Nvidia, würden Mitarbeitende die Plattform nutzen. Häufig beginne es als kleines Team-Projekt und wachse zur unternehmensweiten Lösung heran.

Entwicklung unter Aufsicht

Damit das nicht in unkontrollierter Schatten-IT ende, setzt Lovable laut Unternehmensangaben auf Admin- und Audit-Funktionen, mit denen IT-Verantwortliche nachvollziehen können sollen, welche Anwendungen entstehen, wo sensible Daten verarbeitet werden und wo Sicherheitslücken drohen. Genau das mache aus der anfänglichen Skepsis von IT-Abteilungen häufig Zustimmung, so Osika: „Es wird vom letzten Nein zu dem, was man ausrollen wollte, zum ersten Ja. So verhindern wir Schatten-IT und die Zersplitterung in unzählige Tools, die niemand mehr überblickt“, erklärt Osika.

Überflüssig würden Engineers durch die Lovable-Nutzung anderer trotzdem nicht, meint Osika: Ihre Rolle verschiebe sich von Routineaufgaben hin zu Architektur, Systemanbindung und der Betreuung unternehmenskritischen Codes.

Warum heißt Lovable eigentlich Lovable?

Zum Schluss des Gesprächs räumt Osika mit einem gängigen Klischee über den europäischen Tech-Standort auf: „Viele halten Europa für langsam, aber wenn man in die Tech-Hubs Europas geht, brodelt es dort wie nie zuvor“, sagt Osika. Dass der Produktfokus so stark auf dem Nutzererlebnis liege, führt Osika auch auf den Standort Stockholm zurück, wo der Großteil des Engineering-Teams sitzt. Man habe in den nordischen Ländern genaue Vorstellungen davon, wie ein Produkt funktionieren solle – oder eben nicht. Diese „I-Tüpfelchen-Reiterei“ mache Lovable erst zu dem was es heute ist.

Warum das Unternehmen ausgerechnet „Lovable“ heißt, erklärt er mit einer letzten Zeile, die zugleich als Leitmotiv des Gesprächs steht: „Software sollte nicht einfach nur funktionieren. Sie soll die Emotionen der Menschen wecken“, so Osika.

Vom Vibe zum Volumengeschäft

Was also vor nicht allzu langer Zeit noch als spielerisches „Vibe-Coding“ belächelt wurde, ist laut Osika längst zu einer Infrastruktur geworden, auf der Enterprisekund:innen die nächsten Prozesssysteme entwickeln. Der Markt für KI-gestütztes Bauen sei, so der Lovable-Gründer, endgültig über das reine Ausprobieren hinausgewachsen – und weit über das Vibecoding hinaus.

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

Interne Teams vs. externe IT-Dienstleister: Man kann nicht alles selber entwickeln

AI Kontextualisierung

Welche gesellschaftspolitischen Auswirkungen hat der Inhalt dieses Artikels?

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

Interne Teams vs. externe IT-Dienstleister: Man kann nicht alles selber entwickeln

AI Kontextualisierung

Welche wirtschaftlichen Auswirkungen hat der Inhalt dieses Artikels?

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

Interne Teams vs. externe IT-Dienstleister: Man kann nicht alles selber entwickeln

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 …

Interne Teams vs. externe IT-Dienstleister: Man kann nicht alles selber entwickeln

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 …

Interne Teams vs. externe IT-Dienstleister: Man kann nicht alles selber entwickeln

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 …

Interne Teams vs. externe IT-Dienstleister: Man kann nicht alles selber entwickeln

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 …

Interne Teams vs. externe IT-Dienstleister: Man kann nicht alles selber entwickeln

AI Kontextualisierung

Wer sind die relevantesten Personen in diesem Artikel?

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

Interne Teams vs. externe IT-Dienstleister: Man kann nicht alles selber entwickeln

AI Kontextualisierung

Wer sind die relevantesten Organisationen in diesem Artikel?

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

Interne Teams vs. externe IT-Dienstleister: Man kann nicht alles selber entwickeln