A chain of three bakeries wanted a mobile app. The idea was for customers to order ahead and collect without queuing. We ran one exercise before starting: we asked how many current customers would install an app just for that. The answer, collected at the counter over two weeks, was "around 15 people out of more than a thousand".
We replaced the app with a fast mobile ordering page integrated into the existing site, plus an SMS notification when the order was ready. The result was 200 orders a month by the third month. The app would have cost many times more and reached fewer people, because it requires installation.
That does not mean mobile apps are pointless. It means the question "do we need an app" is almost always framed wrongly. The right question is "what behaviour do we want to change, and what is the cheapest way to achieve it".
When a mobile app makes sense
An app has an advantage over a website in a few specific situations. All of them revolve around one thing: the customer returns often and has a reason to keep the icon on their screen.
High frequency. If a customer interacts with you at least weekly, the installation pays off. Food delivery, gyms, banking, transport. If the interaction happens once a quarter, the app gets deleted.
Offline capability. Warehouse software, courier apps, field technician tools. A browser does not cut it on a weak connection.
Hardware access. Camera for barcode scanning, GPS with background tracking, NFC, biometrics. Some of this already works in a browser, but not all of it and not equally reliably.
Notifications that must arrive. Push notifications have a substantially higher open rate than email. If the business model depends on a timely message, that is a serious argument.
When a mobile site is the better choice
If you sell products bought a few times a year, if your main channel is advertising to new people, or if you are still testing the idea, a well built mobile site does the same job at a fraction of the cost and without the installation barrier. Someone who sees an ad and taps lands directly on the page. That same person, faced with "download the app", mostly walks away.
Types of mobile apps and how they differ
| Type | Technology | Build speed | Hardware access | Maintenance |
|---|---|---|---|---|
| Native | Swift for iOS, Kotlin for Android | Slow, two projects | Full | Two codebases |
| Cross platform | React Native, Flutter | Medium, one codebase | Nearly full | One base plus platform quirks |
| Progressive Web App | Web technologies | Fast | Limited | Same as a website |
| Hybrid wrapper | Web code in a container | Very fast | Limited | Simple but compromised |
The cross platform approach covers the needs of most companies. It produces one app for both platforms, looks and behaves natively to the user, and costs considerably less than two separate projects.
Progressive Web Apps deserve separate attention. A PWA is a site that can be installed on the home screen, works offline to a degree and supports notifications on Android. It needs no app store approval and updates like an ordinary website. For a large share of cases where a company starts thinking about an app, a PWA is the more sensible first step.
What app development involves
Analysis and scope
The first phase is not programming but cutting. The wish list is always three times longer than what is needed to launch. The job is to keep only what the app cannot exist without and to ship quickly.
A practical rule: if a feature is not part of the core action that makes someone open the app, it goes into version two.
Interface design
Mobile interfaces have their own rules. Buttons must be reachable with a thumb, text must be readable in sunlight, and every action should take as few taps as possible. A design built for desktop and then shrunk is obvious immediately and hurts usability.
Development and integrations
An app rarely lives alone. It connects to inventory, accounting, a CRM or a payment provider. Those integrations usually take longer than the interface itself and are where timelines stretch.
Publishing to the stores
The App Store and Google Play both have review rules. Rejection over a missing privacy policy, unclear permission descriptions or insufficient functionality is common on first submission. Plan a two week buffer.
Maintenance after launch
This is the most underestimated cost. Apple and Google update their operating systems every year and occasionally break compatibility. An unmaintained app stops working correctly within roughly a year to eighteen months. A maintenance budget is not optional, it is part of the decision to have an app at all.
Timelines and resources
A simple app with a catalogue, an account and ordering takes two to four months with a cross platform approach. An app with payments, notifications, user roles and inventory integration reaches six months and beyond.
Costs depend entirely on scope, which is why any serious estimate follows a written feature list rather than a phone call. Beyond development, plan for annual store account fees, server infrastructure and hosting for the admin side.
The hidden costs nobody mentions
Install marketing. Apps are not discovered on their own. Every install costs money, usually through paid advertising, and that cost keeps rising.
Supporting two platforms with different user behaviour. Android users run a wider range of devices and screen sizes, which increases testing effort.
Content updates. If the app carries prices and products, someone has to keep them in sync with the online store.
Common mistakes
An app that copies the website. If it does nothing more than the site does, nobody has a reason to install it.
Mandatory registration on the first screen. The fastest way to lose half your new users. Let people browse before signing up.
No analytics. An app without screen and event tracking is a black box. You cannot see where people drop off.
An oversized first version. Trying to ship everything at once produces a long timeline, an exhausted budget and a product still untested with real users.
Ignoring store reviews. Ratings directly affect visibility and installs. Replying to a negative review often gets the rating revised.
Frequently asked questions
Native or cross platform
For most business apps, a cross platform build with React Native or Flutter delivers practically the same quality at significantly lower cost with a single codebase. Native development stays justified for graphics heavy work, complex camera handling or maximum performance requirements.
Can a Progressive Web App replace an app
In many cases yes. A PWA works offline to a degree, can be added to the home screen and supports notifications on Android. The limitations are on iOS, where support is weaker, and around deep hardware access. As a first step to validate the idea, a PWA is the logical choice.
How long does development take
Two to four months for an app with a core feature set, and six months upward once payments, roles and integrations with inventory or accounting systems are involved. Much of that time goes into integrations rather than the interface.
How will people find my app
Not on their own. Store search mostly works for brands people already know. Installs come from your advertising, your website, the counter in your shop, your email list and a QR code on the packaging. Plan the install channel before development starts.
Do I need an app if I have a good mobile site
If customers come a few times a year and the main task is a purchase, most likely not. If the interaction is weekly, if you run a loyalty programme, or if the business depends on timely notifications, an app starts to make sense.
How to decide
Try a simple exercise. Describe in one sentence the action someone will perform in the app at least once a week. If that sentence is hard to write, the app is probably not the answer, and a fast mobile site with a clear path to the order will do the job.
If you want help judging which fits your case and what scope is realistic, get in touch. We review the business model, propose the option with the best effort to result ratio, and send an individual quote within 24 hours.
