How to choose a software development company [selection criteria]

Your app launched in the spring. In September, a small fix cannot reach Google Play until someone updates the project, because the store now requires apps to target Android 16.

Your proposal promised 4 services: strategy, UX/UI design, web and mobile development, and DevOps with maintenance. The update arrives as a new estimate, and the designer who knew the app moved to another client after handoff.

Nothing failed dramatically. The services after launch were simply the thinnest part of the proposal, and no one tested them before signing.

This guide shows how to choose a software development company with that risk in mind. It splits "end-to-end" into the 4 services and the handoffs between them, names the evidence to ask for at each step, and ends with a scorecard of selection criteria you can use to compare vendors side by side.

How to choose a software development company: the checklist at a glance

Use this software development vendor evaluation checklist as your first written request to every vendor on your shortlist.

Score each vendor on what it shows you, using the scorecard further down.

What "end-to-end" should cover, and who actually does it

An end-to-end product development company sells 4 services under 1 contract. Strategy and discovery decide what to build first and how you will know it works. UX/UI design turns that decision into flows and screens people can use. Web and mobile development builds them. DevOps and maintenance get the product to users, keep it running, and keep it current after launch.

Between those services sit 3 handoffs: strategy to design, design to build, and build to operations. At each one, knowledge passes from one group of people to another. Each is a place where something can get lost.

Most vendors are strongest in 1 or 2 of the 4 services. That is normal. Few companies hire senior people for all 4 at the same depth, and a team known for polished design may treat hosting as a side task. The goal of the checklist is to find out which services are strong, which are thin, and who does each one.

Ask who does the work. For each service, ask whether it is done by the vendor's employees, by contractors, or by a partner company. Full-cycle software development companies often bring in a design studio or an infrastructure specialist, and that arrangement can work well. The proposal should name it and say who on the vendor's side manages that partner.

Where the team sits is a separate decision with its own trade-offs. Our guide to onshore vs nearshore vs offshore outsourcing covers how to choose where your team sits.

4 things to settle before you send the checklist

The checklist works better when you have answers to 4 questions of your own. Vendors will ask about them anyway, and your answers decide which outsourcing vendor selection criteria matter most for your product.

1. What the first version must prove. Write it in 1 sentence, such as "tow companies will accept jobs through the app instead of by phone." If you cannot write that sentence yet, start by deciding what your MVP must prove.
2. Who on your side approves decisions, and how many hours a week they have for it. Every service on the checklist will send questions back to you.
3. Which rules apply to your product. Health data, payments, children's data, and sales to public schools or local governments each bring their own requirements. These narrow your shortlist before price does.
4. What you plan to handle yourself after launch, with your own staff or a future hire. This decides how much maintenance you need to buy.

The checklist, service by service

These are the questions to ask a software development company, grouped by service. Each item says what to ask for and what a good answer sounds like. Send the same list to every vendor so you can compare the answers line by line.

1. Product strategy and discovery

Discovery decides what gets built, and building the wrong thing is expensive. CB Insights' 2026 analysis of 431 venture-backed startup shutdowns found poor product-market fit in 43% of cases. A vendor that builds everything on your list, exactly as written, offers you no protection against that.

• A sample discovery output from a past project, with client details removed. Look for a problem statement, the assumptions the team made, a first-version scope that shows what was cut, and a success measure. A good answer arrives within a few days and fits on a few pages.
• The name and background of the person who runs discovery. You want a product manager or product lead, and you want to hear that this person stays on the project after discovery ends.
• How discovery is priced. A strong answer is a separate, paid phase with a written output you own and could take to another vendor.
• A feature the team talked a client out of building, and the reason. Look for a real project and a decision you can picture.
• How the team will measure whether the product works after launch: which analytics are set up, which user actions are tracked, and who reads the numbers.

Red flags: a detailed fixed price before anyone asks about your users, and a discovery phase that is 1 workshop with no written output.

2. UX/UI design

Design decides how the product behaves before anyone writes code. Changing a screen in a prototype takes hours. Changing it after it is built takes a sprint.

• A case study that shows the design process: the research, the first version, what testing found, and what changed as a result. Final screens show taste. The process shows judgment.
• How often the team tests with real users, and with how many. Jakob Nielsen's research for Nielsen Norman Group found that a test with 5 users uncovers about 85% of a design's usability problems, and that 3 small rounds with fixes in between teach more than 1 large study. A good answer puts several rounds of testing in the plan and the budget.
• The accessibility standard the team designs and tests to. The answer you want is WCAG 2.1 Level AA at minimum, checked during design and again in development. WCAG 2.2 is the current version from the W3C, and a team already working to it is ahead.
• How designs reach developers. Look for a shared design file with reusable components and written specifications, and designers who stay available during the build to answer questions and review what got built.
• Who owns the design files. They belong in your company's account from the start.

If you sell to public schools, colleges, or local governments, accessibility is a contract requirement for your customers. The Department of Justice's rule under Title II of the Americans with Disabilities Act sets WCAG 2.1 Level AA as the technical standard for state and local governments' websites and mobile apps, including those provided through contractors. An interim final rule published April 20, 2026 moved the compliance dates to April 26, 2027 for entities serving 50,000 people or more, and April 26, 2028 for smaller entities and special district governments. Expect these customers to ask your product to meet the standard.

Red flags: designers who leave the project at handoff, and a portfolio of visuals with no problem, user, or result attached.

3. Web and mobile development

Development is where most of the budget goes. It is also where the team you met during sales can quietly change.

• The names, roles, and seniority of the people who will write your code, and whether they are employees or contractors. A good sign is a call with the lead engineer before you sign. Put the named team in the contract, with a rule for substitutions.
• Live apps you can check yourself. Find the vendor's past apps in the App Store and Google Play, then look at the version history and the date of the last update. Andrew King, who leads pre-sales engineering at the agency Very Good Ventures, suggests this check because store listings are harder to curate than a portfolio page. An app with no update in a year tells you something about what support means at that company.
• How the team chooses between native apps, cross-platform frameworks, and web for your product. A good answer is a recommendation with reasons, including why the team did not pick the other options.
• How code gets tested and reviewed, including code written with AI coding tools. Look for automated tests, a review step before any change is merged, and a staging link you can open. AI tools are a normal part of development now. Review matters because Veracode's 2025 GenAI Code Security Report found security flaws from the OWASP Top 10 in 45% of tests of AI-generated code.
• The security standard the team tests against. A good answer names one, such as the OWASP Application Security Verification Standard (ASVS) for web apps, released as version 5.0 in May 2025, or the OWASP Mobile Application Security Verification Standard (MASVS) for mobile apps. Ask for a recent test summary with client details removed.
• A code repository in your company's name, from the first commit.

The contract side of these items (named team, ownership, and access) is covered in detail in who owns what in an outsourced build.

Red flags: no technical person on the sales call, and agreement with every technology you mention.

4. DevOps, hosting, and releases

DevOps decides how safely and how often changes reach your users. It is also the service most likely to be 1 engineer's side job.

The most useful measures come from DORA, a long-running research program on software delivery. In plain words, they ask 4 things: how often a team releases, how long a change takes to reach users, how often a release causes a problem, and how fast the team recovers when one does. 

The newest research adds a reason to ask. DORA's 2025 report, State of AI-assisted Software Development, surveyed nearly 5,000 technology professionals. It found that 90% of respondents use AI at work, and that AI adoption is now linked to higher delivery throughput but still to lower delivery stability. Teams ship more changes, so the safety nets around those changes (automated tests, a quick way to undo a release) carry more weight.

• How often a typical client project releases, and how the team undoes a bad release. A good answer includes a number, such as "every 1 to 2 weeks," and a rollback they have actually used.
• Separate test and live environments: a staging copy and production. You should get the staging link.
• Monitoring and alerts. Ask who gets notified when the live product breaks, in which time zone, and how fast they respond.
• Backups and a restore test. Ask when the team last restored a backup to confirm it works.
• Cloud accounts and the monthly bill. Hosting accounts belong in your company's name, with an estimate of monthly costs and a person who reviews them.

Red flags: releases done by hand by 1 person, and no one who can say when a backup was last restored.

5. Maintenance and support after launch

A product keeps costing money after launch. Part of that work is optional, such as new features. Part of it is set by the app stores and by the software your product depends on, and it arrives on a calendar.

Apple. Since April 28, 2026, every app uploaded to App Store Connect must be built with Xcode 26 or later, using the 26 versions of Apple's software development kits. Apple's requirements page shows a new minimum in April of most recent years.

Google Play. Since August 31, 2026, new apps and app updates must target Android 16 (API level 36). Existing apps that target an Android version below Android 15 (API level 35) stop being available to new users on devices running newer Android versions. Google raises this requirement every year.

Neither change is a bug fix, and neither is optional for a mobile product that wants to keep shipping updates and reaching new users. A vendor's plan for them tells you more about its maintenance offer than its brochure does.

• A plan and a price for the yearly platform updates. A good answer puts them in the maintenance agreement, scheduled ahead of each deadline.
• A support agreement with response times by severity, for example "production down" versus "cosmetic bug," plus the hours covered and the time zone.
• A written line between a bug and a change request. Most disputes after launch start here.
• An uptime commitment in plain numbers. For reference, 99.9% uptime still allows about 43 minutes of downtime in a 30-day month.
  
  
• Updates to third-party libraries and security patches: how often they happen, and who decides.
• Who stays on the team after launch. At least 1 person who built the product should stay on maintenance.

Red flags: "post-launch support available" with no written terms, and maintenance quoted only as an hourly rate with no plan behind it.

Check the handoffs: where end-to-end projects lose information

A vendor can be strong in all 4 services and still lose information between them. Each handoff has a question that tests it.

Ask for 1 accountable person. Find out who is responsible for your product across all 4 services, by name, and how much of their week goes to you. The best answer is a product or delivery lead who stays from discovery to maintenance.

Ask which part the vendor would hand to a partner. A vendor that can describe its own limits is giving you information you can use. Andrew King of Very Good Ventures puts it from the seller's side: "An agency that maps its own boundaries is telling you the truth." A clear answer, such as "we design and build, and a partner we have worked with for 3 years runs your cloud infrastructure," is easier to plan around than a promise to cover everything.

If you already work with a vendor and these gaps sound familiar, our guide to the signs your dev team is behind can help you check where the project stands.

Commercial and exit terms, in brief

This section is general information, not legal advice. Have a lawyer review the contract, especially if the vendor is based in another country.

• Copyright assigned to your company in writing. "Work made for hire" language alone usually does not transfer code written by an outside company under US law.
• Accounts in your company's name: code repository, cloud hosting, domain, design files, and app store listings.
• The named team in the contract, with a rule for substitutions.
• Acceptance criteria tied to payments, and a written process for changes.
• Exit and handover terms: notice period, documentation, and a set number of handover hours.

Software development company selection criteria: a simple scorecard

Vendors answer confident questions with confident answers. The scorecard rates what each vendor shows you, which is harder to inflate. Its 7 areas are your software development vendor selection criteria, and each score comes from evidence.

Score each area from 0 to 3:

• 0: claimed in the proposal only
• 1: described in detail when you asked
• 2: shown to you as a sample, a document, or a live app
• 3: verified by a reference or by a check you did yourself

Multiply each score by the area's weight and add them up. Start with the default weights below and adjust them for your product. A regulated or public-sector product should weigh design (for accessibility) and development (for security) more. A marketing website can weigh DevOps less.

Ask for 2 kinds of references. The first is a client whose product the vendor has supported for 2 years or more, which tests the maintenance claims. The second is a project that ran into problems, and how the vendor handled them.

Read reviews for detail. Clutch checks each reviewer's identity and work history, and it publishes reviews it could not verify with a "not Verified" label. Read the project details in each review, such as the services, the length of the engagement, and the results, and check that recent reviews mention the services you plan to buy.

Then turn the scores into a decision. Send the same checklist to every vendor in writing, score the answers side by side, and run a paid discovery phase with the top 1 or 2. Discovery is the cheapest way to see how a team works before you commit to the full build.

One vendor or several?

The checklist may show that no single vendor is strong across all 4 services. That is a useful result, and you have options.

The right choice depends on which service carries the most risk for your product, and on who will manage the handoffs between providers.

Wrapping up

"End-to-end" is a useful promise when you can check each part of it, and that is the practical answer to how to choose a software development company. Split the promise into strategy, design, development, and DevOps with maintenance. Ask for evidence in each one, test the 3 handoffs, and score what vendors show you. The yearly Apple and Google updates make a good final test, because every mobile product will need them and every serious vendor should already have a plan.

How Sproutly helps

The gap this checklist exposes is the same one founders bring to us: someone who checks the evidence before the contract is signed and stays across the handoffs afterward.

Through Edge Sourcing™, Sproutly helps you define what you are building, matches you with a verified development partner, and keeps you, the partner, and a fractional product and technical lead (we call them Edge Facilitators) on the same tools and the same process. Early signs of trouble reach all of you at the same time. Our development partners in India and Eastern Europe have verified projects and talent profiles before we match them with a client. [SME: add 1 sentence on how Sproutly verifies partners, and whether those checks follow this checklist.]

2 projects show the model in practice. For one of the largest school districts in the US, Sproutly built the web application teachers use to plan daily community meetings with their students. A partner team now develops it, and a Sproutly cofounder is the district's Edge Facilitator, staying across the handoff from build to ongoing development. For Tow Ninja, a towing startup, we took over a partially built MVP, reviewed the code and fixed priority issues, added unit tests and an automated release pipeline, built the missing features, and helped launch the pilot. Read how we finished a partial MVP, or see more client stories.

If you are choosing a development partner now, book a needs assessment. If you already have a vendor that sold "end-to-end" and part of it is not landing, schedule a team assessment for an independent, plain-language read on where your project stands.

References

1. Apple Developer. "Upcoming requirements." developer.apple.com
2. Android Developers. "Meet Google Play's target API level requirement." developer.android.com
3. Google Play Console Help. "Target API level requirements for Google Play apps." support.google.com
4. CB Insights (March 2026). "The top reasons startups fail." cbinsights.com
5. Nielsen, J. (March 18, 2000). "Why You Only Need to Test with 5 Users." Nielsen Norman Group. nngroup.com
6. W3C (2023). Web Content Accessibility Guidelines (WCAG) 2.2. w3.org
7. US Department of Justice, ADA.gov. "Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments." ada.gov
8. US Department of Justice (April 20, 2026). "Extension of Compliance Dates for Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities." Federal Register. federalregister.gov
9. King, A. (August 17, 2026). "How to De-Risk Hiring an App Development Agency." Very Good Ventures. verygood.ventures
10. Veracode (2025). 2025 GenAI Code Security Report. veracode.com
11. OWASP Foundation (2025). Application Security Verification Standard 5.0. owasp.org
12. OWASP Foundation. Mobile Application Security Verification Standard (MASVS). mas.owasp.org
13. DORA and Google Cloud (2025). State of AI-assisted Software Development. dora.dev
14. Harvey, N., and DeBellis, D. (September 23, 2025). "Announcing the 2025 DORA Report." Google Cloud blog. cloud.google.com
15. Clutch Help Center. "How does Clutch verify reviews?" help.clutch.co
16. US Copyright Office (rev. 2024). Circular 30: Works Made for Hire. copyright.gov

FAQ

How do I choose a software development company?

To choose a software development company, send every vendor on your shortlist the same written checklist covering strategy, UX/UI design, web and mobile development, and DevOps with maintenance. Ask for evidence in each area, check the handoffs between them, and score the answers from 0 to 3. Then run a paid discovery phase with the top 1 or 2.

What are the most important outsourcing vendor selection criteria?

For software product work, the most important outsourcing vendor selection criteria are a named team, evidence of a real process in each service, release and maintenance practices, and ownership of code and accounts. They also work as IT outsourcing vendor selection criteria whenever the work includes building or running software. Weight them for your product, and score each vendor on what it shows you.

What does end-to-end digital product development include?

End-to-end digital product development covers strategy and discovery, UX/UI design, web and mobile development, and DevOps with ongoing maintenance, all under 1 contract. Ask who does each part. Many vendors use contractors or partner companies for design or infrastructure, which can work well when the proposal names the arrangement and the person who manages it.

Is it better to hire 1 end-to-end vendor or separate specialists?

1 end-to-end vendor works well when it scores strongly in every area and you want 1 accountable team. Separate specialists make sense when 1 service, such as accessible design, matters far more than the rest. Specialists mean you coordinate the handoffs, or bring in someone on your side to cover them.

How do I check a vendor's DevOps practices if I am not technical?

You can check a vendor's DevOps practices by asking 4 plain questions: how often client projects release, how the team undoes a bad release, who gets alerted when the live product breaks, and when the team last restored a backup. Ask for a staging link and open it yourself. Specific numbers and dates are good signs.

Why do mobile apps need updates every year?

Mobile apps need yearly updates because Apple and Google raise their technical minimums on a schedule. Since April 28, 2026, Apple requires uploads built with Xcode 26. Since August 31, 2026, Google Play requires new apps and updates to target Android 16. A maintenance agreement should plan and price these updates before each deadline.

Should accessibility be on my vendor checklist?

Accessibility belongs on every vendor checklist. Ask which standard the team designs and tests to; WCAG 2.1 Level AA is a sound minimum. If you sell to public schools or local governments, the ADA Title II rule makes that standard a requirement for your customers, with compliance dates of April 26, 2027 and April 26, 2028 depending on size.

How many software development companies should I compare?

We suggest sending the same written checklist to 3 to 5 software development companies, scoring the answers side by side, and running a paid discovery phase with the top 1 or 2. That keeps the comparison manageable and lets you see how a team works before committing to the full build.