Engineering bei Txture: Wie Scrum, TypeScript, Kotlin und Teamharmonie zusammenwirken – Einblicke mit Christian Esswein, Senior Full Stack Developer bei Txture

Einleitung: Produktentwicklung mit Fokus, Freiheit und Klarheit

Im Techlead-Format haben wir mit „Christian Esswein, Senior Full Stack Developer bei Txture“ ein Gespräch erlebt, das selten so klar auf den Punkt bringt, wie moderne Produktentwicklung in einem fokussierten Team funktioniert. Txture ist Tool-Vendor mit eigenen Produkten – bereitgestellt als SaaS-Applikation und bei Bedarf auch On-Prem beim Kunden. Der Nutzungszugang erfolgt über ein Webfrontend. Was uns beeindruckt: ein kleines, schlagkräftiges Team, das konsequent auf fachliche Exzellenz, offene Kommunikation und flexible Zusammenarbeit setzt – und dabei eine beachtliche Software-Landschaft betreibt.

Von der Arbeitsorganisation (Scrum, Daily Stand-ups, Subtasking) über eine sehr sachliche, freundliche Hiring-Experience bis hin zu einer robusten Technologie- und Qualitätsbasis (React mit TypeScript, CraftQL, Kotlin/Java mit Spring, Docker/Kubernetes, umfassende Unit-Tests, eigene Graph-Datenbank mit Versionierung) gibt Christian einen kompakten, aber dichten Einblick in Engineering bei Txture. Was hängen bleibt: Man baut hier echte Produkte – und jeder Beitrag zählt.

Teamstruktur: 8–9 Entwickler, klare Verantwortlichkeiten, gemeinsame Architekturarbeit

„Wir sind derzeit im Dev Team 8, je nachdem wie man zählt, 9“, erklärt Christian. Das Team ist bewusst nach persönlicher Vorliebe und Expertise aufgeteilt: Einige arbeiten primär im Frontend, andere vorwiegend im Backend. Entscheidend ist, dass neue Features gemeinsam angegangen werden:

• Als Gruppe setzt man sich zusammen, um Architekturentscheidungen zu treffen: Wie wird das Feature aufgebaut? Wo werden Daten benötigt? Wie stellen wir sie bereit?
• Danach bricht das Team die Arbeit in kleinere Subtasks herunter und verteilt sie im Team.

Diese Mischung aus Spezialistentum und gemeinsamer Verantwortung sorgt dafür, dass die Architektur nicht isoliert entsteht, sondern fachlich breit getragen wird. Gleichzeitig bleiben Aufgaben klar zugeschnitten und planbar.

Arbeitsorganisation: Scrum, Fokus und Transparenz – auch über Distanz

Txture orientiert sich in der Gesamtkommunikation und Struktur an Scrum. Das schafft Planbarkeit und macht Fortschritte transparent, gerade weil „derzeit bei uns zwei primär Remote arbeiten, der Rest ist hier in Innsbruck im Office“. Scrum bildet hier den Rahmen, um den Fokus nicht zu verlieren, zu wissen, wer woran arbeitet und wann mit bestimmten Features zu rechnen ist.

• Daily Stand-up: Der Tag startet üblicherweise mit einem Daily. Jeder teilt, woran er gerade arbeitet, was als Nächstes ansteht und wo es vielleicht hakt.
• Frühe Problemerkennung: Durch das tägliche Synchronisieren werden Stolpersteine früh sichtbar. Anschließend kann man sich in kleineren Gruppen gezielt zusammensetzen, um Probleme zu analysieren und zu lösen.

Diese pragmatische, strukturierte Arbeitsweise macht Remote- und Onsite-Zusammenarbeit gleichermaßen zuverlässig. Transparenz ersetzt Vermutungen – und beschleunigt die Umsetzung.

Flexibilität im Alltag: Arbeiten, wenn es passt – solange es zusammenpasst

Neben den fixen Terminen ist die Zeiteinteilung „relativ flexibel“. In Innsbruck bedeutet das auch: morgens den Schnee nutzen oder im Sommer mit dem Mountainbike unterwegs sein – und dann in den Arbeitstag starten. Dieses Modell zeigt, wie ernst Txture individuelle Arbeitsrhythmen nimmt: Wichtig sind Verantwortung, Abstimmung und Ergebnisse. Das schafft Freiraum, ohne dass der Teamtakt leidet.

Kultur und Erwartungen: Fachliche Stärke, Teamharmonie und klare Kommunikation

Christian bringt die Erwartungshaltung auf den Punkt: „Fachliche Kompetenz muss natürlich vorhanden sein. Ohne die geht gar nichts.“ Genauso wichtig ist, „dass die Harmonie im Team passt“. In einem jungen, motivierten Unternehmen – „wir sind insgesamt in der Firma mittlerweile 18 Leute“ – verbringt man viel Zeit miteinander. Daher gilt:

• Arbeit soll Spaß machen – denn ohne Freude leidet Produktivität.
• Kommunikation ist zentral. Bewerber sollten offen kommunizieren, bei Problemen nachfragen und Ideen einbringen.
• Eigeninitiative zählt: Als Tool-Vendor mit eigenen Produkten ist es „schön und sehr wichtig“, dass jeder am Produkt miterschafft. Txture bietet viel Freiheit in der persönlichen Gestaltung – im Gegenzug wird erwartet, dass man sich reindenkt und Impulse setzt.

In Summe klingt das nach einer Kultur, die Verantwortung, Kollegialität und Produktfokus vereint. Wer nur „Tickets abarbeitet“, wird hier nicht glücklich – wer gestalten will, schon.

Gesuchte Profile: Frontend und Full-Stack – technologieoffen, produktfokussiert

Langfristig sucht Txture „in fast allen Bereichen“ Verstärkung. Akut liegt der Schwerpunkt auf Frontend-Entwicklung sowie Full-Stack-Profilen.

• Frontend: React und TypeScript bilden die Basis, Styles werden mit Styled Components bzw. Emotion umgesetzt. Wichtig: Technologieoffenheit. Wer aus der Angular- oder Vue.js-Ecke kommt und sich gerne einarbeitet, ist willkommen.
• Full-Stack: Im Backend-Umfeld nennt Christian „CraftQL mit TypeScript, Node.js mit Mongo-Datenbanken hintendran“. Hier geht es um Schnittstellendenken, Datenflüsse und stringente Services.

Die Botschaft ist klar: Entscheidend sind Lernbereitschaft, Sorgfalt und der Wille, sich in die Produktlogik zu vertiefen – die Framework-Differenzen sind zweitrangig.

Bewerbungsprozess: Schlank, respektvoll und aussagekräftig

Der Weg ins Team ist bewusst einfach gehalten. „Einfach über unsere Webseite text.io uns kontaktieren, uns anschreiben.“ Der Prozess folgt drei Schritten:

1. Kurzes Telefonat: Ein erstes Kennenlernen, um Erwartungen abzugleichen – von beiden Seiten. Das spart Zeit, falls die Vorstellungen auseinanderliegen.
2. Nächste Runde zum Kennenlernen: Hier steht die Frage im Zentrum, ob es harmoniert und zusammenpasst.
3. Technical Interview: Im Dev-Bereich gibt es ein gemeinsames Code-Beispiel – typischerweise eine Komponente mit ein paar kleineren, bewusst eingebauten Fehlern. Gemeinsam bespricht man: Was ist gut? Was ist verbesserungswürdig? Entscheidend ist das Miteinander am Code.

Txture rekrutiert für das Office in Innsbruck und ist „auch offen für Remote-Besetzungen“. Kontakt aufnehmen – und dann schauen, „was sich zusammentut“.

Produkt, Architektur und Codebasis: SaaS, On-Prem, Webfrontend – und viel Substanz

Txture liefert seine Software als SaaS aus, bietet bei Bedarf On-Prem-Deployments und setzt auf ein Webfrontend. Aus Engineering-Perspektive ist die Frontend-Codebasis bemerkenswert: „allein im Frontend-Bereich um die 250.000 Lines of Code“.

• Warum TypeScript? „Hilft uns einfach schon während der Entwicklung, dass ein Entwickler im Vorfeld schon weiß, ob eigentlich der Code, der er baut, funktioniert, ordentlich ein Auto-Complete hat und einfach da schon einige Static-Checks ausgeführt werden.“ Bei dieser Codebasis ist starke Typisierung nicht „nice to have“, sondern ein Produktivitäts- und Qualitätshebel.
• Mid-Layer: „In dem Mid-Layer setzen wir mittlerweile auch immer mehr CraftQL ein.“ Ziel ist es, im Entwicklungszyklus sicherzustellen, dass die Kommunikation zwischen Server und Client-Parts funktioniert und „wir nur die Daten laden, die wir eigentlich benötigen“.

Diese Kombination aus TypeScript und CraftQL sorgt dafür, dass Verträge zwischen Frontend und Backend zuverlässig funktionieren – weniger Laufzeitüberraschungen, mehr Vorhersehbarkeit.

Backend-Stack: Kotlin/Java mit Spring, Microservices, Node.js

Die Server-Applikation ist „in Kotlin, teilweise auch in Java noch, geschrieben mit dem Spring Framework“. Zusätzlich gibt es Microservices, „großteils in Kotlin, teilweise auch in Node.js“. Qualitätsseitig nennt Christian „über 2.500 Unitests“ – ein klares Zeichen für einen ernsthaften Testanspruch. In Summe entsteht ein Umfeld, das auf moderne JVM-Technologien setzt und pragmatisch Node.js dort nutzt, wo es sinnvoll ist.

Deployment und Betrieb: Docker, Kubernetes, reproduzierbare Zustände

Beim Deployment setzt Txture „seit einiger Zeit eigentlich fast nur noch Docker-Deployments“ ein, „relativ viel auch in unserem Kubernetes-Cluster deployed“. Davon profitiert man doppelt:

• Dynamische Skalierung: Systeme wachsen mit ihren Aufgaben.
• Reproduzierbarkeit: „…hilft, jeden Zustand eigentlich lokal komplett nachstellen zu können, um Probleme zu identifizieren und debuggen.“ Für Entwickler heißt das: realistische Umgebungen sind schnell verfügbar, Fehler lassen sich gezielt nachstellen.

Diese Praxis ist nicht nur ein Betriebsdetail – sie ist ein Produktivitätsbooster für das gesamte Dev-Team.

Datenhaltung: SQLite, MongoDB – und eine eigene Graph-Datenbank mit Versionierung

Auf der Storage-Ebene nutzt Txture „SQLite und MongoDB“ und führt zusätzlich „eine selbstgeschriebene Graf-Datenbank mit Versionierung“ an. Das ist bemerkenswert: Eine eigene Graph-DB baut man nicht nebenbei. Sie deutet auf sehr spezifische Anforderungen hin und auf die Fähigkeit, Infrastrukturkomponenten zielgerichtet zu entwickeln. Für Entwickler bedeutet das: Arbeit an herausfordernden Datenmodellen, bei denen Konsistenz, Historisierung und Abfrageperformance zusammenspielen.

Engineering-Qualität im Alltag: Typisierung, Tests und gemeinsame Reviews

Die von Christian beschriebenen Bausteine ergeben zusammen ein klares Qualitätsbild:

• Starke Typisierung im Frontend (TypeScript) für frühe Fehlervermeidung und besseres Developer Ergonomics (Autovervollständigung, Static Checks).
• Vertragsklarheit zwischen Client und Server durch CraftQL – nur die Daten, die gebraucht werden.
• 2.500+ Unit-Tests auf der Server-Seite – ein signifikanter automatisierter Sicherheitsgurt.
• Gemeinsame Code-Durchsprachen im technischen Interview spiegeln die reale Praxis: Code ist Teamarbeit.

Wer gerne sauber baut, profitiert hier von Strukturen, die Qualität begünstigen – ohne übermäßige Bürokratie.

Zusammenarbeit: Kleine, fokussierte Runden für schwierige Probleme

Christian beschreibt eine Kultur, in der Probleme früh adressiert und in kleinen Gruppen ausgeräumt werden. Das Daily dient als Radar – und danach bildet man Ad-hoc-Taskforces. Ergebnis: kurze Wege, wenig Leerlauf, schnelles Feedback. Gerade in hybriden Teams (zwei Remote, der Rest im Office) ist das der Unterschied zwischen „parallelem Solo-Entwickeln“ und echter Zusammenarbeit.

Verantwortung und Eigeninitiative: Produktmitgestaltung statt Ticketverwaltung

Als Tool-Vendor mit eigenem Produkt ist Txture auf Mitarbeitende angewiesen, die über den Code hinausdenken. „Wir bieten da sehr viel Freiheit in der persönlichen Gestaltung, wie man sich einbringen kann und wo“, sagt Christian. Im Gegenzug wird erwartet, „dass er sich einfach reindenken kann und sagen kann, okay, das wäre natürlich noch ganz besonders und einfach ein bisschen Eigeninitiative da zeigen kann.“

Das ist kein Lippenbekenntnis, sondern Konsequenz aus der Produktrolle: Wer Features baut, prägt das Produkt. Wer das will, findet bei Txture die Bühne dafür.

Warum Txture für Tech-Talente attraktiv ist

Aus dem Gespräch kristallisieren sich klare Gründe heraus, die Txture für Entwicklerinnen und Entwickler spannend machen:

• Produktarbeit mit Wirkung: Eigene Produkte, direkte Nutzerwirkung, klare Roadmaps – hier gestaltet man etwas Bestehendes weiter.
• Saubere Engineering-Basis: TypeScript im großen Frontend, CraftQL für klare Schnittstellen, Kotlin/Java mit Spring im Backend, solide Testbasis, Docker/Kubernetes für reproduzierbare Umgebungen.
• Anspruchsvolle Datenmodelle: Kombination aus MongoDB, SQLite und einer eigens entwickelten Graph-Datenbank mit Versionierung.
• Strukturierte Zusammenarbeit: Scrum, Daily Stand-ups, Subtasking – und Ad-hoc-Zusammenarbeit für schnelle Problemlösung.
• Flexibilität mit Verantwortung: Freie Zeiteinteilung jenseits fixer Termine; Platz für persönliche Routinen und die Innsbrucker Natur.
• Kultur der Offenheit: Kommunikation, Teamharmonie, Spaß an der Arbeit – ohne das, so Christian, bleibt Produktivität „einfach hängen“.
• Fairer Bewerbungsprozess: Schlank, respektvoll, praxisnah – und offen für Remote wie Office in Innsbruck.
• Technologieoffenheit bei Hiring: React/TypeScript als Kern, aber willkommen sind auch Kandidaten aus Angular/Vue.js – Hauptsache, sie sind lernbereit und produktorientiert.

Was wir aus der Session mitnehmen

Im Austausch mit „Christian Esswein, Senior Full Stack Developer bei Txture“ haben wir ein Team kennengelernt, das moderne Produktentwicklung pragmatisch und fokussiert lebt. Nichts wirkt überinszeniert: Scrum ist Mittel zum Zweck, Dailys sind kurz und nützlich, technische Entscheidungen sind an Produktqualität und Delivery ausgerichtet. Dazu kommen Freiheiten, die Eigenverantwortung belohnen, und eine technologische Basis, die großen Codebasen gerecht wird.

Die Essenz lässt sich so zusammenfassen:

• Klarheit im Prozess schafft Geschwindigkeit.
• Typisierung und Tests zahlen auf Qualität und Developer Experience ein.
• Gemeinsame Architekturarbeit verhindert Insellösungen.
• Gute Kommunikation und Teamharmonie sind Produktivitätsfaktoren – keine „Soft Skills“ am Rand.

Fazit: Für Entwickler, die gestalten wollen

Txture vereint die Vorteile eines fokussierten Produktteams mit moderner Technik und echter Flexibilität. Wer Freude daran hat, in einem 8–9-köpfigen Dev-Team Verantwortung zu übernehmen, wer React/TypeScript oder Kotlin/Node.js mag (und gern dazulernt), wer Qualität über Show stellt und in einem respektvollen, offenen Miteinander arbeiten möchte, findet hier überzeugende Bedingungen.

Oder, um Christian zu zitieren: Bewerben, „einfach kontaktieren und dann schauen, was sich zusammentut“. Für uns klingt das nach einer Einladung an alle, die Produktentwicklung als Teamleistung verstehen – und Lust haben, sie mitzugestalten.