Building a Mobile App in Antalya: What Determines the Cost and the Timeline?
You have an app idea in mind, and your first question is probably this: how much will it cost, and how long will it take? The honest answer is that both questions depend on the scope, not on the idea itself. Two apps described with the same sentence — “let customers place orders” — can differ in cost many times over. This article does not give a price list; it explains what determines cost and time, how to compare quotes, and what you must not forget in the first-year budget.
First decide what type of app yours is
What determines the cost most is not the number of screens, but what the app does and on whose behalf. The four tiers below build on each other, and each tier grows the job noticeably.
- Content or catalogue app: The user views, searches, saves. The server side is relatively simple.
- Transactional app: Orders, appointments, bookings. Now status tracking, notifications, cancellations and error scenarios come into play.
- Platform between users: Two sides interact with each other — buyer and seller, customer and tradesperson, user and user. Messaging, ratings, complaints and moderation become necessary; this is the most underestimated tier.
- Internal business tool: No store release is needed and the number of users is known, but integration with your existing systems and permission rules come to the fore.
Placing your idea in one of these four tiers makes the quotes you receive comparable. If you are not sure, we can clarify this together in the first meeting.
The items that determine the cost
A mobile app quote should list each of the items below separately. A single-line figure says nothing about the scope.
| Item | What you should ask |
|---|---|
| Server side (backend) | Who holds the data, where does the business logic live? More than half of the cost is often here, and it is invisible on the screens. |
| User roles | A single type of user, or layers such as customer–business–admin? Every role means separate screens and separate permission rules. |
| Admin panel | Where will you manage the app from? If it is not in the quote, the app cannot be managed even once it is live. |
| Integrations | Payment, maps, SMS, e-Fatura (Turkey’s e-invoicing system), shipping, your existing software. Each one is separate development, separate testing and, in most cases, a separate subscription. |
| Design | Will it be built with ready-made components, or will a brand-specific interface be designed? |
| Platform | One platform or two? The technology choice affects this item directly — see our native or cross-platform article. |
| Test coverage | How many devices, how many scenarios, how many rounds of fixes are included? |
| Store submission | Who is responsible for opening the accounts, submitting for release and fixing things in case of rejection, and how many submissions are included? |
| After delivery | How many months of support are there, what does maintenance cover, how is it charged? |
What extends the timeline?
The timelines given at the quote stage are usually development time. The things that extend a project, however, are mostly outside development:
- Decisions left waiting: If there is no one on the business side who can make decisions, every question extends the project.
- Content and data: Product list, texts, images, existing data — if they are not ready, the launch waits even when development is finished.
- Scope growth: “And if it could also do this” requests are the most common cause of delay. Every new feature brings testing and fixing time on top of development.
- Third-party approvals: A payment provider application, an e-Fatura integration or an API access permission is neither in your control nor in the developer’s.
- Store review: Its duration and outcome depend on the stores’ decision.
When getting quotes, ask for the timeline together with the scope, in writing and broken into phases. A promise of “it will be live on this date” is one that no developer can give on their own, because of store review.
Ready is not the same as live
There is a separate stage between the app working and the app being downloadable from the stores. Developer accounts are required for the App Store and Google Play, and these accounts are paid; check the current fees on Apple’s and Google’s own developer pages. We recommend that the accounts are opened in your business’s name — even if you change companies later, the app, the reviews and the download history stay with you.
Both stores review uploaded apps and can reject them. Rejection is not unusual; the requested fix is made and the app is resubmitted. Clarify from the start who carries this responsibility in the project and how many submissions are included in the scope.
What gets forgotten in the first-year budget
The development fee finishes the project; the items that keep the app alive are ongoing. When making your first-year budget, take these into account too:
- Store developer accounts
- Server and database hosting — grows with the number of users
- Usage fees for services such as notifications, maps, SMS and email
- Error tracking and monitoring tools
- Compatibility work for operating system updates
- User support — who will answer the customers using your app?
- Promoting the app; downloads do not happen by themselves
If your budget is limited: narrow the scope, not the quality
The best thing you can do with a limited budget is to shorten the feature list. An app that does one job properly from start to finish is both cheaper and used more than an app that does ten jobs halfway. Deciding what stays out of the first version is more decisive than deciding what goes in. We covered the details of this approach in our validating an idea with an MVP article.
A second option is this: test the problem the app solves with a mobile-friendly web interface first. If offline use, camera, location or notifications are not essential, this route is shorter and takes the store process off the table entirely.
Frequently asked questions
If I describe my idea, can you give me a rough figure?
In a short meeting, we can outline the scope and tell you which tier you are in and what is driving the cost up. A figure given before the scope is clear would mislead both of us.
Can I start on a single platform?
Yes, and sometimes it is a sensible decision. If you know the device breakdown of your target audience, you can release the first version on one platform and collect feedback. Single-codebase technologies make the move to the second platform easier.
How much does it cost to make changes after launch?
Areas such as content, prices and campaigns can be left to you through the admin panel — these are free. Changes to screens or functionality require a new version and go through store review.
Who keeps the app’s source code?
This is something written into the contract; there is no single standard in the industry. Clarify it at the quote stage — ask us this too, and ask every company you talk to.
Website first, or app first?
If your customers find you through search, the website usually comes first; an app creates value when there is a repeated usage relationship. We covered this decision in detail in our website or mobile app first article.
Let’s outline the scope of your idea together
Tell us who will use it, which problem it will solve and the features you consider essential in the first version; let’s outline the scope and a realistic plan together. You can look at our Antalya mobile app development service and get in touch for a quote — we work in English or Turkish. We collected what to look for when choosing a company in our choosing a software company article.