"We need an app" is a sentence we hear a lot. Sometimes it is right, and sometimes a fast website with a form would have solved the same problem at a tenth of the price. This guide is meant to help you know which side you are on, and if you are on the app side, how to build it without losing a year and a budget.
Does your business actually need an app?
An app justifies itself in three situations:
- Repeat use: the user opens it more than once or twice a week. Field staff, customers with recurring orders, club members. For someone who visits once a month, a website is enough.
- Device capabilities: push notifications, camera (document or barcode scanning), realtime location, offline work, Bluetooth, on-device payments.
- The app is the product: a marketplace, an on-demand service, a consumer product. Here there is no whether, only how.
Native, React Native or PWA: how to choose in 2026?
| Approach | When it fits | What the choice costs you |
|---|---|---|
| React Native / Expo | Most business apps: one codebase for iOS and Android, OTA updates, a team shared with the web | Deep native integrations need dedicated modules |
| Flutter | Highly custom UI and heavy animation, or a team already on Flutter | Harder hiring in Israel, less synergy with web |
| Native (Swift / Kotlin) | Critical performance, AR, video processing, deep system integrations | Two codebases, two teams, roughly double the time and cost |
| PWA | No app store needed, mostly browser use, a tight budget | Limited push and offline on iOS, no store presence |
The full React Native vs Flutter comparison, including performance, hiring and maintenance, is in a separate post. Bottom line: for most businesses in 2026, React Native with Expo is the pragmatic default.
The app development process: from idea to store
- Problem and users (a week): the one thing the app does better than any alternative, who uses it and how often.
- Scope and UX (2–3 weeks): core flows, 5–10 main screens, a clickable prototype tested with real users.
- Architecture and backend: data model, permissions, API, authentication, notifications, monitoring. In most business apps the backend is more than half the work.
- Iterative delivery: an installable build (TestFlight / Internal Testing) every week or two, feedback, re-prioritisation.
- QA on real devices: screen sizes, older OS versions, slow networks, offline mode, denied permissions.
- Stores: developer accounts in your name, privacy policy, screenshots, Apple and Google review. Plan a week or two for a review round and possible rejections.
- After launch: analytics, crash reporting, the yearly OS updates, and a maintenance plan.
What does a business app cost in 2026?
With a professional team in Israel: a simple MVP app (sign-up, a few core screens, a basic backend) costs roughly ₪80K–150K; a mid-size app with payments, notifications, integrations and an admin panel ₪150K–300K; and a product with realtime or AI starts around ₪400K. The full breakdown is in our cost guide.
Four costs almost always missing from a first budget: the backend and admin panel (the app is only the tip), store accounts and fees, the yearly iOS and Android updates that require adjustments, and ongoing maintenance at 15%–35% of the build cost per year.
What to prepare before approaching an app development company?
- One sentence describing the problem: "our field staff report faults over WhatsApp and management sees nothing" is worth more than a 40-slide deck.
- Who the users are and what they do today without the app. That defines the first screens.
- 5–10 core screens, even as a paper sketch. You do not need design, you need the flow.
- Existing systems to connect to: CRM, ERP, payments, time tracking, delivery providers.
- A realistic budget range and timeline. A serious vendor uses them to propose what goes into version one and what does not, not to fill the budget.
Common mistakes in business app development
- Building an app when a website would do, or the reverse: building a website when users need push and offline.
- Starting from the design instead of the backend and the data. A beautiful app on a shaky backend collapses as soon as there are users.
- A first version with 30 features. A good app does one thing excellently; the rest comes after there is usage data.
- Store and cloud accounts in the vendor's name. At the end of the project, or in a dispute, this becomes a real problem.
- Forgetting that an app is alive: new OS versions every year, libraries that age, store policies that change. Without maintenance, the app stops working.