What it means to build software inside organizations serving tens and hundreds of millions of users. Quality expectations, engineering culture, product process, and what that experience brings to every project since.
What This Means For You
Most developers write code that works. Engineers who've shipped inside large-scale consumer products write code that has to keep working: under load, after a team restructure, with junior engineers picking it up a year later.
The discipline that comes from working inside organizations like Duolingo and Lufthansa Systems isn't theoretical. It comes from actually seeing what breaks when you get something wrong at scale, and building habits to prevent it.
When I bring this experience to a startup engagement, the benefit is concrete: architecture decisions that won't paint you into a corner, code that junior engineers can extend, and product thinking shaped by watching what actually moves metrics at scale.
Case 01
Duolingo is the world's most downloaded education app. Working inside a product used by hundreds of millions of people teaches you something that can't be replicated: when you ship a feature, the feedback is immediate and the consequences of getting it wrong are real.
The engineering culture at Duolingo is built around product metrics and speed. Features are A/B tested with statistically significant user populations. Decisions are driven by data. The question is never "do we like this?" It's "does it make users more likely to learn?"
That product discipline (hypothesis, ship, measure, iterate) shapes how I approach every engagement. Features exist to move outcomes, not because they're interesting to build.
Case 02
Lufthansa Systems builds software for commercial aviation operations. The Lido mPilot application is an iPad app used by airline pilots in the cockpit. It handles flight planning, navigation charts, weather data, and fuel calculations.
Aviation software operates under a completely different quality standard than consumer apps. An error in a mobile game costs a user's time. An error in cockpit software has safety implications. This context changes every engineering decision: validation is rigorous, edge cases are documented, assumptions are never implicit.
Working in this environment permanently changes how you think about correctness. "Works in testing" is not the same as "correct under all conditions." That discipline carries into everything built since.
Case 03
Bosch eBike Systems is a premium brand within one of the world's largest engineering companies. The eBike Flow app connects riders to their Bosch-powered electric bikes: firmware updates, ride statistics, navigation, and system diagnostics over Bluetooth.
Building a consumer mobile app for a premium hardware brand introduces engineering constraints that pure software products don't face: BLE connectivity is unreliable, hardware firmware versions create compatibility matrix problems, and the expectation of polish is extremely high because the brand is Bosch.
The cross-functional collaboration between mobile engineers and hardware/firmware teams is an engineering skill in itself. Understanding what the hardware layer can and can't do, and designing the software layer accordingly.
Case 04
Elli is Volkswagen Group's electric vehicle charging brand. The Elli Charging app handles charging station discovery, real-time charging status, payment, and charging history for EV owners across Europe.
Building for the Volkswagen Group means navigating large enterprise engineering processes: multiple backend teams, complex API contracts, localisation across many European markets, and strict release schedules tied to product launches.
Location services, real-time charging status polling, and payment integration in a regulatory environment like European EV charging introduce engineering complexity that goes well beyond typical app development. Reliability is a core requirement. A user trying to charge their car has zero tolerance for failures.
The Takeaway
Not code that works in demos. Enterprise engineering builds the reflex of thinking through failure modes, edge cases, and what happens when someone uses your product in a way you didn't expect.
At scale, a bad architecture decision becomes expensive to reverse. Building inside large organizations teaches you which tradeoffs matter and which ones compound into technical debt that slows teams down for years.
Building at Duolingo calibrates product intuition against real user behaviour at scale. Feature quality isn't judged by whether it looks good in a demo. It's judged by whether users actually do what you hoped.
Aviation and automotive safety standards create engineering habits that transfer everywhere. Validation, documentation, and correctness become non-negotiable instincts rather than optional practices.
Working with hardware teams at Bosch, aviation specialists at Lufthansa, and data scientists at Duolingo builds the skill of translating requirements across domain boundaries.
The lesson isn't to apply enterprise process to a startup. It's to know which practices genuinely protect quality and which ones are organizational theatre. Apply only the former.
The kind of experience that comes from building inside large organizations doesn't have to stay inside large organizations. Book a call and let's see what it looks like applied to yours.
Reach me at hello@skywaylabs.io