From Tinkering to Offline‑First: What We Learned from “Sascha Leber, Mobile App Developer bei Kontron AG”

Introduction: A devstory about curiosity, practice, and user empathy

Listening to “Sascha Leber, Mobile App Developer bei Kontron AG,” one thing stood out immediately: this is a developer who built his path not through spotless textbook progressions but through curiosity, hands-on experimentation, and an unwavering focus on how software is actually used. In this DevJobs.at recap, we trace how Sascha went from dismantling old devices and dabbling in batch scripts to daily mobile development work shaped by agile rhythms, offline‑first architecture, shared design responsibility, and active listening to users.

This is not a polished fairy tale. It begins with crashed laptops, overtaxed machines, and the first taste of automation. It passes through HTL-Sprengergasse and lands in a working style where stand-ups, Product Owners, on-device data, and user empathy set the tone. Most of all, it’s a story about turning personal experience into practical, repeatable principles for software teams.

Early spark: Taking things apart to understand how they work

Sascha describes a childhood spent standing next to old PCs and phones, opening them up, and asking a simple question: how does this work? Curiosity led to contact with the guts of technology. The turning point arrived when he got his first laptop and “stumbled across batch scripts.” Instead of just clicking around, he tested how to instruct a computer to do tasks “by itself.” The learning curve included friction: “once it crashed, once I overloaded it a bit.” Those moments weren’t failures; they were formative. When you automate, you meet limits. When you hit limits, you build real understanding.

From HTL-Sprengergasse to real-world application: Broad base, clear direction

What started as an interest in the “Informatiker thing” became a structured path at HTL-Sprengergasse, focusing on informatics. The emphasis there was breadth: electronics, databases, networks, and programming. That range matters; it pushes you beyond a single language or tool and toward systems thinking.

The pivot, however, was not just curricular breadth but early practice. Through Kontron, Sascha got hands-on experience “already alongside school.” Later, after civilian service, he returned to Kontron full-time as a Frontend Mobile App Developer. That continuity—learn a bit, ship a bit, repeat—shaped his trajectory.

Frontend over backend: Motivation through visible results

Sascha tried backend tasks but “pretty quickly realized” that backend didn’t fit him as well as frontend. Why? Because he likes to see what he’s doing. The visual feedback loop in frontend work was the motivator. He started with Angular on his first school-time project to get to know frontend. Over the years he “slid into app development”—and stayed there. It’s a natural migration: from browser-based UI to handheld experiences.

Agile cadence: Stand-ups, Product Owners—and critical questioning

Sascha portrays his team’s workflow as “a bit agile.” The mechanics are familiar: daily stand-ups and requirements handed down by Product Owners. But the cultural core is sharper: developers aren’t just implementers. They’re responsible for questioning assumptions and validating ideas in the context of real-world use.

He frames the mission clearly: “We are here to find practically good solutions, not just theoretically good solutions for ourselves.” Two reflexes follow from that stance:

• Take requirements seriously—but not blindly. What problem is truly being solved?
• Compare assumptions with reality. “What we think is good” vs. “what is good in the real world.”

This is more than process hygiene. It’s how you prevent sunny-day plans from drifting into products that fail under cloudy conditions.

Stack and architecture: Offline‑first with “Rafflata” and Couchbase

Sascha names the core of their mobile stack: “Rafflata in combination with Couchbase.” The goal is offline‑first: users should be able to keep working “when they don’t have internet.” That framing reorders engineering priorities. The team must constantly decide “which data we have directly on the phone” and “what we could theoretically fetch from remote when [the user] has internet again.”

The practical challenges are immediate. Which data must always be available on-device? Which can wait until connectivity returns? Sascha grounds it in a simple scene: someone walking into a basement. Even a brief loss of connection shouldn’t derail the task at hand. Offline‑first isn’t an afterthought; it’s a product promise.

Why offline‑first is more than a feature

Treating offline‑first seriously forces clear decisions up front:

1. What tasks must be fully supported without a connection?
2. What is the minimum data needed locally to complete those tasks reliably?
3. How do we reconcile and sync later—quietly and safely—once the device is back online?

Those questions echo Sascha’s recurring theme: put practical use before theoretical neatness. Architecture must follow the realities of field work, not the other way around.

Design as a shared responsibility: Specifications and end design in one team

A striking detail in Sascha’s account is how design ownership is shared. The team receives “textual or graphical” requirements that sketch how the app should look. Yet, as he explains, “the end design lies with us,” and the team is allowed to “really express ourselves.”

That’s both an opportunity and an obligation:

• It’s a chance because the people closest to the code can refine the nuances of user experience.
• It’s a responsibility because self-expression without user empathy can drift. The team must take those “roughly” defined specs and shape them into something resilient in real scenarios.

This dovetails with Sascha’s broader posture: question assumptions, test in context, incorporate feedback.

User perspective: Empathy, posture, and the tap that matters

Sascha urges developers to think in the end user’s shoes: What am I doing right now? How am I standing outside? How am I holding the phone? Where do I tap? These questions aren’t academic. They are the exact knobs that turn a mobile flow from clumsy to smooth.

The implications ripple through the stack:

• During requirements: Which steps are essential, and which are friction?
• In the UI: What must be reachable one-handed? What is the primary action?
• For errors and edge cases: What helps the user in this very situation—right now?
• Around offline behavior: Which cues and transitions are self-explanatory?

His punchline lands plainly: include user feedback and “listen actively.”

Practice over theory: Build, watch, help, ask

Sascha is explicit about learning: “Once you have a certain theoretical basis, you should start with practical things relatively quickly.” He recalls reading many guides and watching videos, but “just from theory you don’t get very far.” The breakthrough comes from doing: “really trying things,” “watching others,” “helping a bit,” and “questioning things.”

If we distill that mindset:

1. Theory informs—practice transforms. Without taking on real tasks, understanding remains brittle.
2. Learning is social. Observe, ask questions, pair up, co-debug. Other people’s context expands your own.
3. Question defaults. Common patterns don’t solve every edge case. Map solutions to situations, not the other way around.

The daily loop: Mediating between assumptions and reality

With daily stand-ups as the heartbeat, Sascha’s team continually reconciles plan and field. Product Owners set requirements; the development team reflects back: What’s feasible? What’s risky? What makes sense in actual usage?

That interplay is more than ceremony. It’s culture. It relies on trust—that questions are welcomed, course corrections are okay, and user experience outranks ego. The outcome is product intuition forged by closed feedback loops: “By now I think I have a pretty good feel for it.”

Concrete offline‑first challenges, day by day

The dilemmas Sascha highlights turn into everyday product decisions:

• Which data absolutely must be on-device so workflows never stall?
• Which can be fetched opportunistically once the connection returns?
• How do we surface offline/online and sync status without overwhelming the user?
• Where might conflicts appear on reconnection, and who decides how to resolve them?

These aren’t abstract concerns; they determine whether someone can keep working “in the basement,” to borrow Sascha’s example, without losing momentum.

The spark of visibility—and the discipline of reality checks

Sascha doesn’t hide the joy of seeing code spring to life: when something “shows up right away” and “looks cool.” That instant feedback is energizing. But he pairs it with a steady discipline: a “cool” UI isn’t good enough unless it survives contact with reality. That’s why his team’s design freedom is tightly coupled to user feedback, questioning, and iterative refinement.

What newcomers can take from this devstory

• Start building early: Tutorials are launchpads, not finish lines. Ship something small, break it, fix it.
• Learn with others: Watch colleagues, ask questions, co-create. Social learning accelerates depth.
• Think in real usage: Picture posture, environment, interruptions, and offline moments.
• Question requirements: “Why” and “how exactly” are not blockers; they’re the path to fit-for-purpose solutions.
• Treat offline strategy as core: Decide deliberately what lives locally and how reconciliation works.
• Own the design you touch: If “the end design lies with us,” quality is your responsibility. Use that agency.

What teams can take from this devstory

• Agile rhythm with real user focus: Stand-ups are pointless without critical inquiry.
• Product ownership in engineering: Developers should co-own reality checks and field context.
• Align tools with outcomes: The chosen stack—“Rafflata” plus Couchbase—serves the offline‑first goal.
• Close feedback loops: Listen actively, test early, adjust often. Experience comes from cycles, not slide decks.

Quotes and paraphrases that stick

• “We use [our mobile stack] in combination with Couchbase because we try to do offline‑first.”
• “We are responsible for questioning and checking how people really do things out there.”
• “Once you have some theoretical basis, start practical work relatively quickly.”
• “Empathize with the user … include user feedback and listen actively.”

These aren’t slogans. They’re a craft shaped by real situations—and by the willingness to learn continuously.

Conclusion: A developer’s path that invites action

“Sascha Leber, Mobile App Developer bei Kontron AG” is not about shortcuts. It’s about choices: be curious, break things, rebuild. Build foundations, seek practice. Choose frontend if visible impact motivates you. Embrace offline‑first because the real world is messy. Treat design as shared responsibility. Listen to users and pressure-test your assumptions.

Our takeaway from this session is simple but demanding: great mobile products emerge where technology, process, and empathy meet. Getting there isn’t complicated, but it is consistent—start earlier, ask more, stand closer to real use.

Or, to channel Sascha’s spirit: build what people truly need out there—even when the signal drops—and listen so that “cool” also becomes “practically good.”

• 

  

  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.

  Watch now