Most Software developers develop for their own devices this is a mistake. When developing a product for an emerging market-and I've been doing this for years in countries like Nigeria-millions of users are using Android devices with only 2-4 GB of RAM, outdated processors, unreliable memory and connections, and batteries that were dead before the App was installed. Yet many teams continue to develop as if every user had the latest flagship device.
The result is: an App that feels fast during development becomes a source of Frustration in production users jump off, ratings collapse and growth stagnates Developers blame infrastructure, product teams blame user engagement, and no one wants to see the real Problem: The Software wasn't developed for the Hardware people actually use.
This is not just an optimization task; It affects the entire design philosophy. Often it is assumed that underperforming devices only affect Rendering Performance, but the reality is different. In environments with limited memory and CPU power, every level is affected from:
- startup time
- memory management
- networking,
- storage,
- background processing
- battery consumption
- crash frequency
- ultimately user retention.
There were Apps that took up over 300MB of memory just by opening the home screen on a flagship device, but what about devices with less RAM? Android's "Low Memory Killer" automatically intervenes and is built into the architecture. The App is forced to quit, users are plagued by unexpected restarts, and usage frequency drops. In such cases, the development team looks for an "unknown bug in the production environment", but the cause is quite simple: the App's system requirements simply exceeded the device's limits.
My experience with a biometric identity platform for over 100 million citizens gave me this idea early on in building a system of this magnitude, you can't assume that users will have powerful devices, people who use government identity services, live in rural areas, use shared devices, or access them through unreliable mobile data connections. If the Software fails, it's not just a bug report-it causes citizens to be cut off from vital services.
Most Teams don't, but I strongly advocate: Create a performance budget parallel to your Feature Roadmap. Set concrete goals-Cold starts under 2 seconds, 16 milliseconds per Frame, As little network load as possible and predictable memory usage. Without these limits, performance becomes subjective and willing to compromise. Once the limit is drawn, it becomes a technical requirement, and performance losses are treated as severely as Feature failures. If a new Feature increases memory usage by 50MB, this should be taken as seriously as a production outage in network engineering.
Often the focus is on Backend latency, but the real Problem is network quality. Many users switch between 3G, 4G, and WiFi, use expensive data plans where every Megabyte counts, and connections drop without warning. A Backend response time of 100ms is useless when connecting takes 3 seconds.
The most effective optimization is not to send requests in the first place. Caching is essential-for static settings, user settings, frequently accessed content and reference datasets. Data that does not change frequently, users should not have to pay network penalties every time they open the App. Multiple requests that are inevitable, should be aggregated. Many Apps make five separate API calls at launch-user data, settings, notifications, Feature Flags, dashboard and then wonder about the slowness. Five fast requests can lead to a slow user experience.
Progressive loading is also important: users should only see the information they need immediately, the Rest later.
Storage is an area where teams are most likely to be surprised. Problems don't occur suddenly, but creepy Apps become slower over time. Navigation becomes inconsistent. Crashes are hard to reproduce. Developers eventually look for symptoms. Common causes are;
Huge images: Teams spend weeks on it, optimizing API response times while image files take up more memory than a single screen.
Excessive state management that keeps everything in memory unnecessarily, and large amounts of JSON data that burdens not only the network layer, but also parsing, memory management, object creation, and garbage collection.
A 50 % reduction in the amount of data often has a bigger impact on Performance than any change to UI.
It took a while to fully understand this: Design should be based on interruptions, not continuity on high performing devices. Developers must assume that processing will finish on low performing devices. Process termination, power saving limits, network interruptions, memory shortages, some of these issues can occur simultaneously in a single user session.
This has become a reality, When we developed the eCitizen platform: If citizens lose connection in the middle of the identity verification process, a blank screen or session loss is unacceptable. Errors should be the rule, not the exception. This means proactively saving state, supporting Offline Workflows where possible, making operations idempotent, and developing synchronization that allows for a clean recovery once the Situation improves.
Animations deserve special mention. They can be an underrated but significant obstacle. Movements that run smoothly on development machines may stutter on older Hardware. Before you adopt animations from your design system, ask yourself if they will really help you with your work. If not, remove them. Users value responsiveness more than decorative motions. Then test them on real devices. Sounds self-evident, but hardly anyone gets it right. MacBooks are not suitable as a reference. Even High-End Android devices are unsuitable. Emulators are even worse. If you value scalability, consider devices with little memory, older versions of Android, slow internet connections and limited space. Performance issues are only visible in real-world conditions.
In other words, teams that only test on the latest Hardware, are testing basically a different product than the one users are using. Performance improvements are often dismissed as "technical Debugging" and seen as something to be fixed only after delivery. However, I see it as a market expansion.
In many parts of the world, simple Android devices are widespread and Standard. Teams that consider these limitations as primary factors, Can develop products that reach significantly more people than competitors that optimize exclusively for High-End Hardware. Good developers don't program for ideal environments, but for reality: slow Internet, limited memory, obsolete devices, and users who simply want a system that works. Whether in a European environment or a rural setting, developing for underperforming devices demands a cleaner architecture, clearer trade-offs, and more deliberate decision-making at every level. Almost invariably, software built under these constraints is better for all users.
