Vom Schraubenzieher zur Offline‑First-App: Learnings aus „Sascha Leber, Mobile App Developer bei Kontron AG“

Einleitung: Eine DevStory über Neugier, Praxis und Nutzerfokus

Als wir „Sascha Leber, Mobile App Developer bei Kontron AG“ zuhörten, war schnell klar: Hier spricht jemand, der seinen Weg in die Softwareentwicklung nicht über perfekte Lehrbücher, sondern über Neugier, Ausprobieren und einen konsequenten Blick aufs reale Nutzungserlebnis gefunden hat. In dieser DevJobs.at-Recap fassen wir zusammen, wie Sascha vom frühen Herumschrauben an Altgeräten über die HTL-Sprengergasse bis hin zur täglichen Arbeit in der mobilen Entwicklung gekommen ist – und welche Prinzipien ihn heute leiten: agil denken, offline‑first bauen, Verantwortung fürs Produktdesign mittragen und sich tief in die Perspektive der Nutzer hineinversetzen.

Diese Geschichte ist kein Hochglanz-Märchen. Sie beginnt mit abgestürzten Laptops, geht weiter über erste Batch-Skripte und landet in einer Arbeitsweise, in der Stand-ups, Product Owner, lokale Datenspeicherung und aktives Zuhören den Ton angeben. Vor allem aber zeigt sie, wie persönliche Erfahrungen zu handfesten, umsetzbaren Einsichten für Entwicklerinnen und Entwickler werden.

Früh übt sich: Schrauben, Zerlegen, Verstehen

Saschas Weg begann – so wörtlich er es beschreibt – „eh ganz früh in meiner Kindheit“. Er stand neben alten PCs und Handys, öffnete sie, zerlegte Komponenten und suchte Antworten auf eine einfache Frage: Wie funktioniert das? Dieses intuitive Forschen ist der rote Faden seiner DevStory. Es ist das Gegenteil von passivem Konsum: sehen, anfassen, auseinandernehmen, wieder zusammenbauen.

Ein Schlüsselmoment folgte, als er seinen ersten Laptop bekam und „zufällig über Batch-Skripte drüber gefallen“ ist. Anstatt beim Klicken zu bleiben, testete er, wie man dem Computer Dinge sagen kann, „dass er das halt irgendwie selber tut“. Der Weg war nicht friktionsfrei: „Einmal ist er mal abgestürzt, einmal hab ich ihn ein bisschen zu viel belastet.“ Genau diese Friktionen – der Crash, die Überlastung – machten aus Neugier produktives Lernen. Wer automatisiert, findet Grenzen; wer Grenzen findet, baut Kompetenz auf.

Von der HTL-Sprengergasse zur Praxis: breite Basis, klare Richtung

Aus dem „Informatiker-Ding“ wurde ein klarer Werdegang. Sascha entschied sich für die HTL-Sprengergasse, Zweig Informatik. Wichtig ist hier die Breite: Elektronik, Datenbanken, Netzwerke und natürlich Programmieren. Diese Spannweite half, mehr als nur eine Programmiersprache zu sehen. Es ist der Blick auf Systeme, Datenflüsse und Architektur, der aus einzelnen Tools ein Handwerk macht.

Doch der Wendepunkt liegt nicht in theoretischen Stundenplänen, sondern in der Anwendung. Über Kontron bekam er „schon neben der Schule“ die Möglichkeit, praktische Erfahrungen zu sammeln. Dieser frühe Transfer von Theorie in Praxis zieht sich wie ein Mantra durch seine Erzählung. Und er bestätigt ihn später ausdrücklich: Nach dem Zivildienst kehrte er zu Kontron zurück – diesmal Vollzeit – und stieg als Frontend‑Mobile‑App‑Developer ein.

Frontend statt Backend: Sichtbarkeit als Motivation

Ein weiteres Motiv in Saschas Geschichte: Er will sehen, was er tut. Zwar hat er „auch Backend-Sachen probiert“, doch schnell merkte er, „dass mir das Backend nicht so viel liegt wie das Frontend, weil ich halt doch gern seh, was ich tu“. Das ist weder ein Urteil über Backend noch eine Dogmatik. Es ist ein persönlicher Entscheidungsfilter: Wo motiviert mich Wirkung am meisten? Für Sascha liegt die Antwort in visueller, greifbarer Entwicklung.

Sein Einstieg verlief über Angular als „erstes Einstiegsprojekt noch während der Schule“, um das Frontend kennenzulernen. Über die Jahre rutschte er „in die App-Entwicklung rein“ – und blieb dort. Ein organischer Übergang: von der Weboberfläche hin zur mobilen Interaktion, vom Browser hin zum Gerät in der Hand.

Agiler Alltag: Stand-ups, Product Owner – und kritisches Hinterfragen

Sascha beschreibt die Arbeitsweise seines Teams als „ein bisschen agil“. Entscheidend sind die täglichen Stand-ups, die Anforderungen von den Product Ownern und vor allem die Verantwortung, nicht nur umzusetzen, sondern zu hinterfragen. Seine Formulierung bringt es auf den Punkt: „Wir sind ja dafür da, praktisch gute Lösungen zu finden und nicht nur für uns theoretisch gute Lösungen.“

Zwischen Zeilen liest man hier zwei Reflexe, die gute Produktarbeit prägen:

• Anforderungen ernst nehmen – aber nicht unkritisch. Was steht dahinter? Welches Problem wird tatsächlich gelöst?
• Hypothesen mit der Wirklichkeit abgleichen. „Was glauben wir, das gut ist“ vs. „was ist in der Wirklichkeit gut“. Dieser Spannungsbogen wird täglich neu verhandelt.

Diese Haltung ist kein Selbstzweck. Sie ist ein Prozess-Schutz gegen Schönwetter-Planung. Sie funktioniert nur, wenn Entwicklerinnen und Entwickler Verantwortung für das Produkt mitübernehmen – also fragen, messen, zuhören und gegebenenfalls Kurskorrekturen vorschlagen.

Technologie und Architektur: Offline‑First mit „Rafflata“ und Couchbase

Sascha benennt explizit, was das Team für die Mobile-App-Entwicklung verwendet: „Rafflata in Kombination mit Couchbase“. Das Ziel: offline‑first. Die Nutzer sollen weiterarbeiten können, „wenn er kein Internet hat“.

Dieser Ansatz erzwingt konzeptionelle Klarheit. Das Team muss „schauen, welche Daten haben wir direkt am Handy, was könnten wir theoretisch noch von Remote holen, wenn er wieder Internet hat“. Darin liegen die alltäglichen Challenges: Was braucht der Nutzer wirklich vor Ort – zum Beispiel „wenn er jetzt gerade mal kurz irgendwo in den Keller geht“ – und was nicht?

Warum offline‑first mehr als ein Feature ist

Offline‑first ist hier kein nettes Add-on. Es verändert die Reihenfolge der Fragen:

1. Welche Aufgaben muss der Nutzer ohne Verbindung sicher erfüllen können?
2. Welche Daten sind dafür minimal erforderlich – und wie bleiben sie aktuell genug?
3. Wie synchronisieren wir später, ohne den Nutzer zu stören oder Daten zu riskieren?

Diese Dreifaltigkeit aus Nutzeraufgabe, Datenstrategie und Synchronisationslogik spiegelt genau das wider, worauf Sascha wiederholt pocht: Praxis vor Theorie, Kontext vor Feature-Liste. Offline‑first heißt, realistische Nutzungsszenarien zur architekturellen Leitplanke zu machen.

Gestaltung als Verantwortung: Anforderungen verstehen, End-Design tragen

Ein bemerkenswerter Punkt in Saschas Erzählung betrifft die Gestaltung. Das Team erhält „die ganzen Anforderungen textlich oder auch mit Grafiken, wie es ungefähr ausschauen soll“. Gleichzeitig „liegt das End-Design quasi bei uns“. Die Entwickler dürfen – und sollen – sich „wirklich selber verwirklichen“.

Diese Handlungsfreiheit ist Chance und Verpflichtung zugleich:

• Chance, weil diejenigen, die am nächsten am Code sind, auch die Feinheiten des Nutzererlebnisses schärfen können.
• Verpflichtung, weil Selbstverwirklichung ohne Nutzerblick riskant ist. Das Team muss die „ungefähren“ Spezifikationen so verfeinern, dass sie in realen Situationen überzeugen.

Interessant ist, wie nahtlos sich das zu Saschas Grundhaltung fügt: kritisches Hinterfragen, echtes Nutzungsszenario, Feedback einbeziehen. Design ist hier kein Lack, sondern Teil des Problemlösens.

Der Blick des Endnutzers: Empathie, Haptik, Situation

Ein Kernstück seiner Ratschläge dreht sich um Perspektivwechsel. Er spricht davon, „dass ich mich in diese Person hineindenke als End-User“. Was tue ich gerade? Wie stehe ich draußen? Wie halte ich das Handy? Wo drücke ich? Das sind keine akademischen Fragen. Es sind die Stellschrauben, mit denen mobile Erlebnisse flüssig werden.

Diese Sensibilität hat Konsequenzen in allen Phasen:

• Beim Definieren der Anforderungen: Welche Handlungsschritte sind wirklich nötig?
• Beim UI-Design: Welche Elemente müssen erreichbar sein, auch mit einer Hand?
• Bei Fehlermeldungen: Was hilft dem Nutzer in der Situation – jetzt, sofort?
• Bei Offline-Fällen: Welche Hinweise und Übergänge sind selbsterklärend?

Am Ende ist es genau diese Nähe zur Nutzungssituation, die Sascha mehrfach betont: „User-Feedback einfach mit einbeziehen, den Leuten zuhören aktiv.“

Praxis vor Theorie: Machen, Mitmachen, Mitdenken

Saschas persönliches Lernmuster ist eindeutig: so früh wie möglich praktisch werden. Er schildert, wie er sich „oft viele Anleitungen durchgelesen, Videos angeschaut“ hat, aber „nur von der Theorie her kommt man halt irgendwie nicht recht weit“. Der Durchbruch kommt beim Tun: „wirklich was ausprobiert“, „in Kombination mit anderen Menschen irgendwo zugeschaut“, „ein bisschen geholfen“, „Sachen hinterfragt“.

Diese Haltung lässt sich in drei Leitsätze fassen:

1. Theorie bildet – Praxis prägt. Ohne Berührung mit echten Problemen bleibt das Verständnis lückenhaft.
2. Lernen ist sozial. Zuschauen, Fragen stellen, gemeinsam debuggen – der Kontext anderer erweitert den eigenen Denkrahmen.
3. Hinterfragen ist zentral. Nicht jede bekannte Lösung passt zum aktuellen Problem. Nicht jedes Pattern löst jede Edge-Case.

Alltag im agilen Setup: Zwischen Annahme und Realität vermitteln

Wenn Sascha über den täglichen Rhythmus spricht – „wir haben jeden Tag unsere Stand-Ups“ – wird greifbar, wie kontinuierlich das Team Erwartungen und Realität synchronisiert. Product Owner liefern Anforderungen; das Development-Team spiegelt zurück: Was ist plausibel, was ist riskant, was ist aus Sicht realer Nutzungsszenarien sinnvoll?

Dieses Zusammenspiel ist nicht nur Verfahrenstechnik. Es ist Kultur. Es setzt Vertrauen voraus – dass Fragen geschätzt, Kurskorrekturen akzeptiert und Nutzererlebnisse über Egos gestellt werden. Das Ergebnis ist jene Produktreife, die Sascha so beschreibt: „Mittlerweile habe ich da, glaube ich, ein recht gutes Gefühl dafür.“ Erfahrung ist hier nicht Anzahl der Jahre, sondern Anzahl der geschlossenen Feedback-Schleifen.

Konkrete Challenges im Offline‑First-Kontext

Die von Sascha skizzierten Fragen rund um lokale Daten und nachträgliche Synchronisation lassen sich in typische alltägliche Entscheidungen übersetzen:

• Welche Daten müssen persistent direkt auf dem Gerät verfügbar sein, damit Arbeitsabläufe nie blockieren?
• Welche Daten sind „nice to have“ und können on-demand geladen werden, sobald wieder Netz vorhanden ist?
• Wie wird der Nutzer über den Status (offline/online, synchronisiert/nicht synchronisiert) informiert, ohne ihn zu überfordern?
• Welche Konfliktfälle können beim späteren Abgleich auftreten – und wie wird darüber entschieden oder der Nutzer einbezogen?

Diese Fragen sind kein Overengineering, sondern praktische Produktarbeit. Sie bestimmen, ob jemand im „Keller“ – Saschas Beispiel – weiterarbeiten kann, ohne jedes Mal den Faden zu verlieren.

Selbstverwirklichung mit Verantwortung: Warum „cool ausschauen“ nicht genügt

Sascha erwähnt den Reiz, wenn etwas Programmiertes „gleich aufgeschieden ist und das ist einfach cool ausgeschaut“. Dieser Motivator ist wertvoll – Feedback in Millisekunden. Gleichzeitig koppelt er ihn eng an Realitätstests. „Was glauben wir, das gut ist“ darf nicht unkritisch als „ist gut“ durchrutschen. Erst wenn das „cool“ auch im Feld trägt, ist es wirklich wertvoll.

Das erklärt, warum im Team die Freiheit beim End-Design stets von Nutzertests, Feedback und einer skeptischen Haltung begleitet wird. In dieser Balance entsteht Qualität: sichtbar, benutzbar, belastbar.

Was Einsteigerinnen und Einsteiger aus dieser DevStory mitnehmen können

Aus Saschas Weg destillieren sich klare Ratschläge, die ohne Buzzwords auskommen:

• Früh praktisch werden: Tutorials sind Startpunkte, keine Ziellinien. Baue etwas Kleines, bring es zum Laufen, brich es, repariere es.
• Mit anderen lernen: Schau Kolleginnen und Kollegen zu, frage nach, hilf mit. Gemeinsames Problemlösen beschleunigt Verständnis.
• Echtes Nutzerverhalten denken: Stelle dir konkrete Situationen vor – Standort, Haltung, Unterbrechungen, Offline-Fälle.
• Anforderungen hinterfragen: „Warum“ und „wie genau“ sind keine Störfragen, sondern die Grundlage für gute Lösungen.
• Offline‑Strategie ernst nehmen: Entscheide bewusst, welche Daten lokal sein müssen und wie Resynchronisation gelingt.
• Design als Teamaufgabe: Wenn das End-Design bei euch liegt, entsteht aus Verantwortung Qualität. Nutzt diese Chance.

Was Teams aus dieser DevStory mitnehmen können

Für Teams, die ähnliche Produkte bauen, sind die Linien ebenfalls klar erkennbar:

• Agiler Rhythmus mit echtem Nutzerfokus: Stand-ups sind wertlos, wenn sie nicht mit kritischem Hinterfragen gekoppelt sind.
• Produktownership im Development: Entwickler sollten nicht nur „umsetzen“, sondern die Alltagsrealität mitdenken.
• Technologie auf Ziel ausrichten: Tool-Entscheidungen – hier „Rafflata“ plus Couchbase – ergeben Sinn, wenn sie das Hauptproblem (Offline-Fähigkeit) lösen helfen.
• Feedback-Schleifen schließen: Aktiv zuhören, früh testen, Anpassungen zulassen. Erfahrung entsteht im Durchlauf, nicht im Plan.

Zitate und Paraphrasen, die hängen bleiben

• „Wir verwenden … in Kombination mit Couchbase, weil wir … offline-first … machen.“
• „Wir sind … selber in der Verantwortung, … kritisch hinterfragen und schauen, wie tun die Leute draußen wirklich.“
• „Sobald man mal eine gewisse theoretische Basis hat, relativ schnell mit praktischen Sachen beginnen.“
• „In den User hineinfühlen … den Leuten zuhören aktiv.“

Diese Sätze sind keine Floskeln. Sie beschreiben ein Handwerk, das sich an realen Situationen orientiert – und an der Bereitschaft, kontinuierlich zu lernen.

Fazit: Eine DevStory, die zum Handeln einlädt

„Sascha Leber, Mobile App Developer bei Kontron AG“ erzählt keine Geschichte von Abkürzungen, sondern eine von Entscheidungen: neugierig sein, kaputt machen dürfen, wieder aufbauen; Grundlagen schaffen, Praxis suchen; Frontend wählen, weil Wirkung motiviert; offline‑first denken, weil Realität unzuverlässig ist; Design als Mitverantwortung begreifen; Nutzern zuhören und die eigenen Annahmen prüfen.

Wir nehmen aus dieser Session mit, dass gute mobile Produkte dort entstehen, wo Technik, Prozess und Empathie zusammenkommen. Und dass der Weg dorthin nicht kompliziert, aber konsequent ist: früher anfangen, öfter fragen, näher dran sein.

Oder, um es in Saschas Geist zusammenzufassen: Baue, was Menschen draußen wirklich brauchen – auch dann, wenn der Empfang kurz weg ist. Und höre ihnen zu, damit aus „cool“ auch „praktisch gut“ wird.

• 

  

  Florian Fiby, Teamlead ITSM Development bei Kontron AG

  Florian Fiby von Kontron AG umreißt im Interview den Aufbau der Teams im Unternehmen, mit welchen Technologien gearbeitet wird und was bei Bewerbungen und neuen Mitarbeitern wichtig ist.

  Jetzt ansehen