How to evaluate a software development company: 12 checks

To evaluate a software development company, judge three things: can they actually build it, will they be a reliable partner, and are the commercial terms sound. Most buyers over-index on the sales pitch and the portfolio gloss. The signal that predicts a good outcome is more specific: delivered production work, direct access to the engineers, honest answers about process, and clear ownership terms. Here are twelve checks, grouped so you can score vendors side by side.

Can they actually build it

1. Ask to see a production codebase they maintain today. Not screenshots, a real product that is live and that they still support. Anyone can show a demo; maintaining software over time is the harder skill.
2. Interview the engineers who will do your work. The people in the sales meeting are often not the people who write the code. Ask to meet the actual team and gauge how they think.
3. Check references on projects like yours. A great e-commerce build tells you little about your lending platform. Ask for references in your domain and call them.
4. Understand their testing and code-review process. Ask how code gets reviewed, how they test before release, and how they catch regressions. Vague answers here usually mean vague quality.

Will they be a reliable partner

5. See how they handle scope changes. Requirements always move. Ask what happens when they do, and whether the answer is a fight or a process.
6. Check communication and time-zone overlap. For a distributed team, confirm working-hours overlap and the rituals (demos, standups, written updates) that keep a remote project honest.
7. Look at team stability and depth. A partner with real bench strength can absorb a departure. Ask how long their engineers stay and what happens if one leaves mid-project.
8. Judge how they handle "you do not need us for this." A partner willing to tell you the cheaper or simpler path, even when it costs them the work, is worth more than one who says yes to everything.

Are the commercial terms sound

9. Confirm who owns the code, repositories, and credentials. You should own all of it. Get IP and code ownership in writing before work starts, not at the end.
10. Match the contract model to the work. Well-defined projects can suit fixed price; evolving ones fit time and material. Our guide to fixed price versus time and material walks through the trade-off.
11. Insist on scope before a firm price. Any partner who quotes a hard number before understanding your requirements is guessing. A short discovery step protects both sides.
12. Read the maintenance and handover terms. Confirm what happens after launch: who fixes bugs, what support costs, and how a clean handover would work if you ever part ways.

Score it, and time-box it

Twelve checks are only useful if they produce a decision, so turn them into a scorecard. Score each check 0, 1, or 2: zero for a fail, one for a partial or unverified answer, two for a clear pass with evidence. Weight the capability checks double, since a pleasant partner who cannot build is still the wrong partner. Comparing three vendors on the same sheet turns a gut feeling into something you can defend.

Two refinements make the scorecard honest. First, treat a few checks as disqualifiers regardless of total score: no access to the engineers (check 2), no production codebase to show (check 1), and no written code ownership (check 9) each end the conversation on their own. Second, score only on evidence you actually saw, not on assurances. "We will share references later" is a one, not a two.

The whole evaluation fits in about two weeks without heroics. Days one and two: send the same brief to every vendor. Week one: collect responses, discard the generic ones, and hold first calls with the rest. Week two: interview the engineers, walk through a production codebase, call references, and confirm commercial terms in writing. A vendor who cannot move at that pace during the sale is telling you something about the project.

Turn the checks into a decision

The fastest way to make these checks productive is to give every vendor the same, clear brief, then compare their answers. A tight brief surfaces the good partners quickly, because they respond with sharp questions rather than a generic proposal; our guide on writing a project brief developers love covers how to build one.

If you are weighing a dedicated team or an extended engineering team, run the twelve checks against them exactly as you would any vendor, and ask to see the work they have delivered. The partners worth hiring will welcome the scrutiny, because the same evidence that reassures you is the evidence they are proud of.