How to hire an app developer when you are not technical

To hire an app developer when you aren't technical, judge them on things you can check without reading code: apps they shipped that you can install, a written plan that says what's out of scope, and a small paid first milestone you install on your own phone. Apple's TestFlight lets a team share a test build with up to 10,000 external testers, and each build can be tested for up to 90 days (App Store Connect Help, checked 1 November 2026). Below: the steps, what it costs, and the checks we'd run on any studio, including us.

How do you hire an app developer, step by step?

Seven steps, in this order. The order matters more than it looks: the accounts come before the developer, and the small milestone comes before the big contract.

1. Write a one-page brief: who will use the app, the one job it must do well, and what can wait. How to write a brief for an app or software project has a template to copy.
2. Open the Apple and Google developer accounts and a code repository in your own name (check 5 below). A code repository is where the app's code and its full change history live, usually on GitHub or GitLab.
3. Decide what kind of developer you need: a freelancer, a studio, an agency or an employee (next section).
4. Find 3 candidates. Ask founders who have shipped an app whom they used, look through directories such as Clutch, or post your brief on a freelance marketplace.
5. Send all 3 the same brief and ask each for a written plan. Teams can only give you comparable quotes if they price the same product.
6. Run the checks below on each one.
7. Pay the strongest candidate for a small first milestone. Then sign for the rest, with a written assignment of the code to you and payments tied to milestones you've tried.

Who should you hire if you can't read code?

Someone who will run the technical side for you, against a plan you approve. If nobody on your side can review code or manage developers, a solo freelancer leaves that job with you.

Zoftaa is a small studio, so read the table knowing which row we sell.

How much does it cost to hire app developers?

Published data gives a wide range. Clutch puts the typical app project at $10,000 to $49,999, the average at $90,780.11, the usual timeline at about 11 months and the common rate at $25 to $49 an hour (Clutch, updated 21 September 2026, checked 1 November 2026). Clutch builds those figures from reviews on its own site and doesn't publish the sample size, so use them as a rough guide.

An employee is a salary every year, for as long as the app needs work. The median annual wage for software developers in the US was $135,980 in May 2025, before benefits and payroll costs (US Bureau of Labor Statistics).

Example (hypothetical): a 400 hour build at Clutch's band costs 400 × $25 = $10,000 at the low end and 400 × $49 = $19,600 at the top. The number of hours in a quote moves the total as much as the rate does, which is why a written plan you can compare line by line tells you more than an hourly figure.

Two costs are the same whoever you hire, and you should pay them yourself. The Apple Developer Program is "99 USD per membership year" (Apple), and Google Play has "a US$25 one-time registration fee" (Play Console Help).

We don't publish our own prices. After a scope call you get a fixed price and dates in writing.

The checks we would run on any studio, including us

None of these needs you to read code. The last column is us grading ourselves against our own list, so treat it as a claim to check, like anyone else's.

1. Install something they shipped

Ask for store links to apps the team worked on, and what they did on each. Then open the listings.

Every listing names the account that published it. On Google Play, an organisation account shows its "legal name, legal address, developer email address, and developer phone number", and a personal account shows the developer's legal name, country and email (Play Console Help). On the App Store, the seller is the organisation's name, or the person's own name on an individual account (Apple).

That name tells you whose account the app went out from. If a studio built an app for a business and the business's name is on the listing, that's a good sign: the owner kept control. If the studio's name sits on an app it says it built for someone else, ask why.

Install the app and do its main task. Then look at when it was last updated. Since 31 August 2026, an existing Android app that targets Android 14 or lower "will only be available on devices running Android OS that are the same or lower than your apps' target API level" (Play Console Help). An app nobody updates slowly disappears for new users, and a team whose apps all look abandoned may not be around after your launch either.

Where we stand: weak. The team has shipped Flutter apps to Google Play, but we don't name them on this site, and nothing is published under the Zoftaa name yet. Our own products will appear on our apps page with their store links when they launch. Until then, this check can't tell you much about us.

2. Check who you'd be signing with

Ask for the legal name of the person or company that will sign the contract and send the invoices, then look it up on the official register. In the UK, Companies House shows a company's registered address, incorporation date, and current and resigned officers for free (GOV.UK). Elsewhere, use the national or state register where the company says it's registered. Then put the website's domain into ICANN Lookup to see when it was registered.

A pass: the company exists, and the contract, the invoices and the bank account all carry the same name. Domain age is weak evidence on its own. A young domain doesn't make a bad team, and an old one can be bought.

Where we stand: we ran this check on ourselves on 1 November 2026. The registry record shows zoftaa.com was registered on 22 September 2026 (Verisign RDAP). Zoftaa is a trading name and the company isn't registered yet, as our About page says, so a register search won't find us. Ask us which person signs the agreement, and check the bank account is in that same name.

3. Talk to the engineer and read the written plan

Ask for a call with the person who would build your app. If the person on the sales call won't write any of the code, ask who will, and talk to them before you sign. You're about to trust their estimate.

A good engineer explains the plan in plain words, asks about your users before your feature list, and names at least one thing they'd cut from the first version. Then read the written plan. It should list the features, what's out of scope, the assumptions, the milestones with dates and the accounts the project needs. A price sent back after a two-line email can't contain any of that.

Where we stand: the people on your scope call are the people who write the code. Before any code, you get a fixed written plan with milestones, price and dates, the screens and features, what's out of scope and which store and cloud accounts are needed, as our mobile app development page sets out.

4. Pay for a small first milestone that ends on your phone

Agree a first piece of work that ends in a build you install yourself. TestFlight is Apple's app for installing test versions of an iPhone app before release, and a Google Play testing track does the same job on Android. A Google Play internal test can have "up to 100 testers per app" (Play Console Help). TestFlight also takes up to 100 internal testers, who are users of the App Store Connect account (App Store Connect Help), so if the Apple account is yours (check 5), you can be one of them. For outside testers, a team's first build has to be approved by App Review for TestFlight before invitations go out (Apple), so allow for that in the first week.

A pass: you install the build without the developer's help, and it does what the milestone promised. Screenshots, a screen recording or an app file sent over WhatsApp don't count, because none of them is how your users will get the app.

There's a technical reason too. A lesson from apps we've shipped: Google sign-in can work on the developer's own builds and break in the copy users get from Play, until Google's app signing fingerprint is added to Firebase. Google signs the store version with its own key, so "you must register the Google-held app signing key fingerprint with your API providers" (Play App Signing). The key on the developer's laptop isn't enough. Builds from a Play testing track are signed by Google too, like the store version, so a fault like that shows up while you're still testing.

Where we stand: every week there's a build to install through TestFlight or a Google Play testing track. We don't advertise a separate trial project. The written plan splits the work into milestones, so if you want the first one kept small, say so on the scope call.

5. Open the accounts in your name before any code

Open the Apple Developer Program and Google Play Console accounts yourself, create the code repository in your own account, then invite the developer as a user. A pass: they ask you for invitations. A fail: "we'll publish it under our account for now". If the relationship ends, an app in someone else's account needs their cooperation to move: on Google Play, the transfer request has to come from the account the app is in (Play Console Help).

Start early if the app will go out under a company name. Both stores want a D-U-N-S number for an organisation account, and Apple says to allow up to 5 business days to get one, then up to 2 more before you can enrol (Apple). Who should own your app's developer accounts has the setup order and the roles to give each person.

Where we stand: the app is published under your developer accounts with us invited as users, the code sits in a repository in your account, and the cloud projects are billed to you.

6. Pay someone independent to look at the code

After the first milestone, pay an independent developer for an hour or two to open the repository and answer three questions. Could another team build and release the app from the instructions in it? Are passwords and keys kept out of the code? Is there anything they'd be worried to inherit? You don't need to follow the detail. You need a plain answer from someone with no stake in the job.

A pass: the team is happy about it. A team that resists an outside look at code you're paying for has told you something.

Where we stand: the code is in your repository from the first push, so you don't need our permission. Two things a reviewer can check in the code we write: a bug fix usually comes with a test named after the bug it covers, and AI features are called through your own backend, so API keys don't ship inside the app.

7. Ask how they'll know the app works after launch

Ask what they watch once real people use the app. A good answer names a crash reporting tool and a number. Google's Android vitals sets a bad behaviour threshold of a 1.09% user-perceived crash rate across devices and 8% on any one phone model, and warns: "If your app or game exceeds a bad behavior threshold, Play may reduce the visibility of your title" (Android Developers). A team that has never looked at those numbers hasn't run an app for long.

Where we stand: analytics and crash reports go in before launch. We use Firebase Crashlytics for crash reports, and Play Console's Android vitals for the crash rate Google judges the app on.

8. Talk to people who hired them

Ask for two people who hired the team in the last year. Ask them whether the dates held, how changes were priced, and whether they would hire the team again.

Where we stand: we fail this one. Zoftaa is new and has no public clients, so there's nobody we can put you in touch with. If references matter most to you, that's a fair reason to choose someone else. If you'd still consider us, lean on checks 4 and 6.

When should you walk away?

Before you sign, if any of these happen:

• They want to publish your app from their own developer account.
• They want the whole amount up front.
• The price arrived before any written scope.
• The contract has no written assignment of the code to you. In the UK, "An assignment of copyright is not effective unless it is in writing signed by or on behalf of the assignor" (Copyright, Designs and Patents Act 1988, section 90). This is general information, not legal advice, so have a lawyer in your country read the contract.
• You won't see anything you can install until the end.

For the conversation before you sign, 15 questions to ask a software development company has a table you can email to every candidate.

When is this process too much?

For a small job. A single fix or one feature in an app that already works needs checks 1, 5 and 6, and little else.

If someone you trust can read code, they can do check 6 for you and join the call in check 3. Those are the two checks that need technical judgement.

The process has costs. The first milestone adds time before the main build starts, and you pay for it even if you walk away afterwards. That's the price of finding out early.

The checks also favour older firms. A new studio, us included, looks weak on checks 1, 2 and 8 even when its work is good, and an established firm can pass all three and still put a junior team on your app. Checks 4 and 6 test the work itself, so give them the most weight.

What we would do

If you aren't technical and need a whole app on both stores:

1. Write the brief and open the developer accounts this week.
2. Send the brief to 3 candidates and ask each for a written plan.
3. Run checks 1, 2 and 3 on all of them. It costs you a few searches and calls.
4. Pay the strongest one or two for a small first milestone, and install the result yourself.
5. Get the outside look at the code before you sign for the rest of the build.

If you're in the US and hiring a team in Asia, agree the call window before anything else. Ours puts US calls in your morning: 6pm to 10pm Pakistan time (PKT), Monday to Friday, which is 8am to 12pm in New York in winter and 9am to 1pm in summer. If you haven't tested whether anyone wants the app yet and money is tight, a landing page with a sign-up form comes before any developer.

A decision rule

Hire the team whose first build you installed yourself, from accounts in your name, and whose code an independent developer says another team could pick up. If more than one passes, choose the written plan that says most clearly what's out of scope.

To run these checks on us, send a few lines about your app through the contact page. An engineer usually replies within one business day. Every page cited here was checked on 1 November 2026.