Most businesses that say "I want to get a mobile app built" ask about price first. What sets the price, however, is scope: what job the app will do, who will use it and which system will sit behind it. This guide covers the order of steps, the decision points and real cost ranges.
First question: do you really need an app?
Let's be honest – for some of the requests we get, an app is the wrong solution. In these three situations a mobile app wastes money:
- If users open it 2–3 times a year. People do not install something on their phone that they will use three times a year. A mobile-friendly website does the same job.
- If the app is an exact copy of the website. If there is no added value, there is no reason to download it from the store either.
- If you do not have traffic and a customer base yet. An app is good at retaining existing customers, not at finding new ones.
In contrast, an app clearly pays off in these cases: frequently repeated use (ordering, booking, tracking), processes that need notifications, the need to work offline, use of device features such as the camera, location or NFC, and field team operations.
Step 1: Write down the use case
Before designing any screens, write a single sentence: "[Who] will open the app [in which situation] [to do what]."
Example: "A dealer representative will open it during a customer visit to check stock and enter an order." Once this sentence is clear, the screens you need follow naturally – and, more importantly, so do the ones you do not need.
Other questions that need answers:
- Will the app serve customers, staff or dealers?
- Do you need sign-up, payments, notifications or maps?
- Will there be a panel to manage the content?
- Will iOS and Android be released at the same time?
- Why will the user open the app a second time?
The last question is the most critical. If it has no answer, the project succeeds technically and fails commercially.
Step 2: Native or cross-platform?
| Native (Swift / Kotlin) | Cross-platform (React Native / Flutter) | |
|---|---|---|
| Cost | Two separate codebases, ~60–80% more expensive | One codebase |
| Performance | Highest | Sufficient for most business apps |
| Device features | Full access | Most features ready, some need a bridge |
| Updates | Two teams, two processes | One development track |
| When it is needed | Heavy graphics, games, intensive camera/sensor processing | Ordering, booking, catalog, field work, content |
In practice, cross-platform is the right answer for the vast majority of business apps. React Native and Flutter deliver an experience indistinguishable from native in standard business flows and cut the budget almost in half. Native should be kept for projects that push the device hardware to its limits.
Step 3: Define the MVP scope
An MVP is the smallest yet genuinely usable first version of the app. Its purpose is not to cut features but to put the core value in the hands of real users as soon as possible.
In the MVP: the screens that complete the main flow, login and a basic admin panel.
Not in the MVP: social media sharing, badge/points systems, multiple languages, advanced reporting, theme selection.
In projects that do not make this distinction, two things happen: the launch date slips from 3 months to 9 months, and half of the features that eventually ship are never used. We go into the MVP approach in detail in the MVP mobile app guide.
Step 4: Panel and API – the invisible half
Behind most mobile apps sits a web panel and an API. This is usually where 40–50% of the budget goes. What needs to be planned from the start:
- User and permission management
- Content/product/service management
- Order or request flow
- A screen for sending notifications
- Basic reporting
In apps built without thinking about the panel, every content change goes back to the developer, you wait for store updates and operations get stuck. The decision "let's build the app, the panel can come later" ends up being the most expensive one.
If you have an existing system (ERP, accounting, e-commerce), the app needs to talk to it; that is a separate API integration item.
Step 5: Store release
Releasing on the App Store and Google Play is not a matter of "uploading the code and you're done". What needs to be prepared:
- App name and store description (ASO work)
- Screenshots for every device size
- A privacy policy link and data usage declaration
- Permission explanations (camera, location, notifications – each with a justification)
- A test account and review notes for Apple
- Developer accounts: Apple 99 USD a year, Google a one-off 25 USD
Apple's review process has a high rejection rate on first submission; requesting permissions without justification and an incomplete privacy declaration are the most common reasons for rejection. When these preparations are left to the end, the release is delayed by 2–3 weeks.
Cost and timeline
| Scope | Timeline | Budget |
|---|---|---|
| MVP (5–8 screens, panel, one flow) | 8–12 weeks | 100,000–200,000 TL |
| Mid-size (payments, notifications, integration) | 3–5 months | 200,000–450,000 TL |
| Comprehensive (multiple roles, ERP-connected, offline) | 6+ months | 450,000 TL and up |
Our mobile app development package starts from 100,000 TL + VAT (KDV, Turkey's value-added tax). We explained item by item what changes the price, and how, in the article mobile app prices.
What needs to be added to the budget: annual developer accounts, server costs and, most importantly, maintenance. iOS and Android each release a major version every year; apps that are not updated risk dropping out of the store within 18–24 months. Setting aside 15–20% of the project fee for annual maintenance is realistic.
What should a sound quote include?
When you get a quote, ask for these points in writing:
- A list of screens and a user flow diagram
- The iOS and Android scope stated separately
- The admin panel and API scope
- Special modules such as notifications, payments, maps and subscriptions
- The testing process and acceptance criteria
- Store release support (account setup, submission, rejection handling)
- The length and scope of post-launch support
- Who will own the source code and the store accounts
The last item is often skipped and causes problems later: if the store account was opened in the developer's name, you do not have full control over your app. Accounts should always be opened in your company's name.
Frequently Asked Questions
How many months does it take to finish an app?
8–12 weeks is realistic for an MVP. Of that, 2 weeks is design, 6–8 weeks development and 1–2 weeks testing and the store process.
Which platform first?
In Turkey, the number of users is higher on Android, while spending is higher on the Apple side. When you choose cross-platform, this decision disappears anyway.
Can another team take over the app later?
Yes, if the source code has been handed over to you and the code is documented. Having this clause in the contract removes the dependency.
Do I need an app if I already have a website?
Look at the three points at the top of this article. If usage frequency is low, a mobile-friendly website is a smarter investment.
How to get started
Write your use case in one paragraph and send it over; we will work out free of charge what goes into the MVP and the estimated timeline.
Phone / WhatsApp: +90 536 628 0007
Email: info@enextware.com
