How to Hire an App Developer: What to Pay and Who to Trust

If you want to hire an app developer for a first product, pick a senior freelancer when the scope is small and you can judge what ships, and pick an agency when you need design, backend, mobile and testing done together and nobody on your side writes code. Hire in-house only after the first version has proved people want it. Whoever you choose, the Apple and Google developer accounts and the code repository belong in your name from the first day.

That answer fits most founders, and it has exceptions. We build apps for a living, so you should expect us to like agencies. We will tell you plainly where an agency is the wrong call, because that is the part that makes the rest of this believable.

This post covers the three hiring models, what each costs, how to check a portfolio, the questions worth asking, red flags, what you must own, and how long the whole thing takes. If you want the rate tables in more detail, we wrote them up in how much it costs to hire a mobile app developer.

Every option below works for someone. The mistake is picking by price alone, because the cheapest option on paper is often the most expensive one by month six.

A freelancer

One person, one point of contact, no overhead. A strong senior freelancer is the cheapest way to get a competent app built, and decisions happen in minutes instead of meetings. The risk is also one person. They get sick, take a full-time job, or turn out to be excellent at screens and weak at the backend, the release pipeline and the store listing. Freelancers work best for a clear, small to medium scope with someone on your side who can review the work.

An agency

You pay more per hour and get a team: a designer, mobile engineers, a backend engineer, someone who tests on real phones, and a person who keeps the schedule honest. If you have no technical background and need a whole product, this is usually the lower-risk path, because the alternative is managing four freelancers who have never met.

An in-house hire

The best long-term economics and the deepest product knowledge, and also the slowest start. A senior mobile engineer search often takes two to four months, and until that person sits down you have no product. Founders who hire an employee to build a version one they have not yet validated usually regret it. Validate with a contractor or an agency, then hire the person who will own it for years.

There is a fourth option that gets overlooked: a technical advisor. A few paid hours a month from someone who writes code for a living will catch most bad proposals before you sign them.

We would rather lose a deal than take a project that should have gone elsewhere. Here is when you should not hire a firm like ours.

• Your budget is small and the scope is tight. A single freelancer will do a simple app for noticeably less, and an agency's project management and design time will eat your runway.
• You have a technical cofounder who wants to write the app. Hire a contractor to work beside them on the pieces they have not done, not a team to replace them.
• Mobile is the whole business and you plan to ship weekly for years. You will outgrow any outside team. Build your own, and use an agency only to get version one out the door if you must.
• You want to sit next to the person writing code every day. An agency adds a layer between you and the keyboard, and some founders cannot stand that.
• You are not sure what you are building. Pay for a short discovery or a clickable prototype first. Paying a team to build the wrong thing quickly is a good way to burn a seed round.
• You want the lowest possible price above everything else. There is always someone cheaper, and sometimes they are fine. Just know what you are trading.

An agency is the right call in the opposite situations. You need design, a backend and a mobile app on one schedule. Nobody on your side can review code. You have funding or a launch date and cannot afford to spend two months finding people. If that sounds like you, keep reading, because the vetting steps below apply to us too.

These are market estimates, not quotes. They shift with location, seniority and how scarce the skill is. Use them to sanity-check proposals.

• Freelancers in lower-cost regions: roughly $25 to $60 an hour. Quality varies more than price, so vetting matters most here.
• Freelancers in the US and Western Europe: roughly $90 to $170 an hour for a senior mobile developer. Specialists in payments, media or hardware sit at the top.
• Agencies: roughly $100 to $200 an hour blended, or a fixed project price. The rate pays for design, QA, project management and a second set of eyes on every pull request.
• In-house senior mobile engineer in the US: a salary around $150,000 to $210,000. Benefits, equipment and recruiting fees push the real cost well above that.

A small to medium app built by a decent team usually lands in the tens of thousands of dollars. Products with real-time features, payments and a custom backend go well past that. What moves the number most is the feature list, the number of platforms, and how much of the backend has to be built from scratch.

Two things distort comparisons. A cheap hourly rate attached to a slow developer costs more than an expensive rate attached to a fast one. And a quote that covers only the app, with no backend, admin tools, testing or store submission, is not a quote for a product. Ask every candidate for a written list of what is in and what is out.

Budget for the running costs too. Apple charges a yearly developer fee, Google charges a one-time registration fee, and you will pay for hosting, push notifications, analytics and crash reporting. Confirm current prices when you sign up. They are small next to build costs, but they should not surprise you.

Start with shipped work. Ask for store links and install each app on your own phone. Use it for ten minutes, then ask the candidate which parts they personally built. A developer who says "we" about everything and cannot name a single screen is telling you something.

Once the app is open, look at these:

• Speed and feel. Does it open fast, scroll smoothly and respond to the back gesture the way the phone's own apps do?
• Bad conditions. Switch on airplane mode halfway through a task. Rotate the phone. Leave the app and come back. Good apps recover. Weak ones freeze or lose what you typed.
• Update history. Open the version history on the store listing. An app untouched for two years is a warning, since both platforms change every year and neglected apps start to break.
• The one-star reviews. Crashes, login failures and billing complaints tell you more about the engineering than any case study page.

Then call a reference, and ask for one from a project that went badly. Every team has one. How they describe it, and what they changed afterward, shows you how they behave when things get hard. Ask the reference whether the team flagged problems early or hid them, and whether the app is still running today.

For a real example of a scoped, shipped project, look at Vybes, a members-only, video-first dating app we built in React Native for iOS and Android. It went from concept to the App Store in eight weeks and holds a 4.8 App Store rating. Hold every candidate, including us, to that standard: live links, named roles, numbers you can check.

You do not need to be technical to interview well. You need questions where the quality of the answer is obvious even if the vocabulary is not. If you know someone who codes, ask them to sit in.

1. Which parts of the last app you shipped did you build yourself, and which did someone else build?
2. Would you build this native or cross-platform, and why? A good answer names a tradeoff tied to your product. A weak one recites a favorite tool.
3. What will you not build in version one? Developers who say yes to everything have not shipped under a deadline.
4. Who holds the store accounts, the signing keys and the repository during the project? The only acceptable answer is you.
5. How do you get a build onto my phone each week? You want TestFlight and a Play Store testing track, not a screen share.
6. What happens when the app crashes for a user? Look for crash reporting, alerts and a named person who reads them.
7. Tell me about the last bug you shipped to production. Everyone has one. Evasion is the red flag.

Then run a paid trial. One or two weeks on a real piece of your product, paid at their normal rate, shows you their code, their communication and their pace. Free test projects insult good developers and attract people with time on their hands. Pick something concrete, such as a sign-in flow or one list screen with live data, and ask for a build on your phone at the end.

For agencies the checklist is wider: who writes the code, how long the team has worked together, and how changes are handled. We cover it in how to vet a software development agency.

Bad hires show their problems early. Watch for these.

• A fixed price quoted on the first call, before anyone has asked what the app does.
• No live apps, or only apps they cannot name a role in.
• A portfolio of mockups, Figma screens or template apps that are not in a store.
• Yes to every feature and no warnings about risk. Experienced developers push back on scope.
• A request to publish under their own developer account "to get started faster."
• Testing only in a simulator, or on one phone.
• No mention of crash reporting, analytics or release management in the plan.
• Vague answers about life after launch. New phone operating systems arrive every year and each one means work. A developer who treats launch as the finish line is leaving you a problem.
• Pressure to pay most of the fee up front or to skip a written contract.
• A team that disappears between the sales call and the kickoff, and a project manager you meet for the first time after you pay.

One red flag is a conversation. Three is a no.

This is the part founders skip and later regret. Your app lives in store accounts, and whoever owns those accounts controls whether the app can be updated, transferred or pulled.

Enroll in the Apple Developer Program and Google Play Console yourself, as your company, and invite your developer in with the roles they need to upload builds. Company enrollment on Apple needs a legal entity and a D-U-N-S number, and verification can take days or longer, so start before you need it. Do not let a contractor publish under a personal account to save time. Apps can be transferred between accounts, but it is slow and it gives the other side the upper hand in any dispute.

The rest of the ownership list is short:

• The source repository, hosted in your own GitHub or GitLab organization, with the developer added as a collaborator.
• Signing certificates and keys, or managed signing, under your team.
• Firebase, analytics, crash reporting and push notification keys, created under your email.
• Domain names, API keys and cloud hosting accounts.
• Design files, in your own Figma workspace.

Then get a written contract. It does not need to be long, but it should say a few things plainly:

• IP assignment. Everything built for you belongs to you on payment, including code, designs and documentation. Without an assignment clause, the person who wrote the code may own the copyright.
• Payment tied to milestones. Pay for working builds you have tested on your phone, not for hours or promises. A deposit is normal. Most of the fee up front is not.
• Handover. Repository, build instructions, environment variables and store access, delivered on completion and on termination.
• Warranty. A few weeks after launch where bugs from their work are fixed at no charge.
• Change process. How scope changes are estimated and approved before work starts.
• Exit terms. What happens if either side ends the work midway.

Have a lawyer read it once. A few hundred dollars here is cheap against owning your product outright. We are not lawyers, and this list is a starting point for that conversation.

Hiring takes time before building does, so plan for both.

• Freelancer: one to four weeks to find, vet and contract someone good. The best ones are often booked a month or two ahead.
• Agency: two to four weeks from first call to signed scope, including a short discovery phase.
• In-house: two to four months to hire a senior engineer, plus onboarding.

Then the build. A focused first version of a small to medium app usually takes two to five months from kickoff to the store, and longer for complex products. A tight scope can go faster: Vybes went from concept to the App Store in eight weeks. Add time at the end for store review. Many builds clear in a day or two, but a first submission is the one most likely to come back with questions, so do not schedule a launch party for the day you submit.

The fastest way to lose time is to start building before the big decisions are made. The second fastest is changing scope mid-build. A week spent on platform choice, the first-release feature list and the accounts saves a month later.

Here is how we would map common situations to a pick:

• A prototype to test demand: a freelancer on a short paid scope, with the store accounts and repository in your name.
• A marketplace or booking app for iOS and Android on a budget: a small agency or a senior freelancer, building in React Native.
• A funded startup with a technical cofounder: your cofounder builds, plus a contractor for design and the parts they have not done.
• A product where mobile is the business for years: hire in-house once the first version is validated.
• A founder with no technical background who needs design, backend, the app and the store listings: an agency, because the alternative is managing several freelancers yourself.
• A founder still unsure what to build: a paid discovery sprint or a clickable prototype before any developer is hired.

Platform choice sits behind all of these. If you already know you are iOS-first or Android-first, we wrote hiring guides for each: hiring an iOS app developer and hiring an Android app developer.

Kanopy builds mobile apps, and this is what we do: we help founders decide what to build first, set up the store accounts and repository in their own name, and ship the product through to the App Store and Google Play. If you want a second opinion on a proposal you already have, or a scope and a plan from us, Book a free strategy call