This year has pushed a great many Egyptian businesses to take mobile seriously, and a striking number of them have arrived at the same conclusion: we need an app. Sometimes that is correct. More often it is an expensive way to solve a problem a fast, well built mobile site would solve in a third of the time for a fraction of the money, and without the permanent obligation attached.
The build is not the expensive part
Two codebases are expensive, or one cross platform framework and the compromises that come with it. So are store review cycles, release management, crash reporting, support for the older Android versions your customers are still using, and an update treadmill that never stops. An app is a product with a permanent team attached, not a project with a delivery date.
Distribution is harder still. Somebody has to hear about the app, decide it is worth the storage, wait for it to download over data they are paying for, and then remember it exists a week later. On a phone with 32 or 64 gigabytes already full of photos and WhatsApp media, storage is genuinely scarce, and your app is competing with things people open every day. A first time buyer who has never dealt with your business will not install anything. They will open a browser, and if what they find is slow they will open a competitor instead.
Mobile app or mobile web: two tests, frequency and capability
Frequency is the first test. If a customer has a real reason to come back weekly or more, an app starts to pay for itself, because the install cost is spread across dozens of sessions and notifications become a channel rather than an irritation. Food ordering, transport, banking, fitness, pharmacy refills and loyalty heavy retail all clear that bar. Anything bought once or twice a year does not. Nobody installs an app to buy an apartment.
Capability is the second. If you need the camera, background location for a delivery fleet, offline operation where coverage is poor, or hardware such as a barcode scanner, the browser will fight you the whole way. This is why internal tools are frequently a stronger app case than customer facing ones. A delivery crew, a field sales team or somebody counting stock uses the thing every working day, which is precisely the frequency that justifies a build, and the return is measured in hours saved rather than in downloads.
The sequence that usually works
Build the mobile site first and make it genuinely good: fast on a mid range phone, usable with one thumb, with an inquiry or checkout flow that does not assume a keyboard and a desk. Then add the reasons to come back, whether that is an account with order history, a loyalty scheme, or simply being reliable enough that people stop shopping around.
In the middle ground, a progressive web app covers a good deal of the distance. It can be added to the home screen without a store visit, works offline for cached content, and costs far less to maintain than two native codebases. Pair it with WhatsApp as your retention channel, since your customers already live there and have opted in by messaging you, and you have much of the value of an app without the install barrier.
Then, once repeat behavior shows up in the data rather than in a business plan, build the app for the customers you already have. That project is easier to justify, easier to scope and far easier to get installed. Working out which side of the line a business sits on is the first thing we do with website and app development clients, and the same test decides whether an internal mobile app is worth building for your own team.
