Vom Project-Euler-Tüftler zum React-Native-Profi: Malith Thilakarathne über White-Label-Apps, Build-Pipelines und die Kunst des Problemlösens bei hello again GmbH

Einleitung: Eine DevStory, die auf den Punkt bringt, worauf es ankommt

In der Session „Malith Thilakarathne, Mobile Developer bei hello again“ (Speaker: Malith Thilakarathne, Company: hello again GmbH) haben wir bei DevJobs.at eine erstaunlich kompakte, aber klare und ehrliche Entwicklergeschichte gehört. Ohne große Ausschmückungen zeichnet Malith den Weg vom ersten Programmierfieber über Universitätsprojekte bis hin zur täglichen Arbeit als Mobile-Entwickler mit React Native. Was dabei beeindruckt: der Fokus auf Problemlösung, die Bereitschaft, Werkzeuge zu wechseln, und der sehr praktische Blick auf Skalierung durch Automatisierung.

Aus dieser DevStory lassen sich eine ganze Reihe an Einsichten extrahieren — für Einsteiger:innen ebenso wie für erfahrene Entwickler:innen. Der rote Faden bleibt dabei stets sichtbar: Nicht die Programmiersprache, nicht der einzelne Framework-Hype und nicht einmal das „eine“ Produkt sind entscheidend, sondern die Fähigkeit, Probleme zu knacken und daraus wiederkehrende, robuste Abläufe zu bauen.

Der frühe Funke: Wettbewerbsprogrammierung als Trainingslager

Bevor Malith an die Universität ging, zog ihn eine Plattform besonders in Bann: Project Euler. Dort löste er — oft gemeinsam mit Freunden — zahlreiche Aufgaben, die ihn in die Tiefe des algorithmischen Denkens führten. Diese frühe Routine im strukturierten Denken prägt bis heute seine Herangehensweise.

Für uns ist das ein entscheidender Punkt der Story: Wer früh übt, Probleme formal zu fassen und systematisch zu lösen, baut ein Fundament, das unabhängig von konkreten Technologien trägt. Wettbewerbsaufgaben schärfen nicht nur Logik, sondern auch Durchhaltevermögen und die Fähigkeit, Lösungswege zu vergleichen — alles Fertigkeiten, die im Alltag eines Mobile-Entwicklers immer wieder abgerufen werden.

An der Uni: Vom Full-Stack-Hintergrund zur Nähe zum User

Malith kam mit einem Full-Stack-Hintergrund in die Branche und fand während der Uni Freude an Features, die unmittelbar mit Nutzer:innen interagieren. Er erzählt von vielen mobilen Projekten und dem Reiz, mit dem Frontend wirklich erfahrbar zu machen, was im Code steckt.

Dieser Übergang — von allgemeinem Full-Stack-Können zur „User-facing“-Arbeit — ist in seiner Story nicht das Ergebnis einer großen strategischen Entscheidung, sondern eine Beobachtung: Was direkten Nutzen stiftet, motiviert. Diese Motivation führt automatisch zu mehr Projekten, mehr Übung und schließlich zu größerer Sicherheit bei Frameworks und Tools.

Technologie-Evolution: Von Meteor.js und Ionic/Cordova zu React Native

Maliths technischer Weg spiegelt eine stark JavaScript-geprägte Mobile-Phase wider: Meteor.js, Ionic, Cordova — und schließlich React Native. Nicht als Sprung von Hype zu Hype, sondern als konsequente Bewegung dorthin, wo sich das Arbeiten mit Nutzeroberflächen gut anfühlt und produktiv werden lässt.

Für uns als Beobachter zeigt sich hier ein Muster, das sich bewährt hat: Wer pragmatisch bleibt und Technologien als Werkzeuge versteht, kann über mehrere Generationen von Frameworks hinweg produktiv sein. Wichtig ist nicht das „eine“ perfekte Tool, sondern die Fähigkeit, ein Problem in die passenden Bausteine zu zerlegen und die Toolchain so zu kombinieren, dass sie stabil, testbar und automationsfreundlich ist.

Heute im Alltag: React Native plus Build-Pipeline statt reine App-Schicht

Der zweite Kern dieser DevStory: Mobile-Entwicklung bei Malith ist weit mehr als UI und Komponenten. Zur täglichen Arbeit gehört eine Build-Pipeline (Jenkins) und das Schreiben von Skripten — in Python, Groovy und Bash — um immer wiederkehrende Schritte zu automatisieren.

Genau diese Kombination — App-Logik plus Build- und Release-Prozesse — macht den Unterschied zwischen einem Einmal-Projekt und einem Produkt, das in Serie ausgeliefert werden kann. Wer Build-Prozesse versteht, kann Teams entlasten, Risiken reduzieren und die Taktzahl erhöhen, ohne Qualität zu opfern. In Maliths Story ist das kein Nebenschauplatz, sondern ein integraler Bestandteil seiner Rolle.

Produktmodell: White-Label statt Einzel-App

Ein weiterer wichtiger Punkt: Bei hello again GmbH geht es nicht um eine einzelne App, sondern um eine White-Label-App, die bei beliebigen Kund:innen laufen kann. Das wirkt sich auf Architektur, Build-Prozess und Support aus.

White-Label heißt in diesem Kontext: Eine gemeinsame Basis wird so gebaut, dass sie konfigurierbar ist. Das ist kein Detail, sondern ein Architekturmuster, das jede Entscheidung beeinflusst: Wie werden Features modularisiert? Wie werden Konfigurationen gepflegt? Wo endet generische Funktionalität, wo beginnt kundenspezifischer Code? Selbst wenn Malith keine dieser Detailfragen ausführt, wird die Reichweite deutlich, wenn er die Dimension nennt: 850 Apps, die gebaut werden.

Maßstab und Konsequenzen: 850 Apps bauen heißt „Skalierung durch Skripte“

Die Zahl, die hängen bleibt, ist eindrucksvoll: 850 Apps, die gebaut werden. Wenn für ein Update „hundertfach“ gebaut werden muss, ist klar: Manuelles Vorgehen ist keine Option. Es braucht belastbare Pipelines, Automatisierung und ein waches Auge für wiederholbare Schritte.

Aus unserer Sicht ist das der praktische Beweis, dass Mobile-Engineering im White-Label-Kontext untrennbar mit DevOps-Prinzipien verbunden ist. Wer wiederkehrende Handgriffe in ausführbare, versionierte Skripte überführt, schafft Zuverlässigkeit — und hebt zugleich die Rolle der Entwickler:innen von „Code schreiben“ zu „Lieferung sicherstellen“.

Feature-Ownership und Wirkung: Warum Verantwortung motiviert

Neben Skalierung und Technik spricht Malith über Ownership. Als Entwickler sei es „darum gegangen, Features zu entwickeln“, diese tatsächlich zu besitzen und zu sehen, wie sie das Produkt beeinflussen. Dieser Satz wirkt unscheinbar, ist aber zentral: Ownership erzeugt Verantwortungsgefühl, schärft den Blick für Qualität und verankert Lernen im konkreten Produktverlauf.

Diese Perspektive macht aus der Arbeit mehr als das Abarbeiten von Tickets: Sie verknüpft technische Entscheidungen mit spürbaren Effekten. Daraus entsteht Motivation — und das Bedürfnis, die „Werkstatt“ (also die Pipeline) so einzurichten, dass die eigenen Entscheidungen zuverlässig in die Hände der Nutzer:innen gelangen.

Troubleshooting und Support: Nicht nur Code, sondern auch Rückkopplung

Malith beschreibt den Alltag nicht als reine Entwicklungsstraße. Zum Job gehören auch Fehlersuche und Support — gegenüber Kund:innen und Nutzer:innen. Das klingt zunächst wie Standard, bekommt aber in einem White-Label-Setup eine zusätzliche Dimension: Was wie ein gemeinsamer Code aussieht, trifft in der Realität auf sehr unterschiedliche Kontexte bei unterschiedlichen Kund:innen.

Wichtig daran ist die Haltung: Support ist nicht nur „Feuerlöschen“. Er ist die Rückkopplungsschleife, die hilft, bessere Automatisierungen zu bauen, robustere Defaults zu finden und Prioritäten bei der Feature-Arbeit richtig zu setzen. In einem Umfeld mit vielen Varianten zählt jede Lektion doppelt: Sie verhindert nicht nur den nächsten Fehler, sondern macht die gesamte Lieferkette ein Stück resilienter.

Sprachen sind Werkzeug — Problemlösen ist das Handwerk

Das deutlichste Statement der Session ist inhaltlich vielleicht das einfachste: Gute Problemlöser:innen sind unabhängig von einer bestimmten Sprache. Malith bringt das präzise auf den Punkt.

Aus dieser Haltung folgt ein lernfreundlicher Werkzeugkasten: Eine Sprache ist dann gut, wenn sie das Problem elegant ausdrücken lässt. Wenn nicht, wählt man eine andere — oder ergänzt mit Skripten dort, wo Automatisierung Zeit spart. So erklärt sich auch, warum in Maliths Alltag React Native zusammen mit Python, Groovy und Bash auftritt. Die Sprache passt sich dem Problem an, nicht umgekehrt.

Bildung, Selbstlernen, Projekte: Ein realistischer Lernpfad

Malith zeichnet einen Lernpfad, der uns bei DevJobs.at sehr realistisch erscheint:

• Formale Ausbildung ist „ein sehr guter Start“.
• Danach zählt Selbstlernen: neuen Technologien nachgehen.
• Und vor allem: viele Projekte machen, um Erfahrung aufzubauen.

Dieser Dreiklang ist vor allem deshalb überzeugend, weil er die Verantwortung beim Lernenden belässt, ohne den Wert der Struktur (Uni/Schule) kleinzureden. Struktur bringt Grundlagen und Tempo, Selbstlernen hält die Skills aktuell, Projekte verwandeln Wissen in Routine.

Praktische Lehren für Entwickler:innen: Was wir mitnehmen

Aus Maliths DevStory lassen sich konkrete Handlungsanregungen ableiten — ohne Spekulation, allein aus dem Gesagten:

• Pflege eine Problemlöse-Routine: Übungsplattformen (wie in seinem Fall Project Euler) helfen, Denkprozesse zu schärfen und Gelassenheit im Umgang mit Unbekanntem zu entwickeln.
• Nutze Technologien als Werkzeuge: Der Wechsel von Meteor.js/Ionic/Cordova zu React Native zeigt, dass Technologieeinflüsse kommen und gehen. Entscheidend ist die Transferfähigkeit deiner Denkweise.
• Denke in Pipelines: Mobile-Apps in großer Zahl brauchen Automatisierung. Baue Jenkins-Jobs, schreibe Skripte (Python, Groovy, Bash) und mache wiederkehrende Schritte reproduzierbar.
• Übernimm Feature-Ownership: Verantwortung erzeugt Qualität. Wer die Wirkung der eigenen Features spürt, baut nachhaltiger — und ist motivierter, die Lieferkette zu optimieren.
• Verstehe Support als Lernquelle: Troubleshooting deckt systemische Reibungspunkte auf. Was heute als Hotfix erscheint, ist morgen die Blaupause für eine Automatisierung.
• Lerne kontinuierlich: Formale Bildung ist wertvoll, aber den Ausschlag geben Selbststudium, Neugier auf neue Technologien und viele, viele Projekte.

White-Label-Skalierung gedanklich durchdeklinieren

Obwohl Malith in der Session keine tiefen Architekturdetails nennt, zeichnen seine Stichworte ein klares Bild, das Teams verallgemeinern können:

• Konfiguration statt Forking: Wenn eine Basis-App bei unterschiedlichen Kund:innen laufen soll, muss klar sein, welche Teile konfigurierbar sind und wie Konfigurationen versioniert werden.
• Reproduzierbare Builds: Wenn bei einem Update Hunderte Builds anfallen, wird Stabilität zum primären Ziel. Skripte, Idempotenz und nachvollziehbare Logs sind Pflicht.
• Team-übergreifende Automatisierung: „Automating real repetitive things for all the teams“ ist mehr als Hilfsarbeit. Es ist der Hebel, mit dem alle schneller, sicherer und konsistenter liefern.
• Messbare Ownership: Wer Features besitzt, braucht Sichtbarkeit darüber, wie sie wirken. Auch wenn Malith dazu keine Kennzahlen nennt, ist der Mechanismus klar: Ownership steuert Prioritäten und Qualitätsanspruch.

Warum gerade diese Kombination wirkt: React Native, Jenkins und Skripte

Die Tools, die Malith nennt, sind aus unterschiedlichen Welten — genau das macht sie komplementär:

• React Native: schnelles, JavaScript-basiertes Entwickeln für Mobile-Frontends.
• Jenkins: ein erprobter Orchestrator für Build-Pipelines, der sich gut skripten und erweitern lässt.
• Python, Groovy, Bash: Sprachen, die sich für Automatisierung, Skripting und leichte Glue-Tasks eignen.

Die Botschaft dahinter: Wähle Werkzeuge, die du zusammenspielen lassen kannst. Es muss nicht alles einheitlich sein, solange die Übergänge klar, die Skripte überprüfbar und die Builds deterministisch sind.

Mentale Modelle, die wir aus der Session ableiten

Jenseits der Tools bleiben zwei mentale Modelle in Erinnerung:

1) Problemorientierung statt Toolorientierung

• Frage zuerst: Was ist das Problem? Welche Schritte wiederholen sich? Wo kann Automatisierung stabilisieren?
• Wähle danach die Werkzeuge: React Native für das Frontend, Jenkins für die Pipeline, Skripte für die Klebestellen.

2) Ownership über den ganzen Weg

• Ein Feature ist erst „fertig“, wenn es zuverlässig bei den Nutzer:innen ankommt.
• Troubleshooting und Support sind keine „anderen Abteilungen“, sondern Teil derselben Verantwortung.

Diese Modelle erklären, warum die DevStory trotz ihres knappen Formats so konsistent wirkt: Alles ordnet sich der Lieferfähigkeit unter.

Empfehlungen für Nachwuchs- und Quereinsteiger:innen

Wer an Maliths Weg andocken möchte, kann klein anfangen und konsequent skalieren:

• Baue deine Problemlösekompetenz aus: Übe regelmäßig an Aufgaben, die dich zwingen, präzise zu denken.
• Arbeite an echten Features: Suche dir Projekte, die Nutzer:innen erreichen, und reflektiere aktiv, was funktioniert.
• Automatisiere früh: Nutze eine CI/CD-Lösung (wie Jenkins in Maliths Fall) und beginne, Skripte zu schreiben — anfangs klein, dann breiter.
• Dokumentiere Entscheidungen: Halte fest, warum du welche Schritte automatisierst, und wie sie in der Pipeline zusammenlaufen.
• Pflege Neugier: Verfolge neue Technologien, probiere sie in Projekten aus, statt nur darüber zu lesen.

Diese Schritte lassen sich direkt aus Maliths Erzählung ableiten — mehr braucht es für den Anfang nicht.

Was Teams lernen können: Prozess als Produkt denken

Teams, die in White-Label-Szenarien arbeiten, finden in Maliths knapper Beschreibung eine klare Prioritätenliste:

• Skaliere Wissen über Skripte: Wenn eine Person eine wiederkehrende Aufgabe sicher löst, ist der nächste Schritt, diese Lösung als Skript für alle Teams verfügbar zu machen.
• Ziehe die Pipeline in die Verantwortung: Jede Aufgabe, die manuell fehleranfällig ist, verdient eine Automatisierung.
• Gib Ownership Raum: Entwickelnde, die Features besitzen und deren Wirkung sehen, treffen bessere Architektur- und Tooling-Entscheidungen.
• Halte die Toolchain schlank: So viel wie nötig, so wenig wie möglich — Tools sollten Probleme lösen, nicht neue schaffen.

Abschluss: Eine klare Botschaft, die lange wirkt

Die Session „Malith Thilakarathne, Mobile Developer bei hello again“ lebt von Klarheit: frühe Begeisterung für Problemlösung, schrittweises Hineinwachsen in mobile Technologien, bewusster Fokus auf Build-Pipelines und Automatisierung, Ownership und Support als Einheit und ein Lernpfad, der Formalbildung, Selbstlernen und Projekte verbindet. Ohne Buzzwords und ohne Übertreibung beschreibt Malith genau das, was technische Organisationen stark macht: konsequentes Problemlösen in Kombination mit reproduzierbaren Lieferprozessen.

Wer sich an dieser DevStory orientiert, muss keine Abkürzungen suchen. Die Richtung ist klar: Lerne zu denken wie ein Problemlöser, entwickle Features, die Menschen erreichen, baue deine Pipeline mit, und lerne ständig weiter. Genau so wird aus Code Wirkung — sei es in einer einzelnen App oder, wie in Maliths Alltag, in Hunderten von Builds, die zuverlässig das Gleiche tun: Wert beim Nutzer ankommen lassen.

• 

  

  Integrating hundreds of different systems

  Markus Gasplmayr von hello again zeigt in seinem devjobs.at TechTalk den Weg, wie das Devteam hunderte verschiedene Systeme in die eigene Loyalty Solution integriert hat.

  Jetzt ansehen
• 

  

  How to build and maintain 1.000 Apps

  Michael Schöndorfer von hello again spricht in seinem devjobs.at TechTalk über die Challenge, eine große – und stetig wachsende – Anzahl an Apps zu entwickeln und zu verwalten.

  Jetzt ansehen

• 

  

  Sebastian Auberger, CIO bei hello again

  Der CIO bei hello again Sebastian Auberger redet im Interview darüber, was neue Devs erwartet – aus technologischer und aus persönlicher Perspektive – und welche Möglichkeiten zur Weiterentwicklung es gibt.

  Jetzt ansehen