What a mobile app project really includes
Native or cross-platform, in one paragraph
For most apps we recommend a shared codebase, usually Flutter. Lists, forms, payments, chat, maps, video and push notifications all work well there, and you pay for one team instead of two. We suggest native Kotlin and Swift when the app is built around something the operating system does (heavy Bluetooth work, background location, widgets, watch or car companions), or when you already have native code worth keeping. React Native makes sense when a React web team will own the app. The longer version, with the cost and maintenance arguments, is on the cross-platform page linked above.
The server is part of the app
Almost every app is a client for data that lives elsewhere. Someone has to design the endpoints, decide how login tokens are issued and refreshed, store uploads, send push notifications and keep old app versions working after the API changes. We build that side in Laravel or plain PHP, and we cover the details in mobile app API integration. If you already have a backend, we read its documentation first and tell you what it is missing before we quote.
An admin panel your staff will use
Apps need operators. Support staff look up a user, marketing schedules a notification, finance exports orders, a moderator hides a post. Without a web admin these jobs land on a developer with database access. We scope the admin panel with the app, adding roles and an audit trail where the data calls for it.
Store publishing is a workstream
Apple and Google each want a developer account in your company's name, a privacy policy, data collection disclosures, screenshots for several screen sizes and a test login for the reviewer. Apps with accounts need a way to delete them. Digital goods have to go through store billing. We raise these points during scoping, set up TestFlight and Play testing tracks early, and submit a first build well before the launch date so review feedback arrives while there is still time to act on it.
Analytics, crash reports and the year after launch
We agree on a short list of events worth tracking (sign-up finished, first purchase, lesson completed) and wire them in alongside crash reporting, so the first week of real usage tells you something. After that the app needs looking after. Both platforms ship a major OS version every year and both stores keep raising their SDK requirements, which is why we offer app maintenance as a plan and hand over everything you would need to run it without us.