How much should you budget for a mobile app?

Price one usable journey before counting screens

Consider a hypothetical field-service pilot: a worker signs in, opens assigned jobs, records a form offline and submits it when connectivity returns. An operator reviews the result in a small web administration view. The estimate includes iOS and Android, an existing identity provider, one backend integration and agreed accessibility checks. Payments, a scheduling optimizer, new hardware and regulated clinical decisions are excluded. This is an estimating exercise, not a shipped client project.

A five-screen app can hide expensive permission rules, conflict resolution and unreliable upstream systems. Write acceptance examples first: a worker cannot see another team’s jobs; closing and reopening the app preserves an unsent form; a retry does not create two records. Ask each supplier to state which of these behaviors their price covers. Android’s offline-first architecture guidance explains why connectivity affects the data layer, rather than being a checkbox added after the screens.

A transparent example in EUR

Assume 44 person-days at EUR 900 per day: EUR 39,600. Add an illustrative 20% delivery reserve of EUR 7,920, giving EUR 47,520 for the initial build. Both the rate and reserve are assumptions, not Wavect prices or market averages. The phase table below shows the 44 days. Person-days are effort, not elapsed calendar days; parallel work, client decisions and store review change the schedule.

For the first 12 operating months, assume EUR 300 per month for hosting and tools (EUR 3,600) and two maintenance days per month at the same illustrative rate (EUR 21,600). Initial build plus these operating assumptions totals EUR 72,720, excluding VAT. Store-program fees, paid third-party services, transaction charges, content production and new features are excluded and need separate lines. The reserve covers delivery uncertainty, not a second maintenance allowance. Download the assumptions and arithmetic and replace them with your own quote inputs.

What changes the mobile estimate?

Offline writes require decisions about local storage, identity expiry, retries and conflicting edits. A read-only cache is a different scope from submitting a legally significant record. Device hardware, Bluetooth accessories, background activity and camera behavior need a prototype on target devices before a supplier promises broad compatibility.

A shared framework is not two finished apps for the price of one. React Native documents platform-specific code, while Flutter describes its platform integration layers. Use those boundaries to ask what must remain native, which dependencies need maintenance and who can reproduce the release. The React Native versus Flutter comparison addresses stack selection; this guide addresses what a budget must include.

Test the release, not only the demo

Agree physical devices, OS versions, screen-reader journeys, slow connections, interrupted uploads and expired sessions. Test the signed release build as well as development builds. Include permission refusal, background/resume behavior and account removal where applicable. Record defects by user impact and agree the blocking threshold before launch. A green automated suite does not demonstrate every device or accessibility behavior.

Assign ownership of developer accounts, certificates, signing keys, privacy declarations and release notes. Apple’s review guidelines are a primary reference for the submission process and requirements. A development completion date is not an approval guarantee. Budget review-response work explicitly and distinguish a supplier defect from a later policy or product change.

Compare proposals on equal terms

Request a scope table with included journeys, excluded functions, accepted devices, dependencies, test evidence, client responsibilities and post-release support. For each uncertainty, name the experiment that would resolve it and the decision date. Do not conceal a missing integration behind an unexplained contingency percentage. If the API is undocumented, a small integration probe may be more valuable than another polished screen.

After launch, plan OS and dependency updates, monitoring, incident response, restore procedures and a repeatable store release. Ongoing feature development is separate from keeping an accepted version working. Ask what happens if you stop the engagement: repository access, accounts, build instructions, data export and an owner for outstanding incidents should already be clear. Mobile App Development owns a commissioned app; Software Discovery can define the scope before procurement.