How many people do you need to build an app? One, plus a pair of eyes that is not yours.
For a first version of an ordinary phone app, the answer is one person who can hold the whole thing, plus one other person willing to look at it honestly before strangers do. Headcount above that is bought with deadlines, money and risk, not demanded by the app. The useful move is to stop counting people and count jobs, then ask of each job whether a second person is required or merely convenient. The answer splits hard between a solo builder with no launch date and a team with a client, a contract and users already installed, which is why an agency app development quote lists roles you would never hire for yourself.
Below: the ten jobs an app actually needs, and which of them collapse into one person. Then the three reasons a job needs somebody else, the eight roles Apple has already named for you, and the only headcount either store insists on. Also what app development team size looks like once somebody else owns the launch date.
See who else you actually needThe short version
Count the jobs, not the people, then look for the jobs that need another pair of eyes, another clock or another signature.
An app needs about ten jobs done, from deciding what it does to answering the users who eventually arrive. Seven of them are one person's work in sequence. Three are not, and those three are the ones people get caught by.
Skill is not what forces a second person. Skill can be learned, rented by the hour, or handed to a tool, and that is the axis every app builder and every contractor competes on. What forces a second person is a job that needs a different pair of eyes, a different clock, or a different legal signature. So the honest count is one, plus one for each of those three you cannot cover yourself.
Ten jobs, and seven of them fit in one head
Write the jobs down before you write a headcount, because the job list is stable and headcounts are fashion. A phone app needs someone to decide what it does and refuse everything else. Someone to design the screens. Someone to write the app. Someone to run the server side, if accounts or shared data mean there has to be one. Someone to turn source code into a signed build that installs on a real device. Someone to test it the way a stranger uses it. Someone to hold the developer account: the agreements, the tax details, the privacy answers and the button marked Submit. Someone to answer users and reviews. Someone to tell anyone it exists. And someone to fix it next autumn when a new OS lands and a library stops building.
Seven of those ten are one person's work in sequence, not a team's work in parallel. Deciding and designing are the same conversation with yourself. Writing the app and writing its server side are the same afternoon when you own both sides of the wire. Builds and the yearly maintenance are chores with instructions attached, slow the first time and quick the third. Marketing is a genuinely different skill, but it is still your hours, and it cannot start before the app exists.
None of those seven need a second person to be possible. They need a second person to be faster. That is a good reason to hire and a bad reason to think you cannot start. Whether it holds for your project is the question behind can one person build a mobile app, and the answer there turns on the kind of app more than on the person.
The three left over are testing, answering users, and holding the account. They are different in kind, not in size. Two of them never collapse into the builder at all. The third, the account, collapses only when the builder and the owner are the same person, which is exactly why it catches contractors out.
Three reasons a job needs somebody else, and skill is not one of them
The first reason is eyes. You cannot be surprised by your own app. You know which button to press and in what order, and your fingers route around the bug without reporting it. Testing your own work finds typos and misses the thing that makes a stranger close the app in the first four seconds. One other person, one hour, one build, no instructions, beats another week of your own clicking.
The second reason is the clock. Support mail, review replies, a crash at two in the morning and a platform email with a date on it all arrive on somebody else's schedule. One person there is not a capacity problem, it is a single point of failure in time. A week away from your desk is a week of unanswered one-star reviews, and no amount of skill covers it. Only a second person in another timezone fixes that, or expectations you lower on purpose and write down.
The third reason is a signature. Developer accounts, agreements, tax details and the identity checks behind them attach to one legal person or one company. That is a role, not a task, and if you are not that person you cannot complete it however much of the app you wrote. Everything else on the list is skill, and skill is the cheap axis now: learn it, rent it by the hour, or hand it to a tool. Which of those you pick is the real content of build an app or hire a developer, and it moves the bill far more than it moves the headcount.
So the working count is one builder, plus one person for each of the three tests you cannot personally pass. For most side projects that comes out at two, and the second person does about an hour a week.
Try it
Who else do you actually need
Tick what is true of your project. Anything you leave unticked is a job one person can hold.
1 on the team, plus one pair of eyes
One builder holds every job on the list. The extra pair of eyes is the one job that cannot be done by the person who wrote the thing.
Apple already wrote the job list down, and one entry is not a skill
If you want an outside opinion on which roles are needed for an app, use the one a platform enforces rather than the one an agency quotes. App Store Connect defines eight: Account Holder, Admin, Finance, App Manager, Developer, Marketing, Sales and Customer Support. That is not advice about team structure. It is the set of permissions Apple thinks somebody has to hold for an app to exist on the store. One person can hold all eight at once, and on a solo project one person does.
One of the eight is not a skill at all. Apple's reference says the person who completes program enrollment becomes the Account Holder, and that this is "the only user that can sign legal agreements". The same role renews the membership and requests App Store Connect API access. Apple sets ceilings on people rather than floors: internal testers have to be App Store Connect users on your team and cap out at 100, external TestFlight testers go up to 10,000, and there is no minimum anywhere.
One rule is worth reading before you assume a contractor can submit the app for you. App Review Guideline 4.2.6 covers apps made from a commercialized template or an app generation service, and says they are rejected unless they are "submitted directly by the provider of the app's content". Read plainly, the owner of the app does the submitting. It says nothing about how the code was written, so it is not a ban on generated or AI-assisted apps, though it gets quoted that way. It is a rule about whose account and whose signature.
What each of these roles costs, once you pay for one rather than hold it, is a separate calculation from how many you need. That is the edge of this page: what each person costs is where the rates live.
The only headcount a store actually requires is twelve
Here is the number that surprises people on this question, and it comes from Google rather than from any team-size convention. Google Play requires personal developer accounts created after 13 November 2023 to run a closed test before an app is eligible for production. To apply for production access, at least 12 testers must have been opted in to that closed test continuously for the preceding 14 days. Twelve people, two weeks, before the listing can be public.
Those twelve are not your team. They are twelve humans with Android phones who agree to install a half-finished app and stay opted in while you fix it. Recruiting them is a job of its own, and no tool absorbs it, because the requirement is other people by design. The help page names personal accounts created after that date and says nothing about organisation accounts, so check your own console rather than planning around an exemption nobody wrote down.
The App Store has no equivalent minimum. You can ship an iOS app with zero testers, which is not the same as saying you should. So the real floor is twelve testers for a new personal Play account, one signature for either store, and one more person who is not you if you want the thing to be any good. Every other number on this page is a choice about speed.
Google Play Console Help: app testing requirements for new personal developer accounts
Which jobs collapse into one person and which do not
| The job | One person can hold it | What would force a second person | What it looks like when nobody does it |
|---|---|---|---|
| Deciding what it does | Yes | nothing, decisions do not split | a version one that keeps growing |
| Designing and building it | Yes | a launch date you did not set | there is no app, only a document |
| Testing it as a stranger | No | you cannot be surprised by your own app | your first users find the crash |
| Support, reviews, the on-call clock | No | users arrive on their schedule, not yours | a week away leaves reviews unanswered |
| Signing and submitting | only if you own the account | the store binds it to one legal person | you cannot publish at all |
What a builder removes from the count, and what it leaves
The jobs a tool removes are the skill jobs. That is worth saying precisely, because the marketing around app builders implies they remove the team. They remove the part of the team you were hiring for typing speed. The eyes, the clock and the signature are still yours to staff.
Newly is an AI app builder: you describe an app in plain English and it writes a real React Native and TypeScript project you own. It runs the app on cloud iOS and Android simulators while it builds, uploads to App Store Connect and TestFlight, and publishes to Google Play internal testing, with a standalone production APK as a separate build. It is $25 a month and there is no free plan. New apps start local-first, keeping their data on the phone with no accounts and no server, and the agent adds a backend only when the app needs sign-in, shared data, syncing or payments. It does not submit for review. You press that yourself, from the account with your name on it, which is the third test refusing to go away.
So on a one person project a builder covers deciding, designing, writing and getting a build onto a test track. It does not cover the stranger who tests it, the person who answers reviews while you sleep, or the signature on the developer agreement. Staff those three and your team is one, two or three people.
Questions people ask about team size
One, for the building, if that person can decide, design, write and ship. Plan on a second person to test it as a stranger would, because that job cannot be done by whoever wrote it. Add a third only when something outside the app forces it: a launch date someone else set, rules you have to read carefully, users who would notice a bad release, or a company signature that is not yours to give.
Write the job list before you write the headcount
List the ten jobs for your own app, mark the ones you can hold, and name a real person for eyes, clock and signature. Then build version one and find out which line on the list actually cost you something.
Start building