Why Couldn't Mobile Build a Solid Foundation?

There is an observation that has been nagging me for a while: Why do we see more people who came from backend at senior levels like CTO, staff, and principal? Beneath this question lies an even more fundamental one: why couldn’t frontend reach a mature, shared engineering standard? I think the answer has nothing to do with talent, and everything to do with history and timing.

The foundation backend inherited

Backend is the direct heir of computer science’s academic tradition. The people who built the computer were mathematicians, and everything we consider fundamental today, like algorithms, data structures, databases, and testing reflexes, all came from academia. So backend was born on top of a tradition where discipline was already an expectation; that culture was ready. Mobile and frontend, on the other hand, were born into a completely different environment: consumption, product focus, ship first. What’s more, this accumulation in backend didn’t form overnight: design patterns, layered architecture, transaction management, caching, indexing strategies… It settled in slowly over half a century of history stretching from the mainframe days to enterprise software, to ASP.NET and Java foundations.

Alongside this, there was a second thing feeding daily practice: errors hitting the engineer in the face. In backend, an error lands in your log, instantly, pointing at the culprit. In mobile, the error blows up on the user’s device while you are not there; and what’s more, most errors (broken layout, regression, wrong behavior) are not even a crash, meaning they never reach you. An error is expensive in both worlds; but one warns you instantly, while the other quietly loses the user and has to be measured.

In short, backend didn’t build this discipline because it was “a better engineer”. Two things worked in its favor at once: one, it was born into an academic tradition where discipline was already the standard; two, because the errors it made hit it in the face instantly, that discipline was constantly reinforced. Now add time on top of these, and this necessity found the time to stop being the habit of individual people and turn into a shared culture. In mobile, none of these three existed: neither a ready tradition, nor an error that hits you in the face, nor enough time for a culture to settle.

That’s why some things are taken as beyond debate in a backend team today. Contract tests are written. Work proceeds over protocols. A database engineer already knows many optimizations, from choosing the right index to how to use the cache. This knowledge does not live in the heads of individual people; it lives in the community’s shared memory. When a new junior arrives, they are born into this foundation.

Let me give a concrete example. In a place where two backend services talk to each other, fixing the “agreement” (contract) between them with a test has become routine. If one side makes a change, the test warns instantly and that change is stopped before it moves to production. This is not a luxury that someone added thinking “let me do good engineering”; it is an unquestioned reflex already engraved into the team’s shared memory. Someone new doesn’t question it; they adopt it as part of the culture they were born into.

Frontend was born in the middle of a sprint

Frontend, on the other hand, was born into a completely different world. Naturally I will focus on mobile: the iPhone came out in 2007, the App Store in 2008. So today the mobile ecosystem isn’t even 20 years old yet.

My own story sums up the part up to here too. Back when I was building on Symbian, in the whole world there was a single person on the Nokia forums I could ask questions to. There was no proper documentation, no book, no other resource. Then the iPhone 2.0 SDK was released and I moved there; under Apple’s leadership this gap closed a bit over time. But this improvement always stayed within a narrow, self-contained circle. That focused conversation didn’t touch the people outside, the broader engineering world; it couldn’t turn into a wave that would let frontend reach a shared standard.

And this young ecosystem fell right into the middle of one of the fastest growing sectors in history. The quality of devices increased at an incredible pace. Platforms like HTML, iOS, and Android offered developers the easiest possible APIs. Placing a button or moving from one screen to another became child’s play. This ease officially encouraged fast delivery.

As a result, a lot of products emerged. But they were all programs; they were not systems. Remember that graphic I love so much from The Mythical Man-Month: everything starts with a simple program like the one in the top-left quadrant, a plain program with no tests, no code convention, no documentation, no modularization. To move that program to the “programming systems product” in the bottom-right, you need both productization (tests, documentation) and systematization (integration); and that means roughly nine times the effort. Frontend stayed stuck for a long time in that top-left quadrant, at the “program” stage. The work that came out did the job, made money, entered people’s lives; but that speed left no opportunity for the foundation that would turn programs into systems to form.

The visibility trap

In frontend, success is visible. If the screen works, if something happens when you press the button, if the demo flows, the work looks “finished”. But that apparent completeness also flawlessly hides the technical debt underneath it. A button that works in the demo also hides a test that doesn’t exist.

While in backend the error hits the engineer in the face and forces discipline, in frontend this visible success did the exact opposite; it made discipline look unnecessary. “It already works, why would I write a test?” This sentence quietly took root in the minds of a generation of engineers.

And worse, this culture was fed from above too. After a certain point, even writing a simple unit test came to be questioned by higher-ups. “You’re spending time on this?” “The screen already shows up, let’s move on.” Yet a foundation never formed even around the requirements right in front of us, like snapshot tests.

A culture that rewards the wrong thing

Think about it: one of two engineers gets a screen “working” in one day and makes it in time for the demo; the other delivers the same screen in two days, testing it, thinking through its edge cases, taking its snapshots. On demo day they both look the same. In fact the fast one looks more agile, more of a “closer”. The effort the slow one invested is invisible, because those errors never happen. It is hard to appreciate something invisible.

In backend this equation works in reverse: there, the wound opened by the engineer who rushes blows up sooner or later, usually in front of everyone. That is, the system proves the careful one right over time. In frontend, the wound opens quietly on the user’s device, somewhere you cannot see. Because the feedback loop never closes, the lesson is never learned either. This is not the engineers’ laziness; it is the result of the wrong signal the environment gives them. If you put the same people inside a backend culture, they would most likely show the same discipline. The issue is not talent, but the environment one is born into.

The real reason the loop never closes is exactly here: most of the time we can’t even see the error. Observability, just like tests, stayed in the background for frontend people for a long time; and it largely still does. Today there is no shared, settled standard for logging; most teams couldn’t get past crash detection. On the backend side you can trace step by step where a request passed through, how long it took, exactly where it blew up; but in frontend, what happens on the user’s device is most of the time a pitch-black box. A shared culture that would answer the question “what exactly did the user experience, at which step did they struggle, where did they give up?” never developed.

The “mobile is simpler” misconception

Now I come to my favorite part of this, because it is the exact opposite of most people’s intuition.

What I described above may give the impression that mobile is technically “shallow”. The truth is the exact opposite. In terms of technical range, mobile is not below other platforms; on many axes it is above them. Think for a moment about the things a mobile engineer has to keep in balance at the same time: security, limited memory and CPU, heat and battery life, bad network and offline-first scenarios, detailed device APIs (camera, location, sensors), push notifications, deep linking, the OS sandbox and app lifecycle, UI constraints and different resolutions, backward compatibility, accessibility, localization, and perhaps the most ruthless of all, the absence of a hotfix.

Looking at this list, an ironic picture emerges: the platform that needs a foundation the most became the platform that found the least opportunity to build one.

So where does this leave us?

But I don’t want to end the picture on a pessimistic note, because I don’t believe in it. That foundation is forming right now: unit tests, snapshot tests, design systems, modularization, localization, accessibility… Mobile and frontend are leaving their adolescence behind, slowly but surely. And I think the real thing that will change this equation quickly will be AI. Whatever has been postponed for years can now be set up very cheaply and very quickly with AI. In other words, that “unquestioned foundation” that backend had to settle over half a century out of necessity, frontend is now getting into a position to build in a much shorter time.