How to Choose a Software Development Company: A Vetting Checklist for Business Owners

Last updated: September 4, 2026 · By Joseph Olivas, Founder, MEAN Consultors · 10 min read

I have sat on both sides of this decision. I have been the vendor being vetted, and I have been the business owner inheriting a system built by a firm that was chosen because its proposal was the cheapest and its salesperson was the most confident. The second experience is the one that taught me how to run a selection process. Custom software is a multi-month, often multi-year relationship in which you will not be able to inspect most of the work product yourself. That means the decision is really about predicting how a team behaves when requirements shift, deadlines slip, and something breaks in production. This checklist is built to surface exactly that, and it is the process I recommend even when the firm being evaluated is MEAN Consultors’ own software development team.

Why the Selection Process Matters More Than the Proposal

Large software projects fail at rates that would be unacceptable in almost any other purchase. A widely cited McKinsey and University of Oxford study of more than 5,000 IT projects found that large projects ran 45 percent over budget and delivered 56 percent less value than predicted on average. The root causes were rarely technical. They were unclear objectives, shifting requirements, weak alignment between the business and the delivery team, and poor communication. Every one of those is a property of the partner relationship, not of the code, which is why vetting the partner is the highest-leverage decision in the whole project.

It also means the proposal document is a weak predictor. A proposal tells you what a firm says it will do under ideal conditions. The vetting process below is designed to tell you what it does under real ones. Security and third-party risk are a separate, deeper layer of the same question, and we cover them in our guide to vetting a software development partner for vendor risk; this post is about the overall selection decision.

Before You Contact Anyone: Write the One-Page Brief

The single biggest improvement most businesses can make to their selection process costs nothing: write down the problem before asking anyone to solve it. One page is enough. State the business problem in plain language, the people who will use the system and what they do today, the systems it must connect to, the hard constraints (budget range, deadline, compliance), and how you will know it worked. Do not specify features; that is the vendor’s job to propose. If you want a fuller template, our guide to writing a software requirements document non-technical founders can use expands each section.

This brief does double duty. It forces internal clarity before anyone spends money, and it becomes the test you send to every firm on your long list. How a company responds to a one-page brief tells you more than any portfolio.

The Five-Stage Vetting Funnel

Figure 1: The vetting funnel. Each stage is designed to remove roughly a third of the remaining firms using a different kind of evidence.

Stage 1: Build a long list of 8 to 12 firms

Sources, in order of signal quality: referrals from businesses with a similar problem, firms whose published case studies describe systems like yours, and industry-specific directories. Filter on two things only at this stage: have they shipped something in your problem space (not necessarily your industry), and are they the right size, meaning your project would matter to them without overwhelming them. A firm for whom you would be the largest client is as risky as one for whom you would be the smallest.

Stage 2: Send the written brief and score the questions

Send the same one-page brief to every firm and ask for a short written response within a week. Do not ask for a price yet. What you are scoring is the quality of the questions they ask back. Strong firms ask about users, edge cases, data volumes, integrations, and what happens when the system is down. Weak firms send a templated capabilities deck and a rate card. This stage typically halves the list.

Stage 3: Discovery calls with the people who will do the work

Insist that the engineers or technical lead who would actually work on your project join the call, not just a sales lead. Ask them to walk you through a past project in detail: what the original scope was, what changed, what broke, and how they handled it. Then ask how they would approach your brief. You are listening for specificity, for honesty about trade-offs, and for whether they push back on anything. A team that agrees with everything you say has either not understood the problem or is not planning to tell you when you are wrong.

Stage 4: Reference checks that ask about failure

Every firm will give you happy references. Use them anyway, but change the questions. Ask each reference: what went wrong during the project, how did the firm communicate it, what did the change process look like, who from the original team is still around, and what does support look like two years later. A reference who cannot name anything that went wrong either had an unusually smooth project or was not close enough to it to be useful.

Stage 5: Buy a paid discovery or pilot before the main contract

For anything beyond a small project, do not go from proposal to a six-figure contract. Pay one or two finalists for a fixed-scope discovery phase (typically two to four weeks) that produces a written specification, architecture outline, risk register, and a firm estimate for the build. You get a far more accurate price, a deliverable you own regardless of who builds it, and a live test of how the team works with yours. If a firm refuses to sell discovery separately, that is a data point.

The Seven-Criterion Scorecard

Comparing firms by feel produces a decision driven by whoever presented last. Use a scorecard instead. Rate each firm from 1 to 5 on each criterion, multiply by the weight, and total. The weights below reflect what has actually predicted project outcomes in our experience, and they are deliberately front-loaded toward evidence you gather in Stages 3 through 5.

Figure 2: Recommended weights for the vendor scorecard. Track record, discovery process, and engineering practices together account for 55 percent of the score.

The Engineering Questions a Non-Technical Buyer Can Still Ask

You do not need to evaluate code to evaluate engineering discipline. Ask these and judge the specificity of the answers.

• How do you test? Look for automated unit and integration tests, and ask what percentage of the codebase is covered on a recent project.
• How does code get from a developer’s machine to production? A described pipeline with automated checks is the answer; a person copying files is not. Our explainer on CI/CD and why it matters for reliability covers what good looks like.
• How do you handle security? The U.S. Cybersecurity and Infrastructure Security Agency’s Secure by Design principles give you a vocabulary: ask about dependency scanning, secrets management, access control, and how vulnerabilities in shipped software are disclosed and patched.
• Who owns the code, the data, the cloud accounts, and the domain? The answer should be you, in writing, on payment.
• What happens if we stop working together? You want a documented handover: repository access, documentation, infrastructure credentials, and a transition period.
• How do you estimate, and how often are you wrong? Honest firms will tell you their typical variance and how they manage it through scope.

Understanding Pricing Models Before You Compare Prices

Bids are not comparable until the pricing model is. A fixed-price quote from one firm and a time-and-materials estimate from another describe different risk allocations, not different costs. Fixed price shifts estimation risk to the vendor, who prices that risk in and resists change; time and materials shifts it to you, with more flexibility and more need for oversight. Many good engagements use a fixed-price discovery followed by a capped time-and-materials build. The full trade-off is laid out in fixed price vs. time and materials contracts, and typical budget ranges are in our 2026 custom software cost guide. If you are also weighing where the team sits, our comparison of nearshore vs. offshore development covers the cost, quality, and communication trade-offs.

Red Flags That Should End the Conversation

Some findings are disqualifying regardless of score. A refusal to let you meet the engineers before signing. A contract in which the vendor retains ownership of the code or hosts it in accounts you do not control. A fixed price quoted from a one-page brief with no discovery. Inability to produce a reference who will discuss a project that had problems. Pressure to sign before a deadline that exists only in the proposal. And any guarantee of a delivery date for a system whose requirements have not yet been written down. None of these are common among serious firms, which is exactly why they are useful filters.

Making the Final Decision

By the end of Stage 5 you will usually have one firm that scored highest and one that felt best. When they are the same firm, the decision is easy. When they are not, trust the scorecard over the feeling but interrogate why they diverge; often the “felt best” firm simply presented well, and the scorecard is doing its job. Whichever firm you choose, the discovery deliverable, the scorecard, and the reference notes become the first pages of your project file. They are what you will hold the partner to, and a good partner will welcome that. If you would like to see how we run discovery and what a scored engagement looks like from the inside, our software development services page describes the process end to end.

Frequently Asked Questions

How do I choose a custom software development company?

Write a one-page brief describing the business problem, build a long list of 8 to 12 firms, send each the brief and judge the questions they ask back, hold discovery calls with the engineers who would build the system, check two references per finalist with questions about what went wrong, and pay for a small discovery phase or pilot before signing the main contract. Score every firm on weighted criteria rather than comparing proposals by feel.

What questions should I ask a software development company?

Ask how they test and deploy code, how they handle security and vulnerability disclosure, who will actually work on your project and for how long, who owns the code, data, and cloud accounts, what happens if the engagement ends, how they estimate and how often estimates are wrong, and to walk you through a past project that had problems.

Should I pick the cheapest software development bid?

No. The lowest bid is frequently the one that omits discovery, testing, documentation, deployment, or support, which later appear as change orders. Normalize what each proposal includes, then compare price only among firms that clear a minimum score on delivery track record, process, and engineering practices.

What is a paid discovery phase and why does it matter?

A paid discovery phase is a short, fixed-scope engagement, typically two to four weeks, in which the vendor produces a written specification, architecture outline, risk register, and a firm build estimate. It replaces a proposal guess with a specification-based estimate, gives you a deliverable you own regardless of who builds it, and tests how the team works with yours before a large commitment.

How important is industry experience when choosing a development partner?

Problem-space experience matters more than industry experience. A firm that has built order management or scheduling systems for another sector usually transfers well; a firm from your industry that has only built marketing websites does not. Weight relevant delivery track record heavily, but define relevance by the type of system, integrations, and complexity.

Who should own the source code in a custom software contract?

You should. The contract should state that intellectual property in the code, the data, and the infrastructure configuration transfers to you on payment, and that repositories, cloud accounts, and domains are held in accounts you control. Vendor-retained ownership or vendor-only hosting access is a disqualifying red flag.