How to Choose the Right Mobile App Development Company in the USA?

A Step-by-Step Guide to Finding the Right App Development Partner

Developing a mobile application is more than just selecting a company that meets your budget and reviewing a sample portfolio of mobile apps developed by that company. Mobile applications developed by your selected company have the potential to negatively impact the security, stability, and overall usability of your product.

Start by analyzing whether a potential company can discuss how they would build your product and what risks and issues are likely to arise in the development and maintenance of the application. Have the company list and explain their development choices, especially risks that they would prioritize in the development process.

Analyze whether a company can explain how the product is built, what the risks are during the development of the product, and how the product will be supported post-development in sufficient detail.

1. Determine Your Product Before Evaluating Any Vendors

Understanding the business problem to be solved, the end-user, the desired features, the platforms on which the product is required, the expected timeline, the constraints on the budget, and the expected goals for the initial release of the product is very important before asking potential vendors to prepare a proposal.

Both product and platform requirements strongly influence the type of mobile application being developed. Your application can require secure messaging, backend integrations, or real-time updates.

Consider whether you will also be developing other elements of the system (backend, APIs, etc.) that interact with your mobile application. When a project extends beyond the mobile interface, reviewing custom software development capabilities can be useful.

One Simple Test: Describing your project in one page serves as a great starting point for evaluating prospects. Pay particular attention to the sorts of questions they ask in preparation for the pitch. Regarding location tracking for example, “GPS integration” is the least of your worries. Where is the accuracy needed? How is the technology to be used? What is the battery impact? How often should the technology update? What happens when the location data is not available?

The quality of these initial questions reveals whether the vendor can really address your business needs, or if they are just making a guess based on a feature checklist.

2. Evaluate Relevant Experience, Not Portfolio Size

Long lists of completed projects are less important than demonstrating the quality of project work and how well it addresses your needs.

The EduZone mobile learning application provides user flows, detailed design wireframes, and UI screens for both the teacher and learner. It shows a considerable degree of product thought. An “education app” may mean something to a developer, but an application that is targeted at educators, with the inclusion of user flows, and detailed decision making and trade-offs for user interface is much more descriptive for a client.

CodeStore’s E-Library was a digital product that could support many user groups, and provide content in many different formats, and multiple access devices. A potential customer could clearly indicate features that are important to them and make the best choice for their needs.

For each case study you review, determine whether the vendor was able to:

• Solve the business case
• Describe the functionality they built
• Describe challenges they faced
• Describe their role
• Describe what happened post implementation

It may also help to ask what the most difficult issue was that they faced, and how they solved it. Assuming the issues were not related to the confidential nature of the engagement, asking a client who engaged the vendor may be useful. It may give you the opportunity to inquire about how the vendor handled an unexpected situation, was flexible to evolving requirements, and post implementation challenges that may have arisen.

3. Analyze the Technical Approach

Proposals may outline a tech stack with little or no detail on how the technologies integrate with each other. Ask the technical team to outline how the mobile app, APIs, database, authentication, cloud services, and other third-party integrations connect.

For example, let’s consider a payment request that reaches the provider. The payment request may occur while the user’s phone is out of cell/internet coverage. The payment request app must ensure that users do not resend payment requests. This is accomplished by ensuring that the payment request app does not allow users to resend payment requests while the transaction state is still processing (verification is still pending).

The same logic applies to payment failures and failures in integrations with other systems (e.g. maps, calendars, messaging, etc.). Engineering best practices must be incorporated throughout the design of the app.

Native versus Cross-Platform?

Generally speaking, mobile apps with high levels of interaction or apps that use high level features of mobile devices are generally built natively. Native apps provide performance and stability benefits over cross-platform development. Other considerations include the amount of code that needs to be duplicated across Android and iOS. Generally a vendor should provide justification for native over cross-platform or vice versa, based on the functionality or feature set of the app being developed.

4. Analyze Integration Experience

Most apps incorporate a variety of external services for payments, data/analytics, location services, communications, and other features. Integration experience entails development practices for external service APIs with gracefully, or failure, handling of access controls, outages, rate limits, and authentication protection.

An example is the payment APIs. An HTTP payment API request does not always mean the payment was processed. Confirmation of payment is a separate API request and often requires safe, retry logic.

When considering integrations as a primary aspect of the product, assessing the vendor’s third-party API integrations can offer additional insight for comparison against a given technical team.

5. Identify Who Does What

A service list often fails to answer this question. Attribution may span user experience (UX) research and user interface (UI) design, mobile and server development, integration and maintenance of application programming interfaces (APIs) and services, cloud computing, quality assurance (QA) and testing, and security.

Find out who does what in-house and what is outsourced, and who leads architecture, design, and backend development, QA, and DevOps. This becomes highly important when considering mobile app development companies based in the USA for a product targeted towards USA users. If a key developer leaves during the development cycle, it is important to have good process documentation to aid new developers. Source code, version control systems, and project management applications that incorporate processes should support this.

6. Analyze Development and Communication Methods

Evaluate how the vendor manages the development of a product from the definition of requirements to the deployment of a functional product, and documentation of requirements and designs.

Consider what the vendor does when a requirement changes in the middle of a development cycle. The best processes outline how the requirement is documented, prioritized, and communicated along with its impact to the timeline and budget. This level of traceability becomes critical for an evolving product.

7. Incorporate Security Testing as Part of Development and QA

The quality of the product needs to be verified for its intended use, but the development of mobile applications needs to expand beyond this verification to encompass scenarios with network delays and disruptions, unstable and changing platform environments, shifts in user permission levels, and interrupted app sessions.

An example of what should be tested during checkout flow is the payment button being tapped as the network connection is unstable, when an API takes a while to respond, or when the application is used as the OS is resuming from an interruption.

There are several key elements that should be included in discussions around security such as authentication, authorization, encryption, access controls, data storage, dependencies, and management of security controls. The OWASP Mobile Application Security Verification Standard (MASVS) is a useful framework to consider in this regard as well as Apple’s privacy and data use guidelines. Third party SDKs should also be reviewed in this regard.

Company-provided software testing and QA processes can provide context, but what matters more is what testing will actually be done and which workflows will be prioritized.

8. Consider The Real Cost Beyond the Quoted Price

Developing a mobile app on your own will vary greatly in cost based on the desired features, integrations, security measures, testing efforts, and team size. Various third parties have published general pricing data such as Clutch, however, your specific cost will depend greatly on complexity.

Each of the proposals should include work related to: Discovery, Design, Development, API integration, QA, deployment, and post development support. There will be one time development costs and ongoing costs which will depend on your hosting service and how much you use APIs.

An assumption check should be done to ask what the vendors estimate will cost based on your assumed constraints. There is likely to be a significant difference in quoted costs.

9. Confirm Ownership and Third-Party Dependencies

Prior to starting work, settle ownership of intellectual property (IP) and external resources. For example: source code, designs, databases, docs, cloud resources, app stores, domains and credentials.

Furthermore, clarify how an ownership transfer will be facilitated in the future: scope of source code to be transferred, account credentials, ownership of known defects, deployment artifacts and architecture, and how service build and deployment will be executed.

Define ownership of services that rely on paid third-party integrations (e.g. AI services, payment services, mapping services, and analytics services) to avoid contractual issues in the future.

10. Consider a Paid Pilot for High-Risk Features

High-risk features (e.g. performance-intensive features, integration of third-party services via challenging APIs, location services, etc.) benefit from a paid pilot.

Initial technical work (so-called ‘technical pilots’) exposes early design and integration challenges (e.g. authentication challenges, duplicate/redundant/unnecessary request/transactions).

11. Ask About Post-Launch Support

Post launch is the start of a new support phase. Over time, an application is expected to integrate with new Operating Systems (e.g. Cloud services) and address new security threats, as well as, APIs. Post launch support will define the terms of the partnership for the lifecycle of the application.

Before you sign, ask the following questions:

• How long will the support period be?
• What differentiates a bug vs a new feature?
• What is your average response time for high-severity tickets?
• What determines the price of support and maintenance contracts?
• Who determines whether a given support/maintenance issue is a security concern?
• Are you willing to actively monitor production?

Android Vitals, for example, shows ANRs (Application Not Responding) and/or other issues that a developer might have difficulty identifying.

Examining other software companies maintenance contracts provides insight on what support might entail. This should be outlined in the contract along with the differentiation between support issues due to our code vs a third party code.

12. Proposal Reality Check

When several proposals appear to be similar, go beyond the basics.

• Verify the scope of the contract.
• Review a trade-off related to a high-level design decision.
• Confirm the test strategy for the highest-risk workflow.
• Confirm how source code, accounts, and hardware will be transferred.
• Check how product issues will be prioritized, documented, and addressed.

At this point, review any ‘red flags’ you may have noticed before, such as lack of detail in the deliverables, scope, or security case studies. Other ‘red flags’ you may notice include poor/no justification for a low bid, no description of the delivery team, and/or an overly aggressive project timeline with a lack of definition of deliverables and requirements. If a vendor cites a short timeline for delivery, find out what, if any, dependencies they expect will be satisfied.

Mobile App Development Company Evaluation Checklist

Vendor Questions

• Has the company developed similar products before? If yes, can we meet the people who will work on our product?
• Can we have a documented process on how you manage changes in project scope?

Technical

• Do you have documentation on your product’s architecture?
• Which third-party services do you integrate with, and how do you manage them?
• Do you use native or cross-platform mobile development?

QA

• How and when do you involve QA in your projects?
• Which devices do you include in your testing?
• What failure scenarios are you covering?

Contract and Ownership

• What source code will we get in the end?
• What happens when you transfer the source code to us?

Evaluation Area

Overall score: Why did you give the development team the score that you did? How did they compare with other development teams? Considering all the above sections, how good did you rate the development team?

Conclusion

We do not only consider portfolios, rates, and promised timelines when evaluating a development company, but we also consider several other factors, including product understanding, approach to QA and security, contract and ownership, and app support.

It is essential that all requirements relating to scope, responsibilities, assumptions, dependencies, ownership, and service or support levels have been agreed and documented prior to signature. The evidence provided should be as project specific as possible, and not just relate to broad capability statements.

When companies in the USA evaluate potential mobile app development partners, they may wish to assess CodeStore against other software development companies in terms of their track record and reputation, but also the specific requirements, challenges and risks associated with the mobile app development project.

Technical support and service should match the operational requirements of the mobile application.

Mobile App Development Request

Send us your mobile app project requirements for a free technical assessment and evaluation for software architecture, development, integration, testing, timeline, and business goals.

Frequently Asked Questions