Hiring an App Development Company for Your Startup: What to Check Before You Sign
How a startup checks an app development company before signing: verify the portfolio on the store, ask the scope questions, and recognise the red flags.
Updated 9 min read
On this page
The expensive part of choosing the wrong app development company is not the invoice. It is the four months you spend finding out. Money you can raise again; the round of user feedback that build was supposed to buy is simply gone, and you usually discover the problem in the week the demo is due.
Which is why a "top 10 app development companies" list is close to useless at the moment you are the one signing. A position on a list is a claim, published by someone with a commercial relationship to the companies on it. What a founder needs is not another stranger's shortlist — it is a way to check the one already in the inbox: what to verify, what to ask, and what should end the conversation.
Rankings are claims. Store listings are records.#
Most directories that rank agencies have a "get listed" page of their own. Read it on any list you are relying on: it will tell you whether profiles are paid, whether placement is sponsored, and what the review really consists of. Sometimes that is reassuring. Sometimes the ranking you were about to trust turns out to be a rate card.
The public app stores work differently — neither Apple nor Google is selling an agency a better position in your evaluation. A listing tells you the app exists, that it passed review, when it was last updated and how many people rated it. Ratings can be gamed; a live, maintained app with a real review history is much harder to fake, and takes a minute to check.
What each source can actually tell you
| A place on a "top companies" list | The store listing | |
|---|---|---|
| Who publishes it | The directory, which usually sells placement or profiles | Apple or Google |
| What it proves | That a profile was submitted and accepted | That the app is real, passed review and is live |
| Can you verify it yourself | Rarely — the criteria are seldom published | Yes, in a browser, in a minute |
| What it says about your project | Nothing specific to you | The closest thing to an inspectable work sample |
Verify the portfolio before the first call#
Ask for links, not screenshots. A screenshot in a deck proves a design file existed. A store URL proves an app shipped. For each app a company claims:
- Open it. Delisted apps return a dead page. Worth knowing before the call, not after.
- Check the update history. The "What's New" section carries dates. An app last touched three years ago was shipped, not maintained — a different promise from the one you are buying.
- Read the rating count, not just the rating. A 5.0 average from six ratings tells you nothing. A 4.2 from several thousand means the app has been in real hands.
- Look at who the seller is. Client apps often sit under the client's own developer account, which is exactly how it should be — so their name, not the agency's, appears on the listing.
That last point cuts both ways. A studio may genuinely be unable to link half its work because of NDAs and client accounts — fine, then ask what it can show: apps it published itself, or a past client willing to take a fifteen-minute call. A short public list is not the worry. No verifiable app anywhere, and no explanation for it, is.
How to run the evaluation#
- Verify the portfolio — collect store links for every claimed app, open each one, check it is live, recently updated and carrying a believable number of ratings.
- Send everyone the same one-page brief — the problem, the first user, the one thing version one must do, your deadline. Different briefs produce quotes you cannot compare.
- Ask the scope questions — what is in version one, and what they would cut. The cuts tell you whether they read the brief.
- Ask the process questions — who you speak to each week, and where the code lives while it is being written.
- Ask about the fortnight after launch — crash monitoring, store review responses, the hotfix path. This is where an "on budget" project turns expensive.
- Read the contract for ownership — code, repository, design files, store accounts, and when each transfers.
The questions worth asking, and the answers worth hearing#
"What is in version one, and what would you cut?" A studio that has read your brief can name the two features it would drop and say why. One that answers "everything you listed" is either not reading or not planning to argue with you later, and both cost you the same.
"Whose developer account does the app ship from?" For a startup, the right answer is yours. Apps can be transferred between accounts afterwards, but that is paperwork you do not need; starting on your own account costs nothing.
"Who owns the code, and when do I get it?" You want the repository from day one, not at handover. Weekly commits into a repository you own are the only progress report that cannot be dressed up.
"Who will I actually talk to each week?" You want a name, not a role — and ask what happens when you have a question that person cannot answer.
"What do you know about App Review that has bitten you?" Anyone who has shipped a few apps has been rejected and can tell the story. Apple publishes its App Review Guidelines openly, so this is no trick question — it separates the studios that have stood in the queue from the ones that have not.
What changes because you are a startup#
An enterprise buyer optimises for certainty. A startup optimises for the number of learning cycles it can afford before the runway ends — and that changes what a good hire looks like.
Keep version one small on purpose. The first release exists to find out whether anyone wants this; everything that is not the one thing your first user came for is version two. Scope is also the biggest lever on cost, which we covered separately in what actually drives the cost of a mobile app.
Pick one platform unless you can say why not. Two stores means two review queues and roughly double the testing surface, even with a shared codebase.
Treat calendar time as the real budget. A six-month first build is not merely more expensive than a six-week one; it is five extra months of not knowing. If you are still weighing an agency against a freelancer or a contract team, those trade-offs sit in what it costs to hire an app developer.
We put ourselves through the same check#
It would be poor form to publish a verification test we would not pass ourselves. These are the three apps we have built, read straight off their public App Store listings:
Each is one link away, with the US storefront beside the Turkish one: Glamour — Color Analysis & Glow Up holds 4.4 from 72 ratings in the US, HairMaxx — AI Hair Style & Care 4.6 from 48, and Tattoo Genie — AI Designer 4.1 from 29. Rating counts are kept per storefront, which is why the Turkish and US figures differ so much — these apps found their first audience in Turkey.
There are no revenue numbers here, and no ranking badge either. Both would be self-reported, and self-reported figures have no business next to ones you can check yourself in a browser.
Frequently asked questions#
How do I check an app development company's portfolio?
Ask for store links rather than screenshots, then open each one. You are checking four things: that the app is still live, when it was last updated, how many ratings it carries rather than just the average, and who the listed seller is.
Client apps often sit under the client's own developer account, so a short public list is not automatically a bad sign. No verifiable app anywhere — and no explanation for it — is.
Are "top app development companies" lists worth using?
They are fine for building a longlist and poor for making a decision. A ranking is a claim published by a directory, and most directories have a "get listed" page that will tell you whether placement is paid or sponsored. Read that page before you weight the ranking, then verify the companies yourself on the store.
What should a startup ask before signing with an app development company?
What version one contains and what they would cut; whose developer account the app ships from; who owns the code and when you get the repository; who you speak to each week; and what happens in the fortnight after launch.
Ask all of it before anyone talks about a number. A quote produced from a one-paragraph brief is a guess, and the guess gets corrected later through scope changes.
Who should own the App Store account and the code?
You should, from the start. Apps can be transferred between developer accounts afterwards, but that is avoidable paperwork, and beginning on your own account costs nothing. The same applies to the repository — you want it from day one, not at handover.
