Protor is a complete data engine for ETL, streaming, SQL, workflows and applications, designed to run from a Raspberry Pi to a distributed cluster. Behind it today already: 114 connectors, its own workflow language (VXL) with parser, editor and canvas, 17 system extension families and more than 500 runnable workflows. On top of it we already have a UI design system and a single Control Plane capable of reading, writing and executing engine functionality.
Indago works across millions of patents, publications, documents, source repositories and other knowledge spaces. Today that already means 291 source connectors (including eight patent offices from USPTO to DPMA), 289 analysis and scan tasks, 22 vertical bundles, 68 agent tools and 20 code languages. It also includes a complete application endpoint daemon and a multi-tier reusable UI architecture with a Swift-based control factory, already carrying six standalone applications.
We use both systems ourselves.
The architecture works. The MVPs work.
The core is in place.
We are roughly at seventy-five percent.
The remaining twenty-five percent is where the technology becomes products customers use every day.
Your job
The possible application space around Protor and Indago is enormous.
Protor can support products across data processing, analytics, compliance, industrial systems, research and infrastructure. Indago can become specialised products for patents, scientific research, code, security, enterprise knowledge and many other domains.
So ideas are the easy part.
The craft lies in choosing the right ones and turning them into products that solve a concrete customer problem exceptionally well.
That is where your work starts.
You start at the problem. What is this user actually trying to achieve? Which parts of Protor or Indago matter? What should be exposed, what should disappear behind the product, and which ten percent of a very large platform creates ninety percent of the value here?
Then you build it.
That might be a complete Indago application for a particular market, a Protor-based analytics product, a new interface, a workflow, a service or an integration. You will be building on substantial existing infrastructure rather than starting every application from scratch.
At the same time, we want you to recognise when something product-specific should become reusable infrastructure. If three products need the same capability, we probably should not implement it three times. It may belong back in our UI system, Control Plane, endpoint daemon or another shared layer.
That movement between customer problem and platform abstraction is one of the central engineering challenges of the role.
You'll learn 1.5 million lines of code from the outside in
Certainly not on day one.
Protor and Indago have become too large and multi-layered for anyone new to understand everything immediately.
But you should want to understand why they were built this way.
You start with bounded areas: applications, APIs, services, UI components and concrete workflows. Each product will expose another part of the platform.
Over time, we want something more interesting to happen: you start seeing opportunities yourself.
You notice that an existing engine capability can solve a customer problem before anybody writes a ticket for it. You recognise that two apparently unrelated applications need the same abstraction. Or you tell us that something technically elegant is irrelevant to the person who is supposed to use it.
That is the kind of engineer we are looking for.
The technology
Our primary language is C# / .NET. Depending on the product, you will also work with Swift, HTML, CSS, JavaScript/TypeScript, web technologies and our own APIs and controls.
Protor runs across Windows, Linux and macOS, Intel and ARM, from small devices to clusters. Indago has multiple application and interface layers, including substantial reusable Swift-based UI infrastructure.
We do not expect you to know every platform.
What matters is that you can understand software as a system.
AI-assisted and agentic development is normal here. We use it because it can compress days of implementation into hours. But in a large, heavily abstracted codebase, generating code is the easy part. You still need to judge architecture, understand side effects and recognise when a locally convenient solution damages the system globally.
Who we're looking for
We are not looking for an engineer whose first question is which ticket will be assigned on Monday morning.
We want somebody who enjoys turning technical possibility into concrete reality.
You should be able to think abstractly while still caring about finishing things. You should appreciate architecture without treating abstraction as an end in itself. You should be able to see a product through the eyes of a user without losing sight of what is happening underneath.
And you should have ambition.
Vectorio is still very small. We are founder-financed and are now turning a very large technical foundation into a company. If you join now, you will not be engineer number 247. You will be one of the people deciding which products emerge from Protor and Indago and how they are built.
The amount of influence you have here is unusually large.
This role suits people who take responsibility early and weigh influence and scope more heavily than a finished corporate apparatus.
If the idea of turning two unusually broad technical systems into products companies actually use sounds exciting, we should talk.
How we work
Vectorio is founder-financed. We set our own roadmap. We are investing our own money into technology, people and growth, which also means we have to care where every euro goes.
You work directly with the founder and very close to product and architecture. Problems go straight to the people who solve them.
Ownership here means you decide. On difficult problems we work through architecture, code and requirements together. But when you take responsibility for something, we expect you to move it forward, make decisions and surface problems early.
We work flexibly, with at least one shared day a week in our Reuterkiez office. During the first three months, we would like that to be two days where possible because large systems are learned much faster sitting next to each other.
The terms
Scope: 80–100 %, flexible hours
Location: Berlin Reuterkiez and remote, at least one day per week in the office
Start: immediately
Compensation: €4,000 gross per month full-time, pro rata at 80 %, plus optional equity
Applications close: 30 September 2026
Applying
We do not do LeetCode, whiteboard puzzles or artificial algorithm exercises.
Send us your CV or LinkedIn profile, GitHub if you have one, and one or two things you have actually built. We care less about which framework you used than about the problem you were solving, the decisions you made and what you would do differently today.
Then show us how you think about our world. Pick Protor or Indago and describe a product you would build on top of it. A sketch or a few paragraphs are enough.
What we want to understand is how you reduce a very large technical possibility space to a focused product decision.
That is, in many ways, the job.
Applications from disabled and neurodivergent people are explicitly welcome. If you need particular working conditions, tell us.