• Du hast schon mal etwas gebaut, das es ohne dich nicht gäbe. Ein Nebenprojekt, ein Tool im Studium, ein Startup-Versuch, eine Website für einen Verein oder ein Open-Source-Repo. Uns interessiert nicht, ob es riesig war – uns interessiert, dass es existiert und dass jemand außer dir es nutzt.
• Du studierst Informatik, Wirtschaftsinformatik, Data Science, Maschinenbau/Wirtschaftsingenieurwesen oder einen vergleichbaren Studiengang (oder bist Autodidakt:in mit nachweisbarer Praxiserfahrung) und suchst eine echte Herausforderung neben dem Studium (idealerweise 12–20 Std./Woche).
• Wenn dir etwas unklar ist, baust du eine Version davon. Du schreibst kein seitenlanges Konzept über eine Idee, sondern machst sie schnell sichtbar.
• Du wirst im Gespräch schneller, nicht langsamer. Wenn dir jemand ein unfertiges Problem hinwirft, findest du im Reden die Struktur. Und du hältst es aus, wenn jemand im Raum deiner ersten Idee widerspricht.
• Du fragst nach dem Business, bevor du nach der Architektur fragst. Wie oft passiert das? Was kostet es heute? Wer entscheidet das? Erst danach wird es technisch.
• Du kommst ohne ständige Vorgaben zurecht. Du bekommst bei uns viel Kontext und wenig Mikromanagement.

‍

• Du löst Probleme im Termin, nicht im Backlog. Industrieunternehmen beschreiben dir Abläufe, die seit Jahren so laufen – im Service, Vertrieb oder in Operations. Deine Arbeit beginnt in dem Moment, in dem jemand sagt: „Das geht bei uns nicht.“ Du analysierst das direkt im Gespräch mit den Leuten, die es betrifft.
• Du baust die erste Version selbst. Ein Mock-Up, eine Demo, ein kleines MVP – schnell genug, damit der Kunde eine Entscheidung treffen kann. Nicht sofort perfekt produktionsreif, aber absolut überzeugend. Dein Werkzeug dafür sind KI-Coding-Agents, und du bist darin schneller als die meisten Entwickler:innen, die du kennst.
• Die Tiefe bauen andere. Steht die Entscheidung, geht die produktionsreife Umsetzung an unsere KI-Agenten und an unsere Tech-Teams, die du mitsteuerst. Du hältst die Linie zwischen dem, was im Termin versprochen wurde, und dem, was am Ende herauskommt.
• Du entscheidest auch, was nicht gebaut wird. Ein technisch schöner Use Case, der wirtschaftlich nichts bringt, wird nicht umgesetzt – auch wenn der Kunde ihn will. Diese Entscheidung musst du im Termin vertreten können, gegenüber Menschen, die dafür bezahlen.

‍