How to hire mobile app developers: decide the job before the person

You want an app in both stores, and you are about to pay someone to build it. Most advice on how to hire mobile app developers starts with the person: the portfolio, the hourly rate, the interview. Start with the job instead. Decide whether one codebase should serve iPhone and Android, how much of the work sits outside the app itself, and whether the work has an end date. Those three answers choose the way you hire, and that tells you what evidence to ask for, whose name the accounts sit in and what a month should cost.

Decide the job before you hire app developers

One codebase or two. Flutter and React Native build the iPhone app and the Android app from one codebase, so one developer can carry both and every fix reaches both platforms at once. Native development means Swift for iPhone and Kotlin for Android: two codebases, usually two developers, and every feature built twice. Native is worth that cost when the app depends on platform features such as watch apps, home-screen widgets or car displays. React Native is the better choice when your own web team writes React and will look after the app later. For most other apps, Flutter is the sensible default.

The screens are the smaller part. A shared shopping list looks like a few screens. Behind them sit sign-in and accounts, a database that keeps every phone up to date, push notifications, an admin panel for your staff, the store listings, the privacy forms each store requires, and a new iOS and Android release every year that can break something that worked. Then come the updates after launch, which continue for as long as people use the app. When you hire app developers who have only built screens, they will quote for the screens.

An end date, or not. An app with a fixed scope and nothing planned after launch is a project. An app that will change every month needs someone who stays.

Three ways to hire, and the stage each one fits

Freelancer or company is a separate question, and the comparison of freelancers and agencies for app work covers it. Whoever you choose, the work reaches you in one of three shapes.

A project with a scope and an end. You agree the screens, the backend and the release, and the price is fixed before the build. This fits a first version with clear limits, or a rebuild of something that already exists. Mobile app development as a scoped project starts at US$4,000. Anything added after the scope is agreed becomes a change request, which is fair, and is also why a project is the wrong shape for an app you are still working out.

A dedicated developer by the month. One person works only on your app, in your repository and your tools, and you decide what they build next. This fits an app past its first version that ships every few weeks, where someone on your side can set priorities and read what gets built.

A retainer. The vendor owns the technical decisions as well as the work: architecture, release planning, upgrades and the response when something breaks. This fits a business with an app in production and nobody technical on staff, which does not want to hire one.

What app developers for hire should be able to show you

Most app developers for hire can show a portfolio of screenshots, and screenshots prove that someone can use a design tool. Ask for evidence that only comes from shipping.

• Apps live in both stores, under a developer account they can show you. The seller name on the store listing tells you who published it. A client's app under the client's name is fine, as long as they can explain which part was theirs.
• Release history. Both stores show when an app was last updated. An app updated steadily since launch has been maintained. An app nobody has touched for a long time was delivered and left.
• The last store rejection. Every developer who ships is rejected at some point. Ask which of the App Store Review Guidelines it was, what they changed and how long the fix took. A developer who has never been rejected has usually submitted very little.
• The privacy paperwork. Apple asks for a privacy manifest and privacy details for the listing, and Google asks for the Data safety form. Ask who fills them in and how they find out what each third-party library collects. A vague answer here becomes a rejection later.
• The backend they built and still run. Ask where the data lives, who receives the alert when it goes down and how it is backed up.

We publish eleven apps of our own, ten on Google Play and eight on the App Store. All eleven are built in Flutter, and each app has been kept current through its store's review process since launch. The portfolio links them to their store listings, so you can read the release history before any call.

Put every account in your name before the first build

The app belongs to whoever owns the developer accounts. Apple shows the organisation that enrols in the Apple Developer Program as the seller of the app, and enrolling as an organisation needs a D-U-N-S number, so start that step first. Create the Google Play Console account, the code repository, the Firebase or cloud project and the domain for your privacy policy in your company's name as well, then add the developers as members. If a developer offers to publish under their own account to save time, the saving is a few days and the cost is a store transfer later, if they agree to one. The full list of accounts and what to grant on each goes through them in order.

What a month costs, and what to agree before it

Our published rate for Flutter and React Native developers is US$20-38 an hour, set by seniority, and a dedicated developer by the month starts from US$3,500 a month. You get the exact figure before you interview anyone. A retainer is priced at the same rate per person. An hourly figure on its own hides review, cover and replacement, and the arithmetic behind a dedicated developer's monthly cost shows how two identical hourly rates end up far apart.

Two terms matter more than the rate. Interview the person who will write the code before they start, not only the person who sold you the engagement. And agree a month's notice in both directions, written into the contract, with no long minimum term for a dedicated developer. Notice both ways protects you if the fit is wrong, and it protects the app from a developer who leaves without a handover.

Red flags before you sign

• The app will be published under the developer's account "for now".
• A fixed price arrives before anyone has asked about the backend.
• Nobody reviews the code except the person who wrote it.
• The portfolio is screenshots, with no store links.
• A long minimum term, with no notice clause.
• No clear answer to "what happens when the next iOS release breaks something?"

How to hire mobile app developers, in order

Put together, the order is short: decide the job, choose the shape that fits the stage the app is at, ask for evidence you can open yourself, put every account in your name, and interview the person who will write the code before they start. If one Flutter codebase fits your app, you can hire Flutter developers by the month, in the same stack as our own apps. If your team already writes React and will maintain the app after launch, React Native developers are the better fit, and the same evidence applies: apps in both stores, a release history and the accounts in your name.

*Related: MVP development services · Dedicated development team · Software development partner*