A useful estimate starts with the product’s core loop: what a user must be able to do, what data the app needs, and what has to happen outside the iPhone. A five-screen utility with local storage is a different project from a marketplace with accounts, payments, messaging and an admin backend—even when both are described as an “MVP”.
A good budget is a product decision. It should buy enough functionality to test the business assumption without financing every future feature.
Three common engagement levels
Focused MVP sprint
A narrow native MVP can begin around €3,000 when the scope is fixed, the main flow is clear and the backend needs are modest. This is suitable for one strong use case, a small number of screens and a deliberate list of exclusions.
Complete first release
A fuller product often starts around €8,000. The additional budget covers more states, production integrations, deeper UI work, analytics, release preparation and the less-visible work needed for a dependable app.
Ongoing development
After launch, a retainer from €1,500 per month can cover feature iterations, iOS compatibility, performance work and release support. It works best when the product already has users or a validated roadmap.
What changes the price
- Accounts and permissions: sign-in, recovery, roles and secure session handling add edge cases.
- Backend complexity: real-time data, file storage, server rules and admin operations require work beyond the app UI.
- Payments: StoreKit subscriptions, RevenueCat, entitlement recovery and paywall experiments need careful testing.
- Native capabilities: Bluetooth, camera, background tasks, widgets, notifications and extensions each add platform-specific states.
- Design maturity: a supplied design system is different from discovering flows and visual direction during development.
- Existing code: inheriting an app can save time—or reveal architecture and reliability work that must happen first.
How to control the budget
- Write one sentence describing the user outcome.
- Choose the smallest repeatable flow that produces that outcome.
- Separate launch requirements from later improvements.
- Resolve the highest technical risk before polishing secondary screens.
- Use platform conventions instead of inventing custom behaviour everywhere.
- Define acceptance criteria and exclusions before development starts.
What an estimate should include
Ask for more than a total. A useful proposal explains the first-release scope, assumptions, excluded work, delivery stages, required accounts, ownership of code and assets, App Store responsibilities, and support after release. If those details are missing, the number is not yet an estimate—it is a guess.
Need a scoped estimate?
Send the product idea, current stage and target date. I will reply with the smallest sensible first release and the main risks.
Leave a project request