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, a shared codebase that reduces duplicated maintenance across iOS and Android, and an experience that can be very close to native for most standard uses. 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 a strategy designed to stay useful rather than intrusive;
- 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.
When another solution will fit better
- 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.
