How to choose a software development company in 2026

TL;DR
Here is how to choose a software development company in 2026: write the scope first, shortlist on work that resembles yours, then test delivery, security and the contract before you compare a single price. The vendor who survives all seven steps is rarely the cheapest. What each step has to produce:
- A one-page scope with the business result, the integrations and the compliance regime named, before the first call.
- Verified reviews plus two references the vendor has served for years, because the average project reviewed on Clutch already runs $132,480 over about 13 months.
- Delivery metrics the vendor measures on its own work, plus a named team and written estimate assumptions.
- Dated security evidence: an ISO/IEC 27001:2022 certificate with a scope, not a policy PDF.
- A copyright assignment that takes effect as code is written, and a paid discovery phase before any long commitment.
What you are choosing between
The market is big and the failure mode is boring. Gartner forecast worldwide IT services spending at $1.570 trillion for 2026, as of July 2026. Most of that buys estimates, and estimates are what break.
Clutch puts the average software development project reviewed on its platform at $132,480 and about 13 months, with most reviewed projects landing between $10,000 and $49,999. Those numbers describe projects reviewed on Clutch, not the whole market, but they anchor what a project means to a vendor.
Then the overrun. Flyvbjerg and co-authors collected 5,392 IT projects and found a mean actual-to-estimated cost ratio of 1.8 across the 4,677 with complete cost data. The distribution has a power-law tail. Choosing a vendor is mostly choosing how you will be treated when your project lands in it.
Three 2026 dates your shortlist has to answer for
Three dated questions tell you more than a portfolio does.
The European Commission confirms that Cyber Resilience Act reporting obligations under Article 14 apply from September 11, 2026. An actively exploited vulnerability in a product sold in the EU under your name means an early warning within 24 hours, and the duty sits with you as the manufacturer. Ask the vendor who feeds you the technical detail inside that window, and at what price.
ISO lists ISO/IEC 27001:2013 as withdrawn; the current edition is ISO/IEC 27001:2022. A vendor page still advertising a 2013 certificate is advertising a withdrawn edition. Ask for the current certificate and its scope statement.
Google has required new apps and updates submitted to Play to target Android 16, API level 36, since August 31, 2026. If your product includes an Android app, this is forced maintenance that lands whether or not you shipped a feature. Ask who does it and under which contract.
How we built this checklist
Four rules, applied to every step below.
- Each step has a document as its output. If a step cannot produce something you could hand to a lawyer or a second vendor, it is advice, not a filter.
- Each criterion has a wrong answer. Anything every vendor passes is a warm-up.
- External numbers carry a source with a date. Our own numbers are aggregates, and any group with fewer than three data points is not published.
- Where a public standard exists, the step points at it instead of at our opinion: NIST for secure development, DORA for delivery, WIPO for contract terms.
One disclosure. Mercury Development sells the service this article teaches you to buy, so every step here applies to us too. If you are still deciding whether an agency is the right model at all, start with the three-model comparison.
The seven steps at a glance
| # | Step | What it produces | What disqualifies a vendor |
|---|---|---|---|
| 1 | Write the scope | One page: result, integrations, compliance regime, budget band | Nothing; this step disqualifies scopes, not vendors |
| 2 | Shortlist on similar work | Three to five vendors with a comparable shipped product each | Portfolio items nobody will let you speak to |
| 3 | Test delivery | Named team, delivery metrics, written estimate assumptions | An estimate with no assumptions attached |
| 4 | Check security | Current certificate with scope, dated pen test, processor terms | "We follow OWASP" with no artifact behind it |
| 5 | Read the contract | Present copyright assignment, accounts in your name, exit clause | Ownership transfer conditional on final payment |
| 6 | Compare prices | Three bids normalized to the same hours and assumptions | A rate below the band for its own market |
| 7 | Buy one phase | A paid discovery whose output another vendor could use | Free discovery tied to a twelve-month commitment |
Step 1. Write the scope before you write the shortlist
You cannot compare vendors against a feeling. Write one page: the business result the software has to produce, the systems it has to talk to, the regulation it lives under, and the budget band you can defend to whoever signs.
The regulation line matters more than founders expect. If the product touches protected health information in the US, HHS states that a software vendor who needs access to that information to provide its service is a business associate, and a business associate agreement has to exist before access does. If it processes EU personal data, your vendor is a processor and the ICO lists what the written contract has to cover: subprocessors, security, audit rights, and return or deletion of data at the end. Write the regime down now. It filters half the directory later.
Step 2. Shortlist on work that looks like yours
Directories are a starting point, not a verdict. When you read reviews, check the label. Clutch verifies a reviewer's identity and work history and publishes reviews it cannot verify as Not Verified, so the word verified is doing real work on that page.
Then ask for two references the vendor has served for years, not two launches. Launches are easy to show. Continuity is what you are buying. Our own public examples of the standard: Precision Practice Management, where Mercury Development has worked since 2006 and the platform is on its fourth major release; Fitbit, where the engagement began in 2011 and continued after the acquisition by Google; and Kensington, where the team took over an iOS app written in-house and then shipped the upgrades. Ask every vendor on your shortlist for the equivalent, and then ask to speak to those clients.
Step 3. Test delivery, not slides
Ask how the vendor measures its own delivery. DORA names five software delivery metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. Nobody needs to recite all five. A vendor should be able to say how often a comparable project deploys and how long a broken deploy takes to recover. Silence means nobody is measuring.
Then the estimate. Ask for the assumptions as a list: third-party APIs behaving as documented, content arriving by a date, a defined device matrix. Ask who absorbs the first 10% when an assumption fails. A vendor who cannot name one assumption has not estimated. They have guessed, and the 1.8 mean ratio above is what guessing costs.
Finally, names. Ask who will be on the project, what share of their week you get, and whether you can meet them before signing. Names that arrive after the contract mean you bought capacity from a pool. The full interview script is in our 15 questions to ask a development agency.
Step 4. Check security with documents that carry dates
"We follow OWASP" is not evidence. Ask what the vendor's secure development lifecycle looks like and check it against NIST SP 800-218, the Secure Software Development Framework, which organizes practices into four groups: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities. A vendor who can map its own process to those groups has one.
For maturity rather than presence, OWASP SAMM assesses security across five business functions: governance, design, implementation, verification and operations. Ask which of the five the vendor has been assessed on. The honest answer is usually one or two, and honest is what you want.
For enterprise buyers, the CISA Software Acquisition Guide is a ready-made question set on supplier transparency and software assurance. It was written for government and enterprise buyers and adapts to a one-page checklist. Whatever you ask, insist on dates: the certificate's issue date and scope, the last penetration test and who ran it, the last disaster recovery test. A control without a date is a sentence.
Step 5. Read the contract for ownership and exit
Paying for software does not make you its owner. WIPO states that the developer retains IP ownership unless the software development agreement assigns it to the client, and lists the terms that have to be written down: the grant of rights and the moment ownership transfers, background IP the developer keeps, open-source components and their licenses, warranties, termination, and support. Local legal advice is still necessary, before signing rather than after.
Two clauses deserve special attention. First, the timing of the assignment: ask for one effective as the code is written, and check whether it is conditional on final payment. Second, the accounts: whose legal entity holds the repository, the cloud subscription and the app store listings. If the answer is the vendor, your users belong to the vendor. The clause-by-clause version is in our guide to who owns the code when outsourcing.
Step 6. Compare prices by assumption, not by total
Rates spread by geography, and that spread is legitimate. Clutch's September 2026 pricing guide puts US software development companies at $50 to $99 an hour, Poland in the same band, and India, Ukraine, Mexico and the Philippines at $25 to $49. The number to distrust is a rate below the band for its own market. Something is subsidizing it, and it is usually the seniority of the people you get.
Compare bids by normalizing them to the same hours and the same assumptions, then look at what each vendor left out. Fixed price moves estimate risk to the vendor, who buys it back through change orders. Time and materials keeps the risk with you and the scope flexible. Phased fixed price with an acceptance standard per phase is the practical middle, and it survives the overrun statistics better than either extreme.
Step 7. Buy one paid phase before you buy the project
The good first purchase is a paid discovery that produces something you keep: a specification, an architecture, a backlog a different vendor could pick up. The bad first purchase is a free proposal attached to a twelve-month commitment. Discovery you paid for is leverage. Discovery you got free was sales.
A paid phase also shows you the working relationship instead of the selling one. You see how the vendor reports, how it handles a changed requirement, and whether the people on the call are the people in the repository. Two to four weeks is enough to learn all three.
Which steps matter most for your situation
Seven steps is a long process. Cut it by what you are doing.
First build, no technical staff of your own: steps 1, 5 and 7. Scope, ownership and a paid phase fix the mistakes that are cheap in a draft and expensive in a migration.
Rescue after a failed vendor: step 3 first, applied to your current codebase. If nobody can produce a build from your repository today, that is the first deliverable. Our vendor continuity plan covers the handoff checklist.
Regulated product, or EU users: steps 1 and 4, then the contract. The compliance regime you wrote in step 1 decides which security evidence in step 4 is mandatory rather than nice.
Outgrowing a platform and moving to custom software: step 2, weighted toward vendors who have taken over somebody else's code before, because a migration is an inherited codebase with a deadline.
What buyers say after they chose wrong
These are our own numbers, drawn from public sources. In 2026 we analyzed 9,246 statements from buyer discussions on Hacker News, Reddit and Capterra, filtered them to 261 signals from large-ticket contexts, meaning $50,000 or more in spend or an explicit enterprise, franchise or multi-location marker, and kept 40 patterns that appeared in at least three statements from two independent sources.
The rescue stories cluster around two budgets. One group had spent around $80,000 over roughly five months before looking for a new vendor. The other had spent $190,000 to $300,000 over 18 to 30 months and, in the buyers' own words, had little or nothing working to show for it. Neither group described a technology failure. They described estimates without assumptions and code they could not run without the vendor.
Two more patterns come from platform reviews. Buyers described being sold a dream on the sales call and hearing no at integration, which is what step 3 is for. Buyers also described their own data being held hostage at the end of a relationship, which is what step 5 is for.
Pick the vendor who makes leaving easy
Opinion, stated plainly. The best predictor of a good engagement is how easy the vendor makes it to end one.
A vendor confident in its work puts the repository, the accounts and the copyright in your name from the first commit, because it expects to keep you on merit. A vendor who resists any of those is telling you what its retention strategy is, and the signal arrives before you have spent a dollar.
The other half is on you. Every step above ends in a clause or a document. Running the steps and then signing a template that contradicts them is worse than not running them, because now you carry the risk and the false comfort together.
Written by Rob Devereaux, Chief Operating Officer at Mercury Development. Rob has run the firm's operations from Hudson, Ohio since 2019 and has over 20 years of operational and financial experience. The contract structures, staffing commitments and estimate reviews this checklist tells you to demand are the ones he signs at Mercury.
Ready to shortlist? Put us through the same seven steps
Use the checklist on us before you use it on anyone else. Tell us what you are building, where it will run and who you have today. We come back in writing with our answers to the steps you care about, including the awkward ones about ownership and about what happens when the engagement ends.