How to choose an app development company or developer

Write a one-page brief first

I build apps for clients, so I see this decision from the developer's side. The clients who end up happy usually wrote down what they need before contacting anyone. One page is enough, and it doesn't need to be technical:

• Who the app is for, and the main thing each type of user does in it
• Android, iPhone or both, and whether you also need a web version
• Arabic, English or both, and which one opens by default
• What it connects to: online payments, maps, delivery, SMS codes or a system you already have
• Whether someone needs an admin panel to manage content or orders
• The date you need it by, and why
• A rough budget ceiling you are comfortable with

Company, freelancer or in-house team?

An app development company gives you several roles under one roof: a project manager, a designer, app and backend developers, often a tester, and cover if someone leaves. The cost is overhead, and you may talk mostly to an account manager rather than the people writing the code.

A freelance developer or a small team gives you a direct line to the person building your app, and faster decisions. The risk is capacity: one person can get sick, get busy or disappear. Ask who covers for them, and keep the code and accounts in your hands so someone else can continue.

An in-house team makes sense when the app is your core product, with years of steady work ahead. Hiring takes time and needs someone technical to lead it. Many businesses use an outside team for version one and hire later, which works only if it is clean and properly handed over.

Whatever the label, judge the evidence: the apps they have shipped, the people who will do your work, and how they answer the questions below.

Download their published apps and test them yourself

A presentation shows design; a live app on the App Store or Google Play shows the team can finish, pass review and publish. Install two or three of their apps and spend a quarter of an hour on each:

• Sign up and log in as a new user would, including the SMS or email code
• Switch your phone to Arabic: the layout should flip to right-to-left, back arrows should point the right way and no text should be cut off
• Type a phone number, an email and an Arabic name into one form and check that each displays correctly
• Use an ordinary mid-range Android phone, not only a new iPhone, and notice how fast screens open
• Turn on airplane mode in the middle of a task: does the app explain what happened, or just freeze?
• Make the system font larger and check that buttons and text still fit
• Read the recent reviews and check when the app was last updated

Ask what they built, and who will build yours

‘We worked on this app’ can mean they built it from scratch, or fixed a few bugs for a month. Ask what they did in each one: the design, the mobile app, the backend, the admin panel, or only part of it. If you can, speak to one of their past clients.

If your users read Arabic, ask for an Arabic app by name. Right-to-left layout, Arabic fonts, mixed Arabic and English text and plural forms are where inexperienced teams slip, and late fixes are expensive. If you sell in Saudi Arabia or Egypt, ask whether they have integrated the payment options your customers use, such as Mada cards in Saudi Arabia or Paymob and Fawry in Egypt.

Then ask who will actually work on your project. Some companies pass the work to subcontractors or to their most junior people, and you should know that before you sign. Ask for names and roles, your one point of contact, how many other projects they are running, and what happens if someone leaves.

Questions to ask in the first call

• Which of your published apps is closest to mine, and what was hard about it?
• Who will work on my project, and who will I talk to every week?
• Will you use Flutter, native Swift and Kotlin, or something else, and why for this app?
• What do you need from me, and by when?
• How do you handle a feature I ask for after we agree on the scope?
• When can I first install something and try it on my phone?
• How do you test before each delivery, and on which devices?
• Whose name will the store, server and domain accounts be in?
• When and how do I get the source code?
• What happens after launch, and how is support charged?

Listen to how they answer. A good developer explains choices in plain words, admits what they don't know yet, and asks you about your users and how the app will make money.

Be wary of a team that agrees to everything, gives a price before understanding the app, or can't name one thing that might go wrong. Every app has hard parts. A team that can't see them now will find them later, on your budget.

How they handle scope and changes

Every app changes while it is being built. That is normal, as long as you agree in advance how changes work.

A sensible process: you send the change in writing, the team replies with the effect on cost and timeline, you approve, and only then does work start. Otherwise changes pile up in chat and both sides argue later about what was promised.

A fixed price suits a clear, stable scope; paying for time suits a product still taking shape. Some teams start with a short paid discovery phase that turns your brief into screens and a feature list, then give a fixed price for the build. For a new idea, that is often the most honest route.

Separate bugs from changes too. A bug is something that doesn't work as agreed, and fixing it should cost nothing. A change is new or different, and can fairly cost extra.

How to read a proposal

Send the same brief to every team so you can compare proposals line by line, not by the total. A useful proposal includes:

• The features and screens included, written so you can tick each one off
• What is not included, stated plainly
• The platforms, and the oldest phones the app will support
• Whether design, the backend and the admin panel are part of the price
• Third-party costs you will pay directly, such as developer accounts, servers, SMS, maps and payment gateway fees
• Milestones, each with something you can test, and payments tied to them
• The support included after launch, and for how long
• A clear statement that the code and the accounts belong to you

Make sure you own the source code

The contract should say that ownership of the source code, the designs and anything built specifically for you passes to your company once you pay. Without that clause, switching developers or selling the business becomes a real problem.

Don't wait for a zip file at the end. Ask for the code to live in a repository on GitHub, GitLab or Bitbucket under your own account, with the team invited as members. You see the work move every week, and the code is already yours if the relationship ends early.

Ownership should cover the backend, admin panel, design files and written build and release instructions, not only the mobile app. Open-source libraries keep their own licences, which is normal; just make sure nothing you depend on is locked in the developer's private tools.

Keep every account in your company's name

• Apple Developer Program, enrolled as your organisation
• Google Play Console, also as your organisation
• The domain and its registrar account
• Servers or cloud hosting, such as Firebase, AWS or Google Cloud
• Payment gateway, SMS, maps and email services
• Analytics and crash reporting

Create these accounts yourself with an email your company controls, then invite the developer. App Store Connect and Google Play Console both support limited roles, so the developer can upload builds without owning anything.

Start early. Apple needs a D-U-N-S number to enrol your company as an organisation, and Google Play verifies organisation accounts too. Each step can take days, so don't leave it for launch week.

That is also why store listings often name the client's company, not the agency, as the developer.

Contracts, milestones and payments

Get a written contract, even with a freelancer you trust. It protects both sides and doesn't need to be long. Make sure it covers:

• The scope, with the proposal attached
• Milestones, each ending in a build you can install and accept
• Payments tied to milestones, with nothing large paid before you see working builds
• Ownership of the code, the designs and the accounts
• How changes are requested, priced and approved
• A bug-fix period after launch, and what it covers
• Confidentiality, so your idea and your data stay private
• What happens if either side ends early, including handover of all work so far

Agree on how you will communicate

When an app project goes wrong, the cause is often silence rather than code: weeks without news, then a delivery that isn't what the client imagined.

Agree on a rhythm before you start. A short weekly call or written update covers most projects: what was done, what's next and what the team needs from you. Keep decisions in one shared channel, not scattered across WhatsApp, email and calls. Check working days too, since weekends and public holidays differ between Egypt, the Gulf and Europe.

Ask for builds you can install as you go: TestFlight on iPhone, and a Google Play Console testing track or a direct install link on Android. Seeing it on your phone every week or two catches misunderstandings while they are cheap to fix.

On your side, name one person who makes decisions. Feedback from three people pulling in different directions slows the project and raises the cost. Write important decisions down, even in a short message.

Test it yourself before you accept it

Before you approve a milestone or the final build, test it yourself rather than taking the team's word for it:

• Every feature in the agreed scope, one by one
• Arabic and English if the app has both, including switching between them
• An older or cheaper Android phone as well as an iPhone
• A weak or interrupted internet connection
• Payments in the gateway's test mode, including a failed or cancelled payment
• Notifications while the app is open, in the background and closed
• Deleting an account from inside the app, which both stores require when users can create one
• The admin panel, with the people who will actually use it

What a proper handover includes

When the project ends, you should be able to give it to another developer without asking the first team for anything. A proper handover includes:

• Admin access to the code repository, with everything in it up to date
• Written instructions to run, build and release the app
• The Android upload key and its passwords, stored somewhere safe that you control
• A list of every third-party service the app uses, who pays for it and when it renews
• Access to servers, database and admin panel, with the team's access reduced when you're ready
• The design files and the store listing material: screenshots, descriptions and the privacy policy

Support after launch

Launch is not the end. Apple and Google release new versions of iOS and Android every year, and both stores keep raising their requirements. An app nobody touches for a long time can misbehave on new phones, or be blocked from publishing updates.

Agree on two things before you sign: a free bug-fix period after launch for the agreed features, and what comes after it, whether a monthly plan, a block of hours or paying per request. Any of these works if you know which one you have.

Ask who watches for crashes once real users arrive, how quickly they respond to urgent problems, and which running costs you will carry, such as servers, SMS and the yearly Apple Developer Program membership.

Red flags that should make you walk away

• No live apps you can download, only designs and videos
• A one-line quote with no breakdown of what is included
• A price given before they understand what the app does
• Pressure to sign quickly, such as a discount that ends today
• Wanting to publish the app under their own developer account
• No access to the code until the very end, or at all
• Asking for most of the money upfront
• Promises of downloads, rankings or revenue
• No questions about your users or your business

One red flag is not always a reason to walk away. A new freelancer may have few published apps but real code and a clear process. Two or three together are a pattern, and walking away before the contract is far cheaper than after it.

Holding accounts deserves a special mention. A developer who keeps your app, domain or server in their own name controls part of your business, whatever their intentions. If that is you now, ask for a transfer while the relationship is good; both stores have an official process for moving an app to another developer account.

Final checklist and what to do next

• I sent the same one-page brief to every team
• I tested at least two of their published apps, including in Arabic
• I know who will build my app
• The proposal lists features, exclusions, milestones and third-party costs
• Payments are tied to milestones I can test on my phone
• The contract passes the code and the designs to my company
• The repository, store accounts, domain and servers are in my company's name
• We agreed how changes are priced and how often we talk
• I know what support I get after launch and how it is charged

What to do next: write your brief this week, even as rough notes. Shortlist two or three teams, ask each one the same questions and put their answers side by side. The right choice is usually clear once you do.

If you would like me to be one of those teams, send me your brief. I build Flutter apps for Android and iPhone, in Arabic and English, for clients in Egypt, the Gulf and Europe, and I am happy to answer every question on this list.

Common questions

Is it better to hire an app development company or a freelance developer?

Neither is better in general. A company gives you more roles and cover if someone leaves; a freelancer gives you a direct line to the person building and usually less overhead. Choose based on published apps you can test, the people who will actually work on your project, and whether the code and accounts will be yours.

How can I check an app developer before hiring them?

Download two or three of their published apps and test them on your own phone, in Arabic too if your users need it. Ask what exactly they built in each one, and ask to speak to a past client. Then judge how clearly they answer questions about scope, ownership and support.

Who owns the source code of my app?

You should, and the contract should say so: ownership of the code, the designs and everything built for you passes to your company once you pay. Ask for the code to live in a repository under your own account during the project, not as a zip file at the end.

Should my app be published under my account or the developer's account?

Under yours. Create your own Apple Developer Program and Google Play Console accounts as your organisation, then invite the developer as a user with the access they need. If the app is already under the developer's account, both stores have an official process to transfer it.

What should an app development quote include?

A list of features and screens, what is not included, the platforms supported, whether design, backend and admin panel are included, the third-party costs you will pay, milestones, a payment schedule and the support period. A single total with no breakdown can't be compared with anything.

How should payments to an app developer be split?

Tie each payment to a milestone that ends with something you can install and test, such as a TestFlight build or a Google Play testing track. Avoid paying most of the money before you have seen working software, and keep the final payment for after launch and a complete handover.

Can I change app developers in the middle of a project?

Yes, if you hold the code repository and the accounts, and the contract says the work done so far is handed over. The new developer will need time to review the code before giving a price. That is exactly why ownership and access should be settled before the project starts.