a well designed responsive website<\/a> or a PWA (Progressive Web App). Far more cheaply and without the barrier of installing from a store.<\/p>\n\n\n\nA native app only starts to gain an advantage when you need deep access to the capabilities of the device. We are talking about smooth work with the camera and real-time code scanning, reliable push notifications, a full offline mode with a local database, background geolocation, NFC contactless payments, integration with sensors or advanced Bluetooth handling. If none of those things is at the heart of your idea, a native app is like buying a truck to carry a single folder of documents.<\/p>\n\n\n\n
The line is not sharp, though, because web technologies are catching up with native ones. A modern PWA can send push notifications, work offline thanks to Service Workers, install an icon on the home screen and use the camera. The difference lies in the details: push notifications in a PWA on iOS were limited for a long time, access to some APIs is incomplete, and the experience is not always as polished as in native code. That is why the decision should follow a specific scenario, not a general belief that “an app is better”.<\/p>\n\n\n\n
A typical mistake we see constantly is building an app “because the competition has one”. That reasoning has two flaws. First, you do not know whether the competitor’s app works at all – it may be sitting in the store with three downloads and one star, generating nothing but maintenance costs. Second, copying someone else’s technology decision without knowing its context is a recipe for repeating their mistake with your own money.<\/p>\n\n\n\n
Tip:<\/strong> Before you decide on an app, describe one specific moment in the user’s life when they reach for their phone to use your solution. If that moment can be served just as conveniently in a browser, you probably do not need a native app. At least not for the start.<\/p>\n\n\n\nTo make this distinction clearer, here are the situations in which a native app genuinely beats a responsive website and a PWA:<\/p>\n\n\n\n
\n- Offline work with large volumes of data<\/strong> – field service technicians, warehouse staff or couriers operating in places with no signal, who have to save data locally and synchronize it later.<\/li>\n
- Heavy use of the camera and sensors<\/strong> – scanning documents, object recognition, accelerometer measurements, handling barcodes at a rate of dozens per minute.<\/li>\n
- Push notifications as the core of the product<\/strong> – apps in which an immediate, reliable notification determines the value of the whole service, for example in logistics or alerting.<\/li>\n
- NFC payments and wallet integration<\/strong> – payment and loyalty solutions that require contactless contact with a terminal.<\/li>\n
- Background geolocation<\/strong> – route tracking, automatic presence reporting, navigation that has to keep working with the screen off.<\/li>\n<\/ul>\n\n\n\n
If your project does not fall into any of those five baskets, it does not mean you have to give up on mobility. It only means it is worth starting with a cheap, fast validation of the need – a responsive site or a PWA – and watching how users actually use the solution. Data from real usage will tell you more about whether an app makes sense than the best presentation at a board meeting.<\/p>\n\n\n\n
<\/span>Sign 2: Nobody counted the cost of maintenance, only the cost of the rollout<\/span><\/h2>\n\n\n\nThe second sign lights up when the only question asked during the budget conversation is “how much does it cost to build the app”. That is a question about the rollout cost, that is, about a one-off purchase. And a mobile app is, in cost terms, a subscription product – you pay for it continuously throughout its entire life. Leaving maintenance out of the calculation is one of the most common reasons why seemingly successful mobile projects end in disappointment and abandonment.<\/p>\n\n\n\n
Let us start with the fundamental fact. A native app for two platforms means two separate codebases, written in different languages and with different tools. iOS is the world of Swift and Xcode, Android is Kotlin and Android Studio. Even if you choose a cross-platform technology that reduces this duality, you are still left with two builds, two publication processes and two sets of platform-specific problems. Every change tends to be work done twice.<\/p>\n\n\n\n
On top of that come costs that clients usually do not consider at all during planning. An Apple developer account is an annual fee, a Google Play account is a one-off fee, but both platforms regularly change their technical requirements. Apple can force an update of the minimum SDK version, so an app that worked flawlessly suddenly stops being accepted in the store until you update it. Google does exactly the same, imposing new target system version requirements under threat of removal from Google Play.<\/p>\n\n\n\n
Here is a realistic list of the hidden costs you have to add to maintaining a mobile app over a few years:<\/p>\n\n\n\n
\n- Accounts and certificates<\/strong> – annual developer fees, renewing signing certificates, managing keys and provisioning profiles.<\/li>\n
- Forced platform updates<\/strong> – adapting the code to new versions of iOS and Android, which come out every year and can switch off old APIs.<\/li>\n
- Library and dependency updates<\/strong> – patching security vulnerabilities in third-party components, of which a typical app uses dozens.<\/li>\n
- Store reviews and policies<\/strong> – time spent going through the review process, reacting to rejections, adapting to the changing rules of the App Store and Google Play.<\/li>\n
- Support for many system versions and devices<\/strong> – testing on different phone models, screen resolutions and system versions used by your users.<\/li>\n
- Monitoring and incident handling<\/strong> – error tracking tools, response time to reports, shipping fixes.<\/li>\n<\/ol>\n\n\n\n
None of these items is theory. Each is a monthly or annual expense that does not disappear after launch. An app that goes a year without updates starts to fall apart: it stops working on new phones, it disappears from the store or it opens up security holes. A digital product that is not maintained does not stand still. It moves backwards, because the technology around it moves forward without it.<\/p>\n\n\n\n
Tip:<\/strong> Before you calculate the rollout budget, estimate the maintenance cost over two to three years and treat it as a full part of the decision. In our experience the annual maintenance cost of a well built app is often a significant fraction of the cost of building it. If that number frightens you, it is a sign that the project may be out of proportion to the need.<\/p>\n\n\n\nAn honest contractor will present these numbers up front, even if they reduce the chance of signing a contract. At Web Systems we would rather lose an order for a misguided app than build something that gets abandoned after a year because the client did not anticipate the maintenance costs. An abandoned project is not only the client’s money lost. It is also our reputation, and we have been building that since 2006 for too long to risk it for one-off revenue.<\/p>\n\n\n\n
<\/span>Sign 3: There is no backend, no integrations and no “single source of truth” about the data<\/span><\/h2>\n\n\n\nThe third sign is the most technical, but also the most dangerous financially. It appears when the entire conversation about the app revolves around the look of the screens, the color of the buttons and transition animations, and nobody asks where the app will get its data from and where it will save it. Because a mobile app is above all a presentation layer – what the user sees. Without a solid backend, a database and integrations with the company’s systems, it is an empty, pretty shell.<\/p>\n\n\n\n
Imagine an app for a trading company that is supposed to show stock levels, take orders and report shipment status. Each of those functions requires a connection to something on the server side: a warehouse system, an ERP, a payment gateway, a logistics module. The app itself “knows” nothing – it only displays what the API feeds it and sends back what the user enters. If those server-side systems are not ready, tidied up and exposed through sensible interfaces, building an expensive mobile frontend is putting up the roof before the foundations exist.<\/p>\n\n\n\n
It is worth reaching here for a principle that has been a foundation of good application architecture for years, including in the official recommendations for Android. As the Android app architecture documentation puts it:<\/p>\n\n\n\n
It’s a common mistake to write all your code in an Activity. The primary role of an Activity is to host your app’s UI. This ephemeral nature makes them unsuitable for holding application data or state.<\/blockquote>\n\n\n\nIn other words: you must not keep data and business logic in the interface layer. The data and the rules that determine how your company operates have to live in the data layer – in the backend and the database – and the app should only query and present that layer. This separation of responsibilities (layer separation) is not an academic invention. It is the condition for a product that can be maintained and developed without being rewritten from scratch with every change.<\/p>\n\n\n\n
Closely related is the notion of a single source of truth about the data. The same architecture documentation states it plainly:<\/p>\n\n\n\n
When a new data type is defined in your app, assign a single source of truth. The SSOT is the owner of that data, and only the SSOT can modify or mutate it. This pattern centralizes all changes to a particular type of data in one place and protects the data so that other types cannot tamper with it.<\/blockquote>\n\n\n\nIn practice this means that stock levels, product prices or order status have one authoritative place where they are stored and changed – usually a database on the server side. The mobile app, the website, the service panel and the invoicing system all read the same data from the same source. When a company lacks that order, every channel has its own truth, the data drifts apart, and the mobile app becomes yet another place where contradictory information shows up.<\/p>\n\n\n\n
The most expensive mistake we observe is building an elaborate mobile frontend before the data and integrations on the server side have been sorted out. The client pays for beautiful screens, and then it turns out there is no API to feed them, that the data in the ERP is in an unpredictable state, and that integrating the warehouse requires rewriting half the system. The frontend waits, costs grow, and the launch slips by quarters.<\/p>\n\n\n\n
That is why at Web Systems, when we see this sign, we propose reversing the order of work. First we clean up the backend, design the API, establish a single source of truth and the integrations with existing systems. Only then do we build the mobile layer. It often turns out along the way that once the backend and the API exist, value can be delivered quickly and cheaply through a web app or a PWA, and the native app can wait until it is genuinely justified.<\/p>\n\n\n\n
<\/span>Sign 4: The user forecast does not justify two platforms at once<\/span><\/h2>\n\n\n\nThe fourth sign concerns scale. It lights up when we are planning a native app for iOS and Android for an audience that is small, known and countable. The classic example is an internal tool for thirty field workers, or an app for a closed group of business partners. Building and maintaining two separate native apps for such a narrow group is rarely defensible economically.<\/p>\n\n\n\n
The logic is simple. The cost of building and maintaining a native app is largely fixed, regardless of the number of users. Two codebases, two publication processes and two sets of tests cost about the same whether thirty people use them or three hundred thousand. The difference is that at large scale that fixed cost spreads across a huge user base and works out at pennies per person, while at small scale it weighs on the budget like a stone. That is why a forecast of user numbers should be one of the first inputs into the architectural decision.<\/p>\n\n\n\n
Fortunately, two native apps are not the only road to mobility. The spectrum of options is wide, and it is worth knowing it before you default to the most expensive one:<\/p>\n\n\n\n
\n- One cross-platform codebase<\/strong> – technologies such as Flutter or React Native let you write the app once and ship it on iOS and Android from a single codebase. This does not remove the differences between platforms entirely, but it significantly reduces the cost of building and maintaining, which at medium scale is often a sensible compromise.<\/li>\n
- Progressive Web App<\/strong> – an app that runs in the browser, can be installed on the home screen and uses part of the device’s capabilities. No store installation and one codebase for all platforms make it a very cheap entry into mobility.<\/li>\n
- A web app instead of a store app<\/strong> – for internal tools the best choice is often simply a responsive web app available at a URL, without having to go through the App Store and Google Play with their reviews and fees.<\/li>\n<\/ul>\n\n\n\n
An internal tool for thirty employees is a textbook case in which a web app or a PWA beats a native app hands down. Employees log in through the browser, an update is immediate for everyone (you do not wait for each person to update the app from the store), there is no review process, and the maintenance cost is a fraction of what two native apps would consume. Access to the camera or notifications, if needed, can often be handled within a PWA.<\/p>\n\n\n\n
Tip:<\/strong> Build a simple decision table with three columns – number of users, device types, usage scenarios – and only then choose the technology. An architectural decision should follow hard data, not the fashion for having “an app” or the wish to own an icon in the store.<\/p>\n\n\n\nIt is also worth remembering that the choice of technology is not a decision forever. A sensible path for a company with uncertain scale is to start with a PWA or a cross-platform app, gather data on real usage, and then, if the numbers justify it, invest in a native solution where it will genuinely deliver an advantage. This approach of gradual escalation protects the budget and lets you make each successive decision on the basis of evidence rather than assumptions.<\/p>\n\n\n\n
At Web Systems we work with all of these technologies, so we have no interest in pushing any one of them. Our job is to match the tool to the problem, not the problem to a favorite tool. When the user forecast does not justify two platforms at once, we say so plainly and show cheaper routes to the same business goal.<\/p>\n\n\n\n
<\/span>Sign 5: Nobody planned security, scaling and what happens after launch<\/span><\/h2>\n\n\n\nThe fifth sign is at once the most serious and the most frequently ignored. It lights up when not a single sentence in the conversation about the project touches on security, scaling and what will happen to the app after launch. All the energy goes into the release date, as if the launch were the finish line rather than the start. And for a digital product, launch is only the beginning of the longest and most expensive phase of its life.<\/p>\n\n\n\n
Security is the area where the lack of a plan takes its most painful revenge. An app that processes customer data has to have well thought out authentication, secure storage and transmission of data, protection against typical attacks and compliance with GDPR. These are not add-ons you glue on at the end. They are a foundation that has to be designed from the start. A mobile app runs on someone else’s device, outside the company’s control, which raises additional requirements: locally stored data has to be protected, communication with the server encrypted, and keys and secrets should never end up in the app’s code in an unprotected form.<\/p>\n\n\n\n
On top of that come security updates, which are a continuous process. The libraries an app uses regularly disclose vulnerabilities, and someone has to track and patch them. If nobody owns that process, the app becomes leakier month by month, until it finally poses a real risk to the company and its customers. GDPR adds legal duties on top: the right to erasure, consent, a record of processing activities. All of that has to be reflected in the architecture, not only in the terms and conditions.<\/p>\n\n\n\n
Scaling and maintenance are the second area that routinely lands in the drawer labelled “we will deal with it later”. And that “later” is, in our experience, the most common cause of abandoned mobile projects. A backend designed for a hundred users falls over at ten thousand. Code written in a hurry, without tests and documentation, becomes impossible to develop once the original team leaves. No development plan means that every new feature is a fight with the technical debt accumulated since launch.<\/p>\n\n\n\n
Tip:<\/strong> If you cannot answer the question of who will develop and maintain this app a year from now, that is a very strong sign that there is no point in building it yet. A digital product without an owner and without a maintenance plan is not an investment, it is a problem postponed.<\/p>\n\n\n\nA plan for “what happens after launch” should cover several concrete elements: who monitors errors and the response time to incidents, how often updates ship, who is responsible for compatibility with new system versions, what the development budget looks like in the coming years, and how we measure whether the app actually meets its business goals. Without those answers, a launch is a leap in the dark rather than a controlled product start.<\/p>\n\n\n\n
This is exactly where the difference shows between a contractor who only wants to sell a project and a technology partner who thinks about the product life cycle. At Web Systems we treat security, scalability and the maintenance plan as part of the conversation from the first meeting, not as a topic for “someday”. We would rather design a smaller but solid and maintainable product than an elaborate app that dazzles at launch and becomes an abandoned burden a year later. Security and scaling are not a cost you can skip. They are a cost you pay either up front in the project, or many times over in the form of an incident and lost customer trust.<\/p>\n\n\n\n