Companies lose customers because they have no mobile channel. And most of the time they do not even notice when it starts. There is no alarm – conversion simply drops, carts get abandoned, and sales reps call in from the field because they cannot check stock levels. Since 2006, we at Web Systems have been helping business owners tell a real need apart from a passing fad for “an app”. In this article we will walk through the specific signals that say “time for an app”, show the differences between technologies and explain how not to burn your budget on the first rollout. We will also cover integrations, security and what happens after you push the app to the stores. Because that is where the fun really begins.
Spis treści
Business signals – how to know it is time for a mobile app
The simplest test? Open Google Analytics. If more than 60% of traffic comes from phones and the bounce rate on mobile is clearly higher than on desktop, a responsive website is no longer keeping up. Users want speed, smoothness and one-thumb operation. And a mobile browser has its limits. Push notifications, camera, GPS, offline mode – you cannot get past that without a dedicated application.
The second signal comes from inside the company. Service technicians, sales reps, drivers, warehouse staff – these people work outside the office. And what do they do? They email orders, retype data by hand, call head office for every piece of information. That creates errors and delays. I have seen it dozens of times. A mobile app integrated with an ERP or CRM can cut response time in half. No exaggeration.
And then there is competitive pressure. When companies in your industry give customers convenient apps for ordering, tracking parcels or booking appointments, you simply lose out without a solution like that. Customers compare experiences. And they choose convenience.
- Mobile traffic on the site exceeds 60%, and conversion on smartphones is twice as low as on desktop
- Field staff waste time on manual reporting and lack real-time access to data
- Competitors have launched their own apps and are taking over users
- Customers ask for notifications, a loyalty program or a fast way to place repeat orders
- The responsive website does not support key scenarios – for example code scanning, digital signatures or offline work
- Customer retention is falling even though your offer remains competitive
Tip #1: Before you rush into building an app, look into Google Analytics or Matomo. But do not only check the mobile share. Look at the conversion paths on phones. If users drop off at a specific step – at the form, at the payment – that is a signal they need a better interface. But not necessarily a full native app right away. Sometimes a better mobile version of the website is enough.
PWA, hybrid or native – which path to choose and why it is not obvious
This is where it gets tricky. The choice of technology is a decision that follows the project for years. A Progressive Web App runs in the browser, installs on the home screen, supports push and basic offline use. The main advantage? Low entry cost and no store publishing. It works well for product catalogs, booking systems and simple internal tools – anywhere you do not need to dig deep into the phone hardware.
Hybrids – React Native or Flutter – let you keep a single codebase for Android and iOS at once. You get access to native device features and pay far less than for double development. Honestly? At Web Systems we use this approach most often, especially for first product versions where time-to-market matters. A hybrid handles most business scenarios just fine – e-commerce, logistics, field service apps.
“App architecture is the foundation of high quality Android software. A well defined architecture makes it possible to build scalable, maintainable solutions able to adapt to a constantly expanding device ecosystem – from phones through tablets and foldables to car displays.”
Native apps in Kotlin (Android) and Swift (iOS) are top shelf. Maximum performance, full platform access. But. You are effectively building two separate products, so the budget nearly doubles. When does that make sense? Games, heavy graphics, augmented reality, apps that have to squeeze every minute out of the battery. For most B2B and e-commerce projects it is overkill at the start.
Tip #2: Start with an MVP in a hybrid technology – Flutter or React Native. You will validate the idea on the market in 3-4 months, gather feedback and only then, based on hard data, decide whether to migrate to native. I have seen too many projects where someone picked Swift because they read an article on Medium. Do not do that. Analyze your own requirements.
From idea to MVP – how to plan the first version without burning the budget
The most expensive mistake I see with clients? Trying to build a complete product on the first attempt. Twenty screens, three user roles, integration with five systems, an admin panel. That is not an MVP. That is a full-scale system whose development drags on for a year and blows up any budget. A Minimum Viable Product solves one problem for one group of users. Everything else goes to the roadmap. Full stop.
The discovery and prototyping phase is the stage everyone wants to skip and then regrets it. It produces user personas, a flow map, screen wireframes and a technical specification. With us this stage takes 2-4 weeks and costs a fraction of the whole project. But it lets you catch misunderstandings before they turn into expensive fixes in the code. A clickable prototype gives you the chance to test the concept with real users before the first line is written.
“In-depth industry research, best practice analysis, trend modeling and a quantitative approach make it possible to develop innovative strategies that translate into stronger and more sustainable business results.”
And how much does it cost? Realistic ranges for a simple mobile app start at 40,000-60,000 PLN for a hybrid MVP. An extensive product with many integrations? 200,000-500,000 PLN and more. It depends on the number of screens, the complexity of the business logic, the integrations, the level of security and on whether you are building a backend from scratch or connecting to an existing API. Without a detailed specification no estimate will be reliable – and that is why the discovery phase is not optional.
Tip #3: Pick 3-5 features for the first version. Put the rest aside. Use a simple matrix – rate each feature for user value and implementation complexity. High value, low complexity? It goes into the MVP. The rest waits for the next iterations, which you will base on data from real usage rather than on guesswork.
Integrations, data and security – the technical foundations clients rarely think about
No mobile app works in a vacuum. It connects to an ERP for stock levels, pulls customer data from a CRM, talks to payment gateways, sends notifications through external services, syncs with the admin panel. And every such integration is a separate project – the API layer, error handling, a retry mechanism, a caching strategy. No integration planning at the start? That is one of the most common reasons budgets get exceeded. Reworking the architecture on the fly costs many times more than designing it carefully at the beginning.
Security in mobile is a story of its own. A phone can be lost, stolen, connected to a shady WiFi network in a cafe. Data encryption (at rest and in transit), multi-level authorization, secure token storage, GDPR compliance – that is the absolute minimum. With medical or financial data, industry regulations come on top. At Web Systems every mobile project goes through a security audit before release. No exceptions.
Data architecture should follow the single source of truth principle. Every type of data has one place where it is modified, and the remaining components only read it. A one-way data flow, from the source through the business logic to the UI, reduces synchronization errors and makes debugging easier. I have tested both approaches and I know it works in simple catalog apps as well as in complex systems with an offline mode.
And this brings us to offline-first. An app that dies without a connection is useless to a sales rep in the field, a technician in a basement or a driver in a dead zone. A local database, operation queuing, smart synchronization once the connection is back – that has to be designed from day one. You cannot just “add it in” later without rebuilding half the application. Seriously, you cannot.
Release, maintenance and growth – what happens after the rollout
Pushing an app to Google Play and the App Store is not a click-and-done job. Google requires a developer account, a signed application and passing automated verification. Apple? Oh, Apple is another league. Review can drag on from a few days to two weeks. Rejection over minor deviations from the Human Interface Guidelines? It happens regularly. Plan a time buffer, especially for the first release. On top of that come descriptions, screenshots, a privacy policy and graphics for both stores – that alone eats up several working days.
And now the most interesting part: maintenance. Clients almost always underestimate this stage. Android and iOS ship new versions every year and security patches every month. Every change in a system API can break something in your app. Add to that fixes reported by users, crash monitoring (Firebase Crashlytics is a must-have), performance analysis, battery optimization. Ignore it and your store ratings will fall. A low rating means fewer downloads, which means worse visibility. A downward spiral.
Growth after the rollout should be based on data. Behavior analytics (navigation paths, time on screens, where people drop off), in-app surveys, support ticket analysis – that is what decides roadmap priorities. Rolling out new features iteratively in two- or four-week sprints lets you react to the market without breaking what already works.
How much does maintenance cost? Realistically 15-25% of the annual development budget. For a simple app that is 2,000-5,000 PLN a month. An extensive system with integrations? 10,000-20,000 PLN. That amount covers backend hosting, monitoring, dependency updates, adapting to new system versions and ongoing fixes. Include it in the business plan from the start. It is a fixed operating cost, just like maintaining the rest of your IT infrastructure.
FAQ
How much does it cost to build a mobile app for a mid-sized company?
It depends on the scope, the technology and the number of integrations. A simple hybrid MVP (Flutter, React Native) with 5-8 screens and a basic backend costs 40,000-80,000 PLN. An extensive app with an admin panel, ERP and CRM integrations, offline mode and advanced authorization? 150,000-500,000 PLN. That is why the discovery phase matters so much – it lets you estimate the budget before you start spending. And remember the maintenance costs, roughly 15-25% of the project value per year. Many people forget about that.
Is it better to start with a mobile app or a responsive website?
In most cases, with the website. It is cheaper, easier to maintain and available without installing anything. But there comes a point when the website no longer keeps up: you need push, offline, access to the phone hardware, or you want to build deeper engagement through native UX. That is when an app makes sense. A PWA is a decent middle ground, combining the advantages of both approaches on a reasonable budget. But make the decision based on data about user behavior, not on what the competition is doing.
Summary
Building a mobile app should follow from hard data and real business problems. Not from the belief that “every company has to have an app”. Check your mobile traffic, analyze the processes that require access in the field, assess whether the competition is genuinely gaining from mobile. Only when the signals are unambiguous should you match the technology to the requirements, not to the trends.
The road to a successful rollout looks like this: verify the business signals with analytics, make a conscious choice between PWA, hybrid and native, define the MVP precisely during discovery, plan integrations and security from day one, and account for maintenance costs in the budget. Skip any of these steps and you will end up with delays, an overrun budget or a product nobody wants to use.
If you are considering building a mobile app, need an MVP, are integrating existing systems or want to modernize your current solution, let’s talk. At Web Systems we have spent almost two decades combining technical expertise with a practical approach to projects, helping companies make technology decisions that actually pay off.
