Home InsightsSoftware Development

Software Development

How to Choose an App Development Company Without Regretting It

Choose on how the company behaves before you sign, not on its portfolio. A good app development company asks whether you need an app at all, puts the backend in the quote, lets you install test builds during the work, registers the store accounts in your name, and agrees the source code handover in writing.

Prabhu SolutionsPublished 8 October 2026Last reviewed 8 October 20269 min read

On this page

How do you choose an app development company?
What should you decide before you speak to an app development company?
What should you ask an app development company, and what does a good answer sound like?
Why does the backend matter more than the screens?
How do you make sure you own your app store accounts?
What should the source code handover include?
What should a maintenance agreement for an app cover?
How do you judge an app developer's portfolio and references?
Should an app be built by an agency, a freelancer or an in-house hire?
What are the warning signs when choosing an app development company?
When is hiring an app development company the wrong step?
How would we answer these questions ourselves?

How do you choose an app development company?

A portfolio shows what a company has made. It does not show who owns it, what it costs to keep running, or how the company behaves when a deadline slips. Those are the things that decide whether you are glad of your choice in two years' time, and they come out in the questions you ask rather than the screenshots you are shown.

An app is a product, not a project. The build is the smaller half of the commitment: mobile app development also means operating system updates, store rules that change, a server that has to keep running and users who cannot log in. What follows is the checklist we would use if we were the buyer, and it works whoever you end up hiring.

The point
What follows is the checklist we would use if we were the buyer, and it works whoever you end up hiring.

What should you decide before you speak to an app development company?

Decide seven things before the first call: the job the app does, who uses it, which platforms matter, what it must connect to, what the first release leaves out, who in your business will own it afterwards, and what you can afford to run as well as build. A company can only quote sensibly against a brief that answers those.

The job. One sentence that says what a user can do with the app that they cannot do today. If it takes a paragraph, the first release is probably too big.
The users. Customers, staff or partners, and how many kinds. Each kind of user means another set of permissions, screens and support requests.
The platforms. iOS, Android or both, and why. Native or cross-platform is a decision your developer should explain; you should arrive with the audience, not the technology.
The connections. Your CRM, stock system, accounts package or booking platform. Find out whether each has an API before anyone quotes, because integration is where estimates most often come apart. Where the system you need does not exist yet, a custom CRM may be the real first project.
What the first release leaves out. A written list of what is deliberately not in version one is the best protection against a quote that grows. A minimum viable product is a way of finding out whether people want the thing before you build the rest of it.
The owner. One named person in your business who decides, answers questions the same week and will still care after launch. Apps without an owner drift.
The ceiling. What you can sustain, build and running costs together. What an app costs to build in the UK lists what drives the figure, so you can describe your limit in the same terms the quotes will use.

What should you ask an app development company, and what does a good answer sound like?

Ask these eight questions in writing and compare the answers side by side. A good answer is specific and slightly inconvenient for the supplier; a poor one is a reassurance. The warning signs are set against each question, because a vague answer to any one of them is usually the part of the project that goes wrong later.

Question	A good answer	A warning sign
Do I need an app at all?	They ask what the users are trying to do, and say so if a responsive website or progressive web app would serve. They build more than one kind of thing, so the advice is not shaped by what they sell.	The answer is yes before they have asked a single question.
Is the backend in the quote?	The quote lists accounts, data storage, the API, the admin dashboard and each integration, and says which are in phase one. It is the same discipline as any bespoke software build.	A price for screens only, with the server mentioned as a detail for later.
Who will be account holder on the Apple and Google accounts?	Your company, with a named person at your end. The developer works as a team member.	They will set it up under their own account and transfer it later.
Can I install a build on my own phone during the project?	Yes, at regular intervals, through Apple's TestFlight and Google Play internal testing.	Progress is shown as screenshots, recordings or a demo on their laptop.
What do I receive at the end?	The repository with its history, the backend, designs, credentials, documentation and signing keys, all listed in the contract.	You receive the finished app, and the code arrives later or on request.
What are the running costs after launch?	Developer programme fees, hosting, messaging services and maintenance, itemised as recurring costs with who pays each.	Running costs are missing from the proposal, or described as minimal.
What happens when iOS or Android changes something?	A named maintenance arrangement, with what it covers and what is billed separately.	Nothing is said; the app is treated as finished at launch.
Who will actually do the work, and can I speak to them?	Named people, a conversation with the engineers, and a clear answer on anything subcontracted.	You only ever speak to a salesperson or an account manager.

Why does the backend matter more than the screens?

The backend is often more than half the work and is the part most often left out of a quote. The app is a window; the backend is the building behind it, holding accounts and data, applying your business rules, sending notifications and connecting to your other systems. A quote that prices only the screens has not priced the app.

Ask what the backend is written in, where it is hosted and whose account the hosting sits in. If it runs inside the developer's own cloud account, your data is in their hands and moving it later becomes a migration project. It should sit in accounts registered to your company, exactly as the store accounts should.

Ask about the admin dashboard too. Your team needs somewhere to manage users, content, orders and support without a developer running database queries, and it is routinely forgotten until late in the project. If the app will serve many organisations from one system, you are describing a SaaS product rather than a single-company app, and the decisions about separating customers' data and handling billing change the scope.

The backend is ordinary bespoke software, so what bespoke software costs applies to it as it would to any other system. A company that cannot scope it cleanly is guessing.

The point
The backend is ordinary bespoke software, so what bespoke software costs applies to it as it would to any other system.

How do you make sure you own your app store accounts?

Enrol the Apple Developer and Google Play accounts under your own company, with a named person at your company as account holder, and have the developer work as a team member. Moving a published app between accounts is possible but conditional, so starting in your name is far cheaper than fixing it later.

Enrol the company, not the agency. Apple accepts organisations only as legal entities, not trade names or branches, and asks for a D-U-N-S number, which Dun & Bradstreet issues. Google Play asks organisation accounts for one too. Apple also needs the person enrolling to have authority to bind the company, so the process has to start at your end.
Make the developer a team member. They need access to upload builds and manage testing. They do not need to be the account holder, and removing a team member later is one setting rather than a negotiation.
Check the payment and tax details. The bank, tax and agreement information in each store belongs to the account holder. If revenue will ever flow through a store, it must flow to you.
Know where the signing keys are. With Play App Signing, Google holds the app signing key and you keep an upload key, which Google can reset if it is lost. An app that manages its own signing key has no such safety net: a lost key cannot be reset. Ask which arrangement applies and who holds the keys.
Put the listing on your own domain. Support and privacy policy addresses should sit on a domain you control, such as your own website, so that changing supplier does not break the listing. Apple requires a privacy policy link for every app.
Understand what a transfer involves, in case you inherit a problem. Apple has a formal app transfer process: the current account holder starts it and the receiving account holder accepts it. The app keeps its reviews, ratings and bundle ID, but conditions apply, such as switching off TestFlight testing first, and some things do not travel, including Apple Pay merchant IDs, while push notification credentials eventually have to be recreated.

What should the source code handover include?

Everything needed to ship the next release without the original developer: the repository with its full history for the app and the backend, the database and a data export, credentials, API documentation, build and release instructions, designs and the signing keys. Agree the list in the contract at the start, not at the end.

The repository, with history. Both the app and the backend, with the commit history rather than a zip of the current files. The history shows why decisions were made.
The database schema and a full export, so the backend can be stood up elsewhere with real records in it.
Credentials and environment settings. The keys and accounts for email, SMS, analytics, crash reporting, maps and file storage, each listed with what it is for and who pays for it.
API documentation. Endpoints, authentication, versioning and webhook payloads. An app talking to an undocumented backend is two problems rather than one.
Build and release instructions. How to produce a signed release for each store, and how a backend change reaches production. If only one person can do it, you have a dependency, not a handover. It is one reason the choice between a freelancer, an agency or an in-house hire matters so much.
Design files and assets. Screens, icons and fonts, in editable form, with the licences for anything bought in.
A list of third-party components. The open-source and commercial libraries used, because their licence terms travel with your app.
Ownership in the contract. Intellectual property in the code should pass to you on payment, with third-party and open-source components excluded and listed. Have a solicitor read the clause; this is not legal advice.

What should a maintenance agreement for an app cover?

A maintenance agreement should cover operating system updates, store rule changes, library updates, backend hosting, monitoring and expiring credentials, and say what is included and what is billed separately. Apps that are not maintained break on new devices and, on Google Play, can stop being offered to new users on newer Android versions.

Task	Why it keeps coming back	What to ask the agreement to say
Operating system updates	iOS and Android both ship major updates each year, and behaviour the app relied on can change.	Whether testing against new releases is included, and who decides when to ship a fix.
Store requirements	Google Play requires apps to target a recent Android API level, and apps that fall behind are not offered to new users on newer Android versions. Apple requires in-app account deletion for apps that let people create accounts.	Who watches store policy changes, and how you are told about them.
Libraries and frameworks	React Native and the packages around it release updates, security fixes among them.	How often dependencies are reviewed, and whether upgrades are in the fee.
Backend and hosting	The server needs patching, monitoring and capacity changes as usage grows, the same discipline as website maintenance.	Whose account hosts it, who responds when it fails, and what counts as an emergency.
Certificates and keys	Push credentials and signing certificates carry expiry dates.	Who tracks the dates, and where the renewals are recorded.
Monitoring and support	Crash reports and analytics show what real devices do, and real people still cannot log in.	Who sees the crash reports, and who answers the users.

How do you judge an app developer's portfolio and references?

Find the apps in the stores, install them and read the update history. A live app with recent updates and ordinary reviews tells you more than a case study page. Then ask the company what its part in each one was, and ask to speak to the client. Screenshots and prototypes prove only that someone drew screens.

Look at what you can check without the company's help: the date of the last update, how the developer replies to reviews, whether the app survives its first launch, whether the privacy policy loads. UK companies are listed on Companies House, with their officers and filed accounts, so you can confirm that the legal entity you will sign with exists and who stands behind it.

References are most useful when the questions are specific. Was the quote the final price? Who handled the store submission? What happened when something broke after launch? Did the code arrive when promised? A reference who says only that the team was lovely has told you very little. Our own record is in the projects we have delivered, and the same standard applies to us: ask what each one involved.

The point
A reference who says only that the team was lovely has told you very little.

Should an app be built by an agency, a freelancer or an in-house hire?

An agency suits an app that needs design, backend, testing and store work together; a freelancer suits a smaller, well-defined build that one person can carry; an in-house hire suits a product you expect to develop continuously for years. The trade-off is continuity against breadth, and each option has its own failure mode.

Option	Suits	Watch for
Freelancer	A well-defined build where one person can cover app and backend, and you can accept a single point of failure.	Who covers illness or holidays, who tests on real devices, and whether the code and keys are handed over in a form somebody else could use.
Agency	An app that needs design, backend, testing and store submission together, with more than one person who knows the code.	Whether the people you meet are the people who build, what is subcontracted, and the handover terms. The wider trade-off is in freelancer, agency or in-house.
In-house hire	A product you expect to develop for years, where the knowledge should live inside the business.	The cost and delay of hiring before anything is built, the risk of one person leaving, and buying design and testing separately.

What are the warning signs when choosing an app development company?

The warning signs are a firm price before any questions, a quote that omits the backend, store accounts held in the developer's name, progress shown only as screenshots, no mention of running costs, and reluctance to say what you will receive. Any one is worth a direct question; two or more is a reason to look elsewhere.

A fixed price and date offered after one conversation. Nobody can price a backend, integrations and offline behaviour they have not asked about.
Nobody asks whether you need an app. A company that builds only native apps will tell you that you need a native app.
The app is a wrapper around your website. Apple's review guidelines say an app should include features, content and UI that go beyond a repackaged website, so a thin wrapper risks rejection as well as being poor value.
Store accounts in the developer's name, with a promise to transfer them later.
Progress shown as screenshots. An installable build is the only reliable progress report.
Running costs left out, or described as negligible. Developer fees, hosting, messaging and maintenance all recur.
Reluctance to say what you will receive. Ownership on final payment is normal; a refusal to list what is handed over is not.
Pressure to sign quickly. A discount that expires on Friday is a sales tactic, not a project requirement.

When is hiring an app development company the wrong step?

It is the wrong step when the problem does not need an app, when nobody in your business will own the product afterwards, or when the budget covers the build but not the running. A responsive website, a progressive web app or a better internal process can serve the same users at a fraction of the commitment.

Be honest about where the use will happen. If staff or customers will mostly open it on a laptop, a browser-based application avoids store review, two codebases and release delays. If it is essentially a website with a login, a well-built responsive website may be the whole answer.

And be honest about validation. If you do not yet know whether people will use the thing, build the smallest version that tests it, perhaps a clickable prototype or a progressive web app, before commissioning a full native build. A company that would sooner sell you the large invoice than the small test is telling you something about itself.

The point
A company that would sooner sell you the large invoice than the small test is telling you something about itself.

How would we answer these questions ourselves?

We would answer them the way our mobile app work is set up: ask first whether you need an app, scope the backend with the screens, give you installable test builds during the work, register the store accounts in your name, and hand over the repository on final payment. Judge us against this list as you would anyone else.

Prabhu Solutions is registered at 14 Chester Rise, Oldbury, B68 0SS, West Midlands. Our delivery record is international rather than UK-based, and we would rather say so than imply otherwise; most of the work runs over video calls and shared test builds. Who we are and who does the work is set out plainly.

If you want a view on a specific app, describe it to us and we will say whether we think you need one, and what we would ask before quoting. The full description of our app work shows what is included and what is not.

The point
If you want a view on a specific app, describe it to us and we will say whether we think you need one, and what we would ask before quoting.

Questions people ask about this

How many app development companies should I ask for quotes?

Two or three is enough, provided each quotes against the same written brief. More than that mostly produces noise, because quotes built on different assumptions cannot be compared. Judge the questions a company asks before the figure at the bottom, and use what drives the cost of an app to compare like with like.

Is the cheapest app development company a false economy?

Often, though not always. The cheapest quote is usually cheap because something is missing: the backend, the admin dashboard, testing on real devices, store submission or maintenance. Compare what each quote leaves out before you compare totals. A higher quote that includes those is frequently the lower cost of owning the app.

Does the app development company need to be near me?

No. Video calls and installable test builds do most of what a meeting does, and a visit helps at scoping and at launch. What location does affect is contract law, invoicing and time zones, so check the registered address and that the contract names a legal entity you could pursue if something went wrong.

Who should own the Apple and Google developer accounts?

You should, through your company. The accounts decide who is the seller of record, who receives revenue and who can publish updates. Enrol your organisation as account holder and add the developer as a team member. An app under an agency's account can be transferred, but only on conditions and with some settings recreated.

What should an app development contract cover?

At least what is being built and what is excluded, who owns the intellectual property and when it passes, what is handed over, who holds the store accounts, how changes are priced, what fixes are covered after launch, and what happens if either side ends the agreement. Ask a solicitor to review it; this is not legal advice.

How do I check that an app development company is genuine?

Look the company up on Companies House, confirm the people named on its website exist, find its apps live in the stores and speak to a client. Check that the name and address on the website, contract and invoice match. Be cautious of anyone who cannot show a working app or put you in touch with an engineer.

Should I ask for a fixed price or time and materials?

A fixed price suits a clearly scoped first release, because both sides know what is included. Time and materials suits work whose scope will change as you learn. Either can go wrong: a vague scope produces disputes, and open-ended hours produce surprises. For backend-heavy work, how to choose a software development company applies as well.