The plan is real. Fourteen pages in a Google Doc, forty-one rows in a spreadsheet, screens sketched in Canva, a name you already checked on Instagram. You can pitch the whole thing in ninety seconds. Then you started asking what it would cost, and the answers came back at $8,000, $45,000 and $210,000, two people went quiet after the first call, and one asked something about “the backend” you could not answer.

So you posted the sensible version: you are not a developer, the app idea is fully planned out, how do you find someone to build it?

Direct answer first. Your first job is not finding a developer. It is closing the gap between “fully planned out” and “buildable”, because “fully planned out” almost always means the features are decided and nothing else is. Four things are usually still open: what happens on a server rather than on the phone, who pays for that server every month, what the app stores will and will not accept, and what version one actually has to contain. Those four set your price and decide whether the thing ships.

An app is three things, and two of them bill you every month

Non-technical owners picture one object: the thing on the phone. A quote covers three.

The app itself. What installs on the device. Screens, buttons, the camera, what you sketched.

The backend and database. Anywhere the app must know something that is not already on that one phone, a server has to hold it. Accounts. Other people’s posts. A booking a second person can see. Payments. Push notifications sent while the app was closed. And admin screens, so you can moderate, refund or fix a customer’s record at 9pm without phoning your developer. Admin screens are missing from nearly every first quote and are the most common surprise invoice in app projects.

The accounts and infrastructure. Apple and Google developer accounts, a cloud project, a payment gateway, transactional email, SMS for login codes, maps, crash reporting, analytics. Not one-off purchases. A monthly bill with your card on it.

This is how one feature list produces an $8,000 quote and a $70,000 quote. The cheap one priced the first box and assumed the phone stores everything. Test it with one question: “If I install this and my customer installs it, what makes her see what I did?” A vague answer means you are being quoted for a different product.

The exercise worth more than any hire: turn your app idea into one loop

Do this before you speak to another developer. It takes an afternoon and routinely halves a first build.

One. Write a single sentence in this shape: “A [specific person] opens the app to [do one specific thing], and keeps it because [specific outcome].” Not “connect people”. A dog walker opens the app to confirm tomorrow’s three walks, and keeps it because she stopped losing bookings in WhatsApp.

Two. Put every feature on its own line. All forty-one. For each one ask: if this did not exist at all, could that sentence still happen? If yes, it is version two. Profile photos, badges, in-app chat, dark mode, referral codes, an activity feed, filters, a second user type. Nearly always yes.

Three. For each survivor, ask whose data it needs besides this user’s own. Anything touching other people’s data needs a backend, usually a moderation plan and a privacy disclosure. That is where money goes.

Four, the step people skip. What does the app do for user number one, on the day nobody else is on it? Marketplaces and community apps have an empty-room problem development cannot solve. If the answer is “nothing until hundreds join”, version one must be useful to one lonely user, or you need a plan to fill one side by hand.

You are finished when you can describe the build in five spoken sentences. Hire against those. The rest goes in a file called “later”.

What the app stores actually require, and what gets apps rejected

This is the part a first-timer cannot know, and it moves the price. All of it comes from Apple’s and Google’s own published rules.

Developer accounts, one of which renews annually. The Apple Developer Program is a $99 annual membership, enrolling as an individual or an organisation. A Google Play developer account carries a US$25 one-time registration fee, and Google says it may ask for “a valid government ID and a credit card, both under your legal name.”

New personal Play accounts must run a closed test first. For personal accounts created after 13 November 2023, Google requires “a minimum of 12 testers who have been opted in continuously for at least 14 days” before you can apply for production access. Put that fortnight in your launch schedule.

Then review, which is a person saying no. The clauses that catch first apps:

• Minimum functionality (Apple 4.2). “Your app should include features, content, and UI that elevate it beyond a repackaged website.” A wrapper around your existing site is the classic rejection. Under 2.1, submissions must also be “final versions with all necessary metadata and fully functional URLs included”, so placeholder text and a dead support link will bounce you.
• Login services (4.8). If accounts are created through a third-party or social login such as Facebook or Google Sign-In, you must also offer an equivalent option that limits collection to name and email, lets users keep their email private, and does not track in-app behaviour for advertising without consent. Budget for two sign-in methods.
• Account deletion (5.1.1(v)). “If your app supports account creation, you must also offer account deletion within the app.” Google requires both an in-app path and “a web link resource where users can request app account deletion”. Two pieces of work, plus a real deletion process on your server.
• Paying for digital things (3.1.1). To unlock features, subscriptions or premium content inside the app, Apple’s rule is that “you must use in-app purchase”. So the store takes a cut: Apple’s Small Business Program sets 15% for developers with up to 1 million USD in proceeds the prior calendar year, and Google Play publishes 15% on a developer’s first $1M of annual revenue, 30% above, subscriptions at 15%. Price that in before you set your prices.
• Privacy disclosure. Apple requires privacy information “to submit new apps and app updates to the App Store”, covering “analytics tools, advertising networks, third-party SDKs, or other external vendors whose code you’ve added to your app.” Google’s Data safety form is the equivalent, and non-compliant apps face “blocked updates or removal from Google Play.” So you need a written list of every third-party service your developer bolted in. Make it a deliverable.

There is also a treadmill nobody quotes for. From 31 August 2026, new apps and updates on Google Play must target Android 16 (API level 36), and apps targeting Android 14 or lower are only available on devices running the same or lower Android version, so new users on new phones cannot find them. An app you never change still needs paid work each year.

Native, cross-platform, or no app at all

You will be offered a technology choice. Judge it by consequences, not preference.

Two native apps (Swift for iOS, Kotlin for Android) means two codebases and the highest cost, in exchange for the best access to camera, sensors and background behaviour. Right when the app is the business and the hardware features are the point. Cross-platform (React Native or Flutter) means one codebase producing both apps, and for an app made of lists, forms, accounts, payments and notifications it is usually correct for version one; it is what I would default to on a fixed budget. The consequences to accept: you depend on that framework keeping pace with OS changes, some device-level work still needs a native specialist, and genuinely senior people in it are rarer than the CVs suggest.

A mobile web app means a website that works beautifully on a phone. No store, no review, no annual fee, no install. Which leads to the question nobody asks the person with the idea: a great many app ideas do not need an app. If your users visit occasionally, arrive from a link, and never need the camera, offline use or push notifications, a website is faster to build, cheaper to change, and ships on a Tuesday without anyone’s permission. You need a real app for push notifications people act on, offline use, hardware access, or daily habitual use where a home-screen icon matters. If the only reason you want one is that investors or your own pride expect it, build the web version first.

What version one costs to build, and what it costs to run

I will not price your app from a paragraph, and neither should anyone else. Here is the arithmetic to do with the quotes you have.

Ask every candidate to quote in hours by area: design, the app itself, backend and database, admin panel, store submission, and a stabilisation window after launch. In my experience a disciplined version one, the five-sentence kind, lands around 400 to 900 developer hours once the backend and admin screens are counted. That is a rule of thumb from doing the work, not a survey figure. Multiply by each candidate’s own hourly rate and compare with their quote. A quote implying 120 hours for accounts, payments and two platforms is a smaller project nobody has described to you yet.

Then build the running cost on one page:

• Store accounts: $99 a year to Apple, $25 once to Google.
• Backend and database. Free tiers are generous at the start. Firebase’s no-cost Spark plan publishes Cloud Firestore limits of 1 GiB storage, 50,000 reads and 20,000 writes a day, and 50,000 monthly active users on Authentication. Above that you pay per read, per write and per gigabyte, so hosting scales with success rather than time. Ask your developer to estimate reads and writes per user per day, then multiply by your own forecast. If they cannot, they have not thought about running costs.
• Third-party services. Transactional email, SMS codes (priced per message, and signup flows burn through them), maps, error monitoring, paid SDKs.
• Maintenance. OS releases, Android target-level rules, framework upgrades, expiring certificates, security patches. Buy a retainer or a block of hours per quarter, or buy an emergency later.

Founders are rarely broken by the build price. They are broken by learning in month five that the thing costs $600 a month to keep alive, support included, and nobody planned for it.

Own the accounts, or you don’t own the app

App projects have ownership traps website projects do not. Settle each of these in writing before money moves.

• The Apple Developer Program enrolment in your company’s name, on your card, with you as Account Holder. Published under an agency’s account, your app sits inside their organisation, your ratings attach to their listing, and moving it later needs their cooperation at the exact moment they may be least willing.
• Google Play Console the same. Its verification asks for government ID and a card in the account holder’s legal name, so whoever set it up is the verified identity behind your app.
• Signing keys and certificates. Android updates must be signed with the same key as the original release, and iOS distribution needs your certificates. If those live only on a contractor’s laptop, your ability to update your existing users depends on their goodwill.
• Code in a repository you own from day one, developer added as a member. Not a zip file at the end.
• Cloud and third-party accounts under your billing. Firebase or AWS, payment gateway, email, SMS, analytics. They get access, you get ownership.
• Written IP assignment covering everyone who touched it, subcontractors included, present tense, surviving termination. Plus the third-party service list and editable design files.

Writing a brief, and judging a developer when you can’t read code

A quotable brief is about two pages. Specify the what and the constraints; leave the how to them.

Specify: the one-sentence loop; the five sentences of version one; who the users are and how many in year one; what must live on the server rather than the phone; whether you take money and for what; which platforms and why; budget range and real deadline; the ownership list above; and what done looks like in things you can personally test. That last item matters more than the feature list. “A dog walker with no training confirms tomorrow’s three walks in under thirty seconds on an iPhone, and the customer gets a text” is an acceptance test. “Booking module” is a hope. Leave language, framework, database, hosting and architecture to them; specifying those buys obedience instead of judgement.

Now the evaluation problem. Ask for an explanation of a tradeoff and judge the explanation, not the answer:

“My users will upload photos. We could keep them on the phone or on a server. Explain both as if I have no technical background, tell me which you would pick for version one, and tell me what each costs me per month at a thousand users.”

Strong answers contain a cost, a consequence, and a named downside of their own recommendation, and they often end with a question back to you, because the right choice depends on something you have not said. Weak answers are confident, one-sided, jargon-heavy and silent about money. You do not need to know the correct answer to grade it, which is the whole point.

One more worth its weight: “walk me through what happens when Apple rejects the first submission.” Anyone who has shipped apps answers calmly, cites guidelines, and treats rejection as a normal Tuesday. Anyone who looks startled has not shipped one. Then buy a small piece of paid work before the big commitment, at their normal rate, over a week or two, and judge whether they ask good questions and answer without being chased.

Questions people ask next

Can I find a technical cofounder and pay in equity? Occasionally, and rarely the way it is imagined. From their side the offer is unpaid work of unknown duration for a slice of something with no users, and the people who could build your app well have the best paid alternatives. It works when there is a real relationship first, when the person genuinely shapes the product rather than taking tickets, and when the split and vesting are documented before any code exists. Wanting a cofounder because you cannot afford a developer is not a partnership. It is a discount you are asking a stranger to fund.

Where do I actually look for mobile developers? In rough order of hit rate: other founders who have shipped an app in your sector, because they watched the whole engagement rather than the portfolio; the stores themselves, since an app you admire names its seller, and small agencies are findable from there; platform-specific communities and local iOS or Android meetups, where the good people are visible to each other; and freelance marketplaces last, which work fine provided you run the small paid trial rather than hiring off a profile. The channel that performs worst is the one that finds you: cold agency outreach promising an app for a suspiciously round number.

What if someone quotes four weeks and $6,000? Believe the hours, not the price. Ask what happens on the server, who builds the admin panel, who handles submission and rejections, what is excluded, and what it costs to run monthly. Usually they are building far less than you described, recovering the rest through change requests, or they misread the brief.

If it would help to have someone technical on your side of the table rather than only the other one, that is the part AB7 Solutions plays: reading a scope and its ownership terms before you sign, turning a feature document into a version one that can be priced, or supplying named mobile and backend engineers who work in your repository and your cloud accounts. We build applications and APIs outright where that fits better, and we will say plainly if your idea should be a mobile website this year. Call +1 321 341 7733, email ab@ab7solutions.com or director@ab7solutions.com, or start at www.ab7solutions.com.

Sources: Apple, App Store Review Guidelines (2.1, 3.1.1, 4.2, 4.8, 5.1.1); Apple Developer Program; App Privacy Details; App Store Small Business Program; Google Play Console Help on developer accounts, testing requirements for personal accounts, account deletion, Data safety, service fees and target API levels; Firebase pricing.