My Work · Journey · Technology · Building

From an Out-of-the-Box Idea… to No Box at All

The story of an Android app inspired by a PlayStation 1 cheat code, picked up by the press, bought by early supporters, and eventually overtaken by the technology built into phones themselves.

· Published: · 11 min read

A sequence of up and down arrows representing the app's button code

Where did all these people come from?

One ordinary day, I opened the analytics for my apps to check whether the new one had finally crossed ten downloads.

Instead, I found thousands of people using it at the same time.

How?

I had not run a campaign. I did not have an audience waiting for my next release. Even the friends who had downloaded the app could be counted on one hand.

So where had everyone come from?

The analytics dashboard had not updated the traffic sources yet. Almost by accident, I searched Google for the app’s name and found a headline repeated across several websites:

“Egyptian developer launches an unconventional way to lock Android phones.”

To explain how I ended up there, we need to go back a little.

It started in late 2013

A few friends and I were staying up late with a modest laptop and a collection of terrible wired controllers—the cheap ones that somehow made every loss feel like a hardware problem.

Someone suggested revisiting the PlayStation 1 era and finding out who could still compete with Eslam.

That last part may have been added by the person currently writing the story. 😅

While we were playing, I noticed that I could still remember old cheat codes almost perfectly. I remembered the button sequences for unlocking hidden national teams in the Japanese version of Winning Eleven. I remembered the fruit cheat in Crash Team Racing.

I did not even have to think about the sequence. My fingers already knew it, almost like muscle memory.

That was the moment the idea appeared.

The idea

Why not use the same interaction to protect a phone?

Instead of typing a PIN or drawing a visible pattern on the screen, the user could unlock the device through a private sequence of physical button presses: volume up, volume down, the home button that phones still had at the time, and sometimes a dedicated camera button.

I thought it could be faster and much less obvious to anyone watching over your shoulder.

A traditional PIN was often only four digits. With two, three, or four physical buttons, you could still create a large number of possible sequences without displaying the password on the screen.

At the time, smartphones were only beginning to spread widely in Egypt. Android 4 KitKat had recently arrived, and developers were building all kinds of launchers, interface customizations, lock screens, and app lockers based on PINs or Android’s familiar pattern grid.

I believed a different way to secure a phone could stand out.

The decision

I spent the rest of the evening playing with my friends, but my mind had moved somewhere else.

Could this actually work? Would it be practical? Was I even capable of building it?

My Android SDK knowledge was barely enough to create a new Activity—which, at that point, mostly meant producing an impressively empty screen.

My Java skills were nowhere near the level required to build a product people could trust. To make things worse, Java and I were not exactly enjoying a warm relationship. I was learning it mainly because being able to say “I am a programmer” sounded nice.

The idea took seconds.

The planning and implementation took considerably longer.

When I got home, I wrote the concept down in two lines and began trying to answer two much larger questions:

How do I turn this into something people can actually use? And how could it eventually become a real product rather than another abandoned experiment?

That was when I made the decision:

I had to learn.

The idea was simple. The implementation was not.

I started collecting every useful resource I could find about Android and Java.

I was not particularly good at structuring that process. I could not confidently set a timeline and stick to it, and the learning resources I knew about were limited compared with what is available today.

This is also where I need to thank the person who taught me the foundations after God: engineer Abdullah Eid.

He published high-quality Java and Android courses as an ongoing charity in memory of his parents, then quietly disappeared from the scene. Please remember him and his parents in your prayers.

What I learned from him was bigger than Java syntax or Android screens. I learned how to learn: how to read documentation, investigate unfamiliar APIs, and search for answers instead of waiting for a tutorial that matched my exact problem.

That was a turning point for me.

Before then, I could write code. But writing code and building a real product are not the same thing.

The learning phase took a while, but it did not feel wasted. I was not studying for the sake of collecting information. I had something I needed to build—something usable, reasonably secure, and trustworthy enough for a person to put between strangers and their private data.

Every time I learned one piece and tried to apply it, I discovered three more things I did not understand.

So I went back, learned again, and repeated the process.

A laptop screen showing source code and an Android emulator

The challenge

Eventually, I had to stop preparing and start building. I could not study forever, and there was nothing wrong with learning while moving.

I will spare non-technical readers the less exciting details, but the project quickly introduced me to questions I had not known existed:

  • How should the app behave across different Android versions?
  • How do you support devices from different manufacturers?
  • How can it remain available when needed without draining the battery or slowing the phone down?
  • How do you make users trust that the lock is difficult to bypass or shut down?

Those questions gave me an early look at how much I still did not know—and how software development never really reaches a point where learning is finished.

Like most ideas, the app looked extremely easy before I started implementing it.

Still, after months of experiments, mistakes, and study, I finally had a working first version.

It worked

After months of trying, I had built an Android app that solved a real problem and behaved roughly the way I had imagined:

  • A lock screen for the phone.
  • A separate lock screen for selected applications.
  • A secret sequence created with the phone’s physical buttons and chosen during setup.
  • A traditional backup PIN in case the user forgot the button sequence.
  • No root access required.

I sent the app to my friends for testing. Their reactions made me happier than finishing the implementation itself.

Had I actually become an Android developer now?

A promotional cover showing the app on a phone beside a set of keys

The app was ready. I was not.

After using the app for a while and sharing it with friends, an obvious question appeared:

Now what?

I had the idea. I had learned enough to build it. I had tested it with friends and published it on Google Play.

What came next?

That was when I discovered that building a product also includes preparing to distribute it.

I had made something useful, but nobody knew it existed. More importantly, nobody knew I existed either.

The obvious answer was to learn marketing, run campaigns, define the target audience, study acquisition channels, and figure out how to reach the right users.

But I was tired.

I had learned programming because I genuinely loved it. I did not believe the answer to every missing skill should be “learn that entire profession and do it yourself too.”

So I stopped and admitted something important:

I needed help.

I sent one email and carried on with my life

Unfortunately, my professional network at the time consisted of me—and, on a good day, also me.

I did not know people in the industry. I did not even personally know another programmer.

That was a serious mistake. You need to place yourself inside a community that shares your interests, especially when you are still learning how the industry works.

With no better plan, I made one uncalculated attempt that I did not expect to succeed.

I emailed a technology news agency I followed, explained the story, included the Google Play link, and closed the tab.

Then I forgot about it and returned to the much harder problem of marketing an app that had not yet reached eight users.

The disappointment was real, especially after months of work.

I developed a daily habit of checking the download statistics. Every few days, the number would increase by one—usually because I had personally sent the link to someone and asked them to download the app and leave a review, hoping it might help the store show it to more people.

Then the opening scene of this article happened.

The reward

By pure luck, the agency I had chosen was large and widely followed. Other websites picked up the story and republished it as though I had completed a national technology mission.

“Egyptian developer launches an unconventional way to lock Android phones.”

The headline appeared on technology websites and general news outlets alike.

Suddenly, it was no longer a small app shared between me and my friends. It was being discussed publicly, and the download numbers started moving quickly.

At first, I assumed the analytics were broken. That explanation felt far more realistic than the idea that the press had suddenly become interested in an app I had built alone.

Then emails began arriving.

Some people wanted to acquire the app. Others suggested that we build a startup around it. Well-known people posted about it on Facebook and celebrated the young Egyptian developer who had tried something different.

I was still trying to understand one thing:

Was this actually happening?

Success arrived faster than my experience

The attention was unexpected, and I was not personally prepared for it.

My thoughts became scattered, and one question took control of almost everything:

How do I turn this into money?

The simplest answer seemed obvious: make people pay for the app. 😅

I ignored most of the opportunities coming from people with more experience than I had—people who were ready to collaborate and potentially build something larger.

Instead, I decided to release a paid edition with a few extra features and use the free version to promote it.

Within a few weeks, the paid version was live.

To my surprise, a meaningful number of users bought it even though many of them did not truly need the additional features.

They were not only buying software. In many cases, they were supporting a young Egyptian developer who had made something unusual and thought a little outside the usual box.

Bad luck and no real plan

The app made some money, but I had no serious plan for what came next.

There was no expansion strategy and no alternative direction if the original value proposition changed.

That was the real problem.

A few months later, two developments were enough to undermine the project.

First: fingerprint sensors spread everywhere

Fingerprint authentication moved rapidly from something associated with science-fiction films and expensive flagship phones to a standard feature across almost every price category.

Even affordable phones began shipping with fingerprint sensors.

Excellent timing, as always. 😅

Second: Android changed underneath the app

Newer Android SDKs introduced stronger restrictions on applications that needed to remain active in the background.

Phone manufacturers also became increasingly aggressive about stopping background processes to save battery. Users often had to manually grant exceptions or additional permissions to keep the app working reliably.

That created a painful gap in the user experience.

The average user did not know that the operating system or device manufacturer had stopped the app. From their perspective, the developer had built something unreliable.

The app did not stop working. It stopped solving the problem.

The app did not fail in the traditional sense.

The problem it was designed to solve became less important and then almost disappeared.

Technically, the app could still work. But there was no longer a strong reason for it to exist when the phone could unlock instantly with a fingerprint.

The original purpose had vanished.

This was the moment when I needed an alternative strategy. I did not have one, and my lack of experience allowed the project to fade until I eventually stopped maintaining it and removed it from the store.

Was it really bad luck?

Not at all.

The app may be one of the most important projects in my journey.

Had those events not happened in the order God chose for them, I would not have gained the experience that shaped the work I do today.

The project taught me things I did not know I needed to learn—and, in some cases, things I did not even know existed.

I learned that an opportunity still requires experience if you do not want to waste it.

I learned that education is not a stage you complete. It is an ongoing state that should continue for as long as you are building, working, and living.

And I learned that the idea and the implementation matter, but timing, distribution, and knowing what to do after success may matter even more.

In the end:

The app disappeared, but its impact did not.