Native or cross-platform: the decision everything else follows
This is the first question on any mobile project, and the most expensive one to answer too quickly. Cross-platform (React Native, Flutter) means a single codebase for both iOS and Android: faster to build, roughly half the maintenance, and indistinguishable from native for the vast majority of apps. Native (Swift for iOS, Kotlin for Android) regains the advantage as soon as you touch specialised hardware, heavy graphics processing, or recent system features.
I don't push one technology out of habit. The choice follows your case: the features actually planned, the maintenance budget over three years, and the profile of whoever will inherit the code. In practice most SME and startup apps ship better cross-platform — but not all of them, and I'll tell you which.
What a delivered app actually includes
A released app is more than screens that work. The scope systematically covers:
- user flows and interface design, before the first line of code;
- authentication and user account management;
- the backend and API, or integration with your existing system;
- push notifications, with sending logic that doesn't get the app deleted;
- offline mode where the usage justifies it;
- testing on real devices, both iOS and Android;
- release on the App Store and Google Play, including Apple's review process;
- an optimised store listing: title, description, screenshots, keywords.
How a project runs, week by week
A mobile project runs in four stages. First scoping: we list the features, decide what ships in version one and what waits, and you get a firm schedule. Then design: flows, screens, edge cases — this is where expensive back-and-forth gets avoided. Then development, delivered incrementally: you test the app on your own phone while it is being built, not at the end. Finally acceptance testing and release.
You get a progress update every week and permanent access to the state of the project. Nobody waits three weeks to discover the app doesn't do what was agreed.
Budget and timeline: the orders of magnitude
A mobile app ships in 6 to 12 weeks depending on scope. The range is explained almost entirely by three factors: the number of distinct user journeys, whether an admin back-office is needed, and how much integration with existing systems is involved — payment, ERP, CRM, internal tools.
Every quote follows a free scoping call, and the price is fixed: no overage billing on a scope already agreed. If the available budget doesn't cover the desired scope, we cut the scope — never the estimate.
What I don't take on
- Projects without a decision-maker. If every feature needs three approvals, the announced timelines won't hold — and I'd rather say so before committing.
- Taking over undocumented code without an audit phase. On legacy work, no timeline commitment before a prior audit.
- Design without development. I design what I build.
- Timelines below the scope. An app doesn't ship in three weeks. If that's the constraint, we cut scope, not the estimate.
Frequently asked questions
How much does it cost to build a mobile app?
The price depends on scope: number of user journeys, whether an admin back-office is needed, integrations with existing systems. Rather than a range that means nothing, you get a fixed price after a free scoping call, once the scope has been settled.
Do I need to build for iOS and Android at the same time?
With cross-platform, yes: a single codebase produces both apps, so there is no saving in building only one. With native, each platform is a separate build — there, starting with the platform your users are actually on makes sense.
Who owns the app's source code?
You do. The complete source code is handed over and remains transferable to another provider or an in-house team. No dependency on a platform or proprietary tool whose keys you don't hold.
Do you handle publishing to the app stores?
Yes, it's included: developer account setup, store listings, screenshots, and Apple and Google review. Apple's review can take several rounds; those are covered, not billed as extras.
What happens after launch?
Release isn't the end of the project. I offer monitoring, fixes for issues raised by early users, and subsequent iterations. Since iOS and Android evolve every year, a living app requires maintenance.