Protor ist eine vollständige Data Engine für ETL, Streaming, SQL, Workflows und Anwendungen, vom Raspberry Pi bis zum verteilten Cluster. Dahinter stehen heute schon 114 Konnektoren, eine eigene Workflow-Sprache (VXL) mit Parser, Editor und Canvas, 17 System-Extension-Familien und über 500 lauffähige Workflows. Darüber liegen ein UI-Designsystem und ein einheitliches Control Plane, über das sich Funktionen der Engine lesen, schreiben und ausführen lassen.
Indago erschließt Millionen von Patenten, Publikationen, Dokumenten, Code-Repositories und anderen Wissensbeständen. Heute sind das schon 291 Quellen-Konnektoren (darunter acht Patentämter von USPTO bis DPMA), 289 Analyse- und Scan-Tasks, 22 vertikale Bundles, 68 Agenten-Werkzeuge und 20 Code-Sprachen. Dazu kommen ein vollständiger Endpoint-Daemon und eine mehrstufige, wiederverwendbare UI-Architektur mit Swift-basierten Controls, auf der bereits sechs eigenständige Anwendungen laufen.
Wir benutzen beide Systeme selbst. Die Architektur funktioniert. Die MVPs funktionieren.
Der Kern steht.
Wir sind ungefähr bei fünfundsiebzig.
Die nächsten fünfundzwanzig Prozent sind die, aus denen Produkte werden, die Kunden täglich einsetzen.
Deine Aufgabe
Die Möglichkeiten von Protor und Indago sind fast zu groß.
Aus Protor können Anwendungen für Datenverarbeitung, Analyse, Compliance, industrielle Systeme, Forschung, Infrastruktur oder völlig andere Bereiche entstehen. Indago kann aus denselben Grundbausteinen Produkte für Patente, wissenschaftliche Recherche, Code, Security, Unternehmenswissen und viele weitere Wissensräume tragen.
Ideen haben wir also genug.
Die Kunst liegt darin, die richtigen auszuwählen und sie so gut zu bauen, dass sie für einen konkreten Kunden unmittelbar wertvoll werden.
Genau hier beginnt deine Arbeit.
Du beginnst beim Problem: Was versucht dieser Nutzer tatsächlich zu erreichen? Welche Fähigkeiten von Protor oder Indago sind dafür relevant? Was muss sichtbar werden, was kann im Hintergrund bleiben, und welche zehn Prozent der Plattform erzeugen hier neunzig Prozent des Nutzens?
Danach baust du das Produkt.
Das kann eine vollständige Indago-Anwendung für einen bestimmten Markt sein, eine Protor-basierte Analyse- oder Datenanwendung, eine neue Benutzeroberfläche, ein Workflow, ein Service oder eine Integration. Dabei greifst du auf sehr viel vorhandene Infrastruktur zurück, statt jedes Produkt von vorne zu beginnen.
Gleichzeitig sollst du erkennen, wann aus einer produktspezifischen Lösung wieder ein allgemeiner Baustein werden sollte. Wenn drei Anwendungen dasselbe Problem haben, wollen wir es nicht dreimal lösen. Dann gehört die Lösung wahrscheinlich zurück in unser UI-System, das Control Plane, den Endpoint-Daemon oder eine andere gemeinsame Ebene.
Das ist der eigentliche technische Reiz dieser Rolle: zwischen konkretem Kundenproblem und allgemeiner Plattformarchitektur wechseln zu können.
1,5 Millionen Zeilen Code lernst du von außen nach innen kennen
Zumindest nicht am ersten Tag.
Die Systeme sind inzwischen zu groß und zu vielschichtig, um sie vollständig im Kopf zu haben.
Du sollst aber verstehen wollen, warum sie so gebaut wurden.
Du beginnst mit klar umrissenen Bereichen: Anwendungen, APIs, Services, UI-Komponenten und konkrete Workflows. Mit jedem Produkt erschließt du einen weiteren Teil der Plattform.
Mit der Zeit sollte etwas anderes passieren: Du siehst selbst Möglichkeiten.
Du erkennst, dass eine vorhandene Engine-Funktion ein Kundenproblem lösen könnte, bevor jemand dir ein Ticket dafür schreibt. Du bemerkst, dass zwei scheinbar unterschiedliche Anwendungen dieselbe Abstraktion brauchen. Oder du sagst uns, dass etwas, das technisch elegant aussieht, für einen Kunden vollkommen irrelevant ist.
Genau dieses Denken suchen wir.
Die Technik
Unsere primäre Sprache ist C# / .NET. Je nach Produkt arbeitest du außerdem mit Swift, HTML, CSS, JavaScript/TypeScript, Web-Technologien und unseren eigenen APIs und Controls.
Protor läuft auf Windows, Linux und macOS, auf Intel und ARM, vom kleinen Gerät bis zum Cluster. Indago besitzt mehrere Anwendungs- und Interface-Schichten und unter anderem eine umfangreiche Swift-basierte UI-Infrastruktur.
Welche Plattformen du schon kennst, ist zweitrangig.
Wichtig ist, dass du Software als System verstehst.
KI gehört bei uns selbstverständlich zur Entwicklung. Agentische Coding-Werkzeuge können enorme Geschwindigkeit bringen, und wir nutzen sie. Aber bei einer großen, abstrahierten Codebasis reicht es nicht, Code generieren zu können. Du musst Architektur beurteilen, Seiteneffekte verstehen und erkennen können, wann eine scheinbar schnelle Lösung langfristig die falsche ist.
Wen wir suchen
Wir suchen keinen Entwickler, der möglichst genau wissen möchte, welches Ticket am Montagmorgen auf ihn wartet.
Wir suchen jemanden, der Freude daran hat, aus technischer Möglichkeit konkrete Realität zu machen.
Du solltest abstrakt denken können und trotzdem gern Dinge fertigstellen. Du solltest Architektur mögen, aber nicht Architektur um ihrer selbst willen. Du solltest Produkte aus Sicht eines Nutzers betrachten können, ohne die technischen Konsequenzen zu vergessen.
Und du solltest Ambition mögen.
Vectorio ist noch sehr klein. Wir sind gründerfinanziert und bauen gerade aus einem sehr großen technischen Fundament ein Unternehmen. Wenn du jetzt dazukommst, wirst du nicht Entwickler Nummer 247. Du wirst einer der Menschen sein, die entscheiden, welche Produkte aus Protor und Indago entstehen und wie sie gebaut werden.
Die Fläche, auf der du hier etwas verändern kannst, ist ungewöhnlich groß.
Die Rolle passt zu Menschen, die Verantwortung früh übernehmen und Gestaltungsspielraum höher gewichten als einen bereits fertigen Unternehmensapparat.
Wenn dich die Vorstellung reizt, aus zwei ungewöhnlich großen technischen Systemen gemeinsam Produkte zu machen, die Unternehmen tatsächlich einsetzen, sollten wir miteinander sprechen.
Wie wir arbeiten
Vectorio ist founder-financed. Unsere Roadmap entscheiden wir selbst. Wir investieren unser eigenes Geld in Technologie, Menschen und Wachstum und müssen deshalb bewusst entscheiden, wofür wir es ausgeben.
Du arbeitest direkt mit dem Gründer und sehr nah an Produkt und Architektur. Probleme gehen direkt an die Menschen, die sie lösen.
Ownership heißt bei uns: du entscheidest. Bei schwierigen Problemen sitzen wir gemeinsam vor Architektur, Code und Anforderungen. Wenn du jedoch einen Bereich übernimmst, erwarten wir auch, dass du ihn voranbringst, Entscheidungen triffst und früh sagst, wenn etwas nicht funktioniert.
Wir arbeiten flexibel, mit mindestens einem gemeinsamen Tag pro Woche im Reuterkiez. In den ersten drei Monaten möchten wir möglichst zwei gemeinsame Tage haben, weil man große Systeme erheblich schneller versteht, wenn man gemeinsam davor sitzt.
Rahmenbedingungen
Umfang: 80–100 %, flexible Arbeitszeiten
Ort: Berlin Reuterkiez und remote, mindestens ein Tag pro Woche im Büro
Start: ab sofort
Vergütung: 4.000 € brutto pro Monat bei Vollzeit, anteilig bei 80 %, plus optionale Beteiligung
Bewerbungsschluss: 30. September 2026
Bewerbung
Wir machen kein LeetCode, keine Whiteboard-Rätsel und keine künstlichen Algorithmusaufgaben.
Schick uns deinen Lebenslauf oder dein LinkedIn-Profil, GitHub falls vorhanden und ein oder zwei Dinge, die du tatsächlich gebaut hast. Uns interessiert weniger, welches Framework du benutzt hast, als welches Problem du lösen wolltest, welche Entscheidungen du getroffen hast und was du heute anders machen würdest.
Und dann würden wir gern sehen, wie du auf unsere Welt schaust. Such dir Protor oder Indago aus und beschreibe ein Produkt, das du darauf bauen würdest. Eine Skizze oder ein paar Absätze reichen.
Uns interessiert, wie du aus einer sehr großen technischen Möglichkeit eine fokussierte Produktentscheidung machst. Das ist letztlich die Arbeit.
Bewerbungen von Menschen mit Behinderung und von neurodivergenten Menschen sind ausdrücklich willkommen. Wenn du bestimmte Arbeitsbedingungen brauchst, sprich uns darauf an.