Choosing an App Development Company: A Vendor Checklist

Say you've received two proposals for your store's online ordering app. One costs roughly half as much as the other, and its scope is written up more briefly too. Which one do you pick? When choosing an app development company, the answer won't come from comparing the number at the bottom of the page. Ask for evidence behind every claim, and only put proposals side by side when they cover the same scope.

What should you check when choosing an app development company?

When choosing an app development company, check these: relevant portfolio work, the vendor's actual role in that work, the team members, the reasoning behind the technical proposal, and the timeline. Ownership of code and accounts, acceptance criteria and support terms matter just as much. Ask for evidence on every criterion and score same-scope proposals against fixed weights. Clear up contractual ambiguities before you choose, not after you sign.

Using this checklist is simple. Next to each vendor criterion below, write one of three statuses:

• Verified: you've seen evidence that backs up the claim.

• Needs evidence: the vendor has made the claim but hasn't shown anything yet.

• Not a fit: you've seen the evidence, and it doesn't match what the project needs.

So a line like "we've done this plenty of times" in a meeting doesn't count as verified. Until you see proof, that item stays in the second column.

"The best app development company" also means something different for every project. The best option is the vendor who has already solved your kind of problem and knows its risks. Public rankings and a row of client logos on a website tell you nothing about fit with your project.

Agency, independent team or freelancer: which fits the project?

It depends on two things: how many roles the project needs, and who coordinates those roles. Being a registered company isn't proof of delivery capability on its own. The accountability structure matters more than the legal label.

Before choosing an app development company, settle these two points in your own checklist:

• Is the project narrow or multi-part? If you want design, backend, release and maintenance at the same time, you need several roles. The number of roles shapes the kind of engagement. Evidence: a list of responsibilities with a named owner for each.

• Do you have a technical coordinator? If nobody in your organization ties several people's work together, an independent team without an integration lead will put that load on you.

Look at the "agency or freelancer" question through two hypothetical scenarios. If you want a prototype that simply shows the idea to a handful of users, an experienced freelancer is often faster and cheaper. But a product with online payments, an admin panel and an inventory integration needs several specialties and one person ultimately accountable.

That doesn't make freelancers weaker. The point is simply that the vendor's capacity has to match the scope.

How do you check the portfolio and the vendor's real role?

Judge the portfolio by how similar the problem is, not by industry or looks. A clinic's app and a distributor's app may both need offline work or a connection to an internal system. When choosing an app development company, that shared experience is what counts, not a similar color scheme.

• A live run with test data: ask the vendor to run a build in front of you. You don't need to see a previous client's confidential data.

• A description of their contribution: ask who did the design, development, backend and maintenance. Are those same people on the team proposed to you?

• One technical decision and its consequences: ask the team to explain a tough call and what effect it had later on.

The first thing I usually do in a portfolio review is test one complete flow; for example, from placing an order to checking its status. Screenshots on an app store listing only show that the screens exist. They don't prove the flow works.

Sometimes a product the vendor built is no longer available. Maybe the client closed the business or moved the app in-house. In that case, ask why and request alternative evidence, such as a test build or a video of it working. The lack of a public version isn't a reason to reject a vendor on its own.

A beautiful screen shows design skill; a flow that works end to end without errors shows delivery capability.

What should you ask about the team and technical capability?

Ask questions with answers you can check, not questions that just get a "yes." Your pre-order questions should lead to names and roles. Three basic ones: Who is the technical lead? Who does the testing? If a key member leaves, who replaces them?

As a project manager, I care more about real capacity than about résumés. Ask for a roles table: each person's name, their share of time on your project, and the decisions they own. The résumé of someone who isn't on the proposed team does nothing for you.

Ask the team to explain their technology choice as well. A good explanation refers to the product's needs, the limits of your users' devices, and maintenance costs in the years ahead. If you're torn between separate builds for each operating system and a shared codebase, comparing native and cross-platform app development will help you ask sharper questions.

The backend is the part of the system users don't see; it's where data is stored and orders are processed. Ask about it:

• How do they handle connections to external services like payment gateways or SMS?

• What does the app do if the user's internet drops mid-task?

• Where are errors logged, and who follows up on them?

• How do they store sensitive data such as phone numbers and addresses?

Evidence here comes in two forms. First, an anonymized sample of code review, meaning every change a developer makes is also checked by a colleague. Second, a real test report. If the project is sensitive, say the app handles money or health data, consider an independent technical assessment too.

What details should the technical proposal and timeline include?

A technical proposal should be precise enough that two people reading it come away with the same understanding. Tick off these items:

• Target OS versions, for example which Android and iOS versions onward

• The feature list and the admin panel's capabilities

• Integrations with other systems and services

• What's outside the vendor's commitment

• Who supplies content, such as product copy and images

This same list is the basis for comparing costs. Without it, you're putting two numbers side by side that belong to two different jobs.

For the timeline, ask for a phased plan where each phase has a reviewable output. Dependencies, who signs off each phase, and how change requests are recorded should all be clear. A date with no written assumptions behind it is worth little. If the general order of phases is unfamiliar, the mobile app development roadmap gives you a clear picture.

Remember that an initial estimate isn't a contractual commitment. Late access to an external service, delays in the client's decisions and the app store review process all shift the release date. A good proposal says who is responsible for each kind of delay.

One of the most common mistakes when choosing an app development company is looking only at the build cost. Look at cost in four pieces: the build, external services such as SMS and maps, infrastructure and hosting, and maintenance. A proposal that only quotes the build figure doesn't give you the full picture of what you'll spend.

Consider two entirely hypothetical, anonymous proposals:

Before scoring, level the scope. That means asking vendor A for the cost of testing and release and adding it to their figure. It may still come out cheaper afterwards, or it may not. And proposal B being more expensive isn't an advantage in itself either.

How do you settle ownership of code, data and accounts?

Settle ownership before you sign, in the contract text and the list of deliverables; not in the last days of the project. Source code means the editable files of the app that the next team can change. Handing over the source code isn't the same as handing over an install file. With an install file you can't change so much as a button.

• Ownership, item by item: spell out separately the status of custom code, ready-made components the vendor reuses across projects, designs, data and documentation. For third-party components, record any licensing limits.

• List of deliverables: code with its change history, build instructions and the configuration needed to run it. When access is transferred, and how that ties to payments, should also be clear.

• Accounts: app store publishing accounts, infrastructure and external services. For each account, the owner, the access administrator and the person responsible for renewals should be named.

Having an account registered in your name is only half the job. Ask how the transfer actually works in practice and what limits the store or service provider imposes. When choosing an app development company, a vendor who dodges writing down these details is a warning sign.

An app whose code and accounts aren't in your hands isn't fully yours yet.

Take the app signing key seriously too. The store uses it to recognize that an update comes from the same publisher as before. If it's lost or stays only with the vendor, releasing the next version runs into serious trouble. Ask how it will be handed over securely, where it's stored and what limits apply to transferring it. Sending passwords over a messaging app is not a handover method.

Leave sensitive ownership and licensing clauses to a legal advisor. This checklist only shows what needs to be in the contract; it doesn't replace a contract written for you.

How do you measure delivery quality and project acceptance?

Measure delivery quality against acceptance criteria. An acceptance criterion is a testable condition you write down before the work starts, and sign-off on each deliverable depends on it. Looking good isn't a delivery standard on its own.

A hypothetical acceptance criterion for payments: if the connection drops during payment, the app should check the transaction status with the server and not create a duplicate order. The expected result and the test environment are recorded alongside it. In reviews, this is the scenario I go after more than any other.

• Test evidence: test scenarios, the list of target devices and versions, bug reports and the status of fixes for any bugs that block release.

• Speed and capacity: the measurement conditions and the agreed threshold; for example, how long the home screen takes to open on a mid-range device on an ordinary connection. Words like "fast" or "bug-free" can't be measured.

• Delivery process: a trial delivery, how long you have to review, and phase-by-phase sign-off.

Keep one point separate.

Getting the app approved by an app store doesn't mean it works properly. The store checks its own rules; you're the one who has to confirm the ordering flow is correct.

On security, too, "our app is secure" isn't enough. To know what evidence to ask for before choosing an app development company, read why security matters in mobile app design.

How do you assess support and the option to switch vendors?

Assess support from a draft support agreement, not a promise that "we're always available." First, check whether four kinds of work are kept separate:

1. Fixing defects against the original commitment

2. Adding new features

3. Compatibility with new OS versions

4. Infrastructure maintenance

Each has its own cost terms. Suppose a few months after launch a new Android version comes out and one screen no longer opens properly. Is that a defect fix or new work? If the boundaries aren't clear, every request turns into a fresh argument.

In the draft agreement, find the coverage hours, the severity levels, the channel for logging requests and who is responsible for responding. Bear in mind that response time isn't resolution time. "We respond within two hours" means someone sees your message, not that the problem is solved.

Assess the option to switch vendors from day one as well. If the engagement ends, can the next team build and run the project? The evidence is a setup guide, a dependency list and a knowledge-transfer plan.

Who handles data backups and restore testing should also be clear. A backup that has never been test-restored only gives you a feeling of safety.

Before the selection meeting, ask each vendor for these documents so you have them in hand before scoring:

• A roles table with each person's level of involvement

• A technical proposal including what's out of scope

• A phased plan with assumptions and dependencies

• A proposed ownership clause and list of deliverables

• A sample test scenario and bug report

• A draft support agreement

If a vendor can't show something for confidentiality reasons, suggest an anonymized sample or a controlled demo in the meeting. That respects the previous client's rights and still doesn't leave you without evidence.

How do you score proposals and run the final meeting?

Score each proposal with a weighted form whose weights you set before seeing any proposals. That separates your comparison of app development companies from personal taste and the mood of the meeting. These are the weights I suggest, and you can adjust them to fit your project:

For the scores themselves, a simple zero-to-five scale is enough:

• 0: no evidence yet.

• 1 to 2: there is evidence, but it has a significant gap.

• 3: the project's minimum need is covered, with evidence.

• 4: strong, documented coverage.

• 5: full coverage of the need, with verifiable evidence.

A zero means "we don't have evidence yet," not proof of incompetence. Give the vendor a chance to provide evidence before the final score.

The math is simple. Multiply each criterion's weight by its score, divide by five, then add everything up. For example, a score of four on team, with a weight of twenty, gives sixteen points. The total is out of a hundred.

But a high score mustn't hide a contractual dealbreaker. Write down the project's red lines before scoring; for example, no access to the code you need or no possibility of independent handover. A proposal that crosses a red line is out, whatever its score.

Prepare the form once as an editable file and once as a printout so each member of your team can fill it in independently. Suggested columns, with one hypothetical row:

Run the final meeting with a set agenda: unanswered questions, the assumptions behind the cost, the split of responsibilities and the acceptance terms. Have both sides sign off the minutes and use them as the basis for revising the proposal. A verbal agreement that never makes it into the minutes effectively doesn't exist.

If you want to get started this week, follow this order:

1. Write down the weights and red lines and finalize them with your own team.

2. Send the document list to all vendors at the same time.

3. Pick one complete user flow to test across the portfolios.

If Niasa is on your shortlist, send us a project summary, the must-have features, integrations with other systems and your constraints. Then we'll talk through scope and approach; a firm estimate before that review doesn't mean much. You can see how we work and the service details on the mobile app design and development at Niasa page.