From Project Euler to Shipping Hundreds of Builds: Malith Thilakarathne on React Native, Jenkins, and Problem Solving at hello again GmbH

Introduction: A compact DevStory with big lessons

In the session “Malith Thilakarathne, Mobile Developer bei hello again” (Speaker: Malith Thilakarathne, Company: hello again GmbH), we at DevJobs.at heard a refreshingly straightforward developer journey. Malith walks from an early fascination with competitive programming to hands-on mobile work, and into the daily reality of React Native engineering paired with build pipelines and automation.

What stood out is the clarity of priorities: get good at problem solving, follow the work that touches users, evolve your toolkit pragmatically, and engineer delivery at scale through scripts and pipelines. Rather than chasing a single language or a silver-bullet framework, Malith centers the craft around repeatable thinking and reproducible builds.

The early spark: Competitive programming as a training ground

Before university, Malith found his way into programming through Project Euler with friends. He highlights how solving many problems there drew him into the field and honed the mindset that keeps paying dividends.

This is a familiar but powerful pattern: structured puzzles build the habits of decomposition, iteration, and comparison of approaches. Those habits transfer directly to product work, where confidence grows from working systematically through ambiguity.

At university: From full stack to user-facing features

Malith came into the industry as a full stack developer. During university, a preference emerged: working on features that interact with users. That pulled him into building many mobile apps and reinforced a practical focus on the interface where software becomes experience.

This shift isn’t framed as a grand plan. It’s the natural gravity of motivation: when you see users interact with what you build, you want to build more, test more, and learn the tools that help you iterate faster.

Evolution of tools: Meteor.js, Ionic/Cordova, and finally React Native

The tools Malith lists trace a JavaScript-first path into mobile: Meteor.js, then Ionic and Cordova, and eventually React Native. It reads less like hopping trends and more like the journey of someone following where productivity and user-facing work converge.

The lesson is durable: treat technologies as tools, not identities. What matters is the problem you’re solving, the reliability of your delivery, and the speed with which you can validate what you’ve built.

Day-to-day: It’s not just the app, it’s the pipeline

Today, Malith works with React Native — and he draws a clean boundary: mobile isn’t only about UI or the app surface. A significant part of the work is build pipelines and scripting to automate repeatable steps.

This pairing — product code plus delivery machinery — separates a one-off app from a system that can ship reliably. When you understand the pipeline, you de-risk releases, speed up feedback loops, and reduce toil across teams.

Product model: White-label rather than a single app

Malith highlights the product approach at hello again GmbH as a white-label mobile app that can run for any client. That choice shapes architecture, build, and support in very practical ways.

White-label, in practice, means the base needs to be configurable and the build process needs to enforce consistency across variations. Even without deep architectural detail, the implications become concrete when Malith shares the scale they’re handling: “850 apps that we are building.”

Scale and consequence: 850 apps, hundreds of builds per update

The number that sticks is scale. When a single update can translate into building hundreds of apps, manual handling stops being an option. Pipelines, scripts, and determinism become the backbone of engineering.

This is where DevOps thinking is inseparable from mobile engineering. The same instincts that help you solve algorithmic puzzles now help you stabilize delivery: capture repeatable steps as code, make builds reproducible, and lift the team by turning local fixes into shared automation.

Feature ownership and visible impact

Malith underscores feature ownership as a core motivator: you develop features, you own them, and you get to see how they impact the product.

Ownership closes the loop between design, implementation, and outcome. When you feel that loop, you care differently about quality, documentation, and the pipeline that carries your work into users’ hands.

Troubleshooting and support: The feedback loop in production

The day-to-day isn’t only feature work. Troubleshooting and support for clients and users are part of the role — especially meaningful when a shared codebase runs across many client contexts.

That work is not just fire-fighting. It’s where you discover systemic friction, opportunities for new scripts, and better defaults. In a white-label setup, every lesson you capture can pay off across many variants.

Languages as tools — problem solving as the craft

Malith’s clearest statement is also the most generalizable: if you’re good at problem solving, the language you start with matters far less.

This is the through-line that explains his tool choices. React Native for product code; Python, Groovy, and Bash where automation brings leverage; Jenkins to orchestrate reliable builds. The problem chooses the tool, not the other way around.

Education, self-learning, and many projects

On growth, Malith balances structure with initiative. Formal education is a strong start. To become an expert, you need to pursue self-learning, chase new technologies, and do many projects to accumulate experience.

That trilogy lines up with what we consistently see: fundamentals from education, currency from self-learning, and depth from projects that force trade-offs and require delivery.

Practical takeaways for developers

Without extrapolating beyond what Malith shares, there are concrete practices you can adopt:

• Build a problem-solving habit: regular exposure to structured challenges (like his early Project Euler work) strengthens the muscles you’ll use in product code and operations.
• Treat tools as means, not ends: moving from Meteor.js/Ionic/Cordova to React Native shows that adaptability is an asset. Transfer the thinking, not the hype.
• Think in pipelines: if an update fans out to hundreds of builds, your real product is the system that ships. Use Jenkins. Write scripts in languages that help you move fast — Python, Groovy, Bash.
• Own features end-to-end: when you feel the impact of your work, you naturally care about quality, documentation, and automation.
• Let support inform engineering: the issues you troubleshoot today can become tomorrow’s automations and defaults that help every team.
• Keep learning: formal education gets you in the door; self-learning and many projects give you momentum and judgment.

White-label at scale: working principles you can reuse

Even without deep specifics, the contours of Malith’s setup suggest reusable principles:

• Configuration over forking: if the same base runs for many clients, define what’s configurable and how configuration is versioned.
• Reproducible builds: when updates multiply across variants, idempotent scripts and transparent logs are a necessity.
• Automation as a shared asset: “automating real repetitive things for all the teams” is multiplicative leverage. Invest in it.
• Ownership as alignment: if developers own features and see product impact, priorities and quality naturally align with outcomes.

Why this stack combination works in practice

The tools Malith mentions are pragmatic and complementary:

• React Native for user-facing speed and a unified product codebase.
• Jenkins to orchestrate builds and encode release workflows.
• Python, Groovy, and Bash to script the glue and turn manual steps into repeatable code.

The message is simple: choose tools you can make work together, value determinism over novelty, and script away the toil that slows teams down.

Mental models that frame the work

Two mental models summarize the session’s through-line:

1) Problem-first, tool-second

• Identify the problem and the repeatable steps. Then pick the tool that makes those steps reliable.

2) Ownership across the delivery path

• A feature isn’t done until it reliably reaches users. Troubleshooting and support sit in the same loop, not in a separate silo.

These models explain why Malith’s story feels cohesive: it’s all organized around shipping reliably at scale.

Getting started: a practical progression for newcomers

If you want to follow the arc Malith describes, start small and compound:

• Practice systematically: strengthen problem-solving with consistent, structured challenges.
• Build user-facing features: choose projects that make impact visible and motivate iterative improvement.
• Automate early: add a CI/CD tool (as in his case, Jenkins) and begin writing scripts — initially for local tasks, then across teams.
• Document your pipeline: as you automate, record the why and how. Make it easy for teammates to reuse and improve.
• Stay curious: track new technologies and test them in projects. Experience beats theory.

Closing: A clear signal through the noise

The session “Malith Thilakarathne, Mobile Developer bei hello again” is concise but rich in signal. Early problem-solving, a gradual move into mobile, a day-to-day anchored in React Native plus pipelines and scripts, ownership tied to product impact, and a growth path that blends formal education, self-learning, and projects.

The core message is durable: think like a problem solver, build features that reach users, engineer your pipeline, and keep learning. Whether you’re shipping a single app or, as in Malith’s environment, triggering hundreds of builds for an update, the same discipline applies — make delivery repeatable so your code can reliably become value in users’ hands.

• 

  

  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.

  Watch now
• 

  

  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.

  Watch now

• 

  

  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.

  Watch now