How to Vet a Software Development Company Before You Sign a Contract

Vetting Starts Where the Sales Pitch Ends

Every software development company's sales team is good at describing how they work. Learning how to vet a software development company means checking whether that description is true before you're financially committed to finding out the hard way. The uncomfortable truth is that a slick sales process and strong engineering delivery are almost uncorrelated — the person who sold you the engagement is often not the person who will write your code, and their incentive is to close the deal, not to accurately represent the team's day-to-day capability. If your process ends when the proposal looks good, you haven't vetted anything; you've read marketing copy.

Ask for a Paid Trial, Not a Free Sample

The single highest-signal thing you can do before signing a multi-month contract is run a paid two-to-four week trial sprint with the actual engineers who would work on your project, not a solutions architect who disappears once the contract is signed. Pay for it — free samples get you the agency's best available person for a demo, not the person staffed on you for the next six months. A trial sprint tells you three things a proposal never will: whether the estimates you got were realistic, whether the team asks the right clarifying questions about your product, and whether the code they hand back is something a different engineer could pick up without you.

A trial sprint is also the only way to see how a team handles ambiguity, which matters more than how they handle a well-specified task. Anyone can execute a perfectly clear ticket. What you actually need to know before a six-month commitment is what happens when the spec is incomplete — do they ask a clarifying question, make a reasonable assumption and flag it, or just guess and ship something that technically matches the ticket but misses the point. That behavior under ambiguity is close to impossible to assess from a proposal, and it's the behavior that determines how painful the next six months will actually be.

Check Who You'll Actually Be Talking To

Ask, explicitly, who your day-to-day point of contact will be, and ask to meet that person before you sign — a real conversation, not a bio. A shocking number of contracts get signed after conversations with a founder or a VP of sales, and the client never speaks to that person again once delivery starts. If the company can't tell you specifically who's staffed on your project and can't get that person on a call within a few days, that's your answer about how the engagement will actually run once the invoice is paid.

Verify the Technical Claims, Don't Just Trust Them

If a company claims a particular tech stack, a particular hiring bar, or vetted senior engineers, ask for evidence you can independently check — a GitHub profile, a technical assessment they'll walk you through, a reference client you can actually call, not one hand-picked and coached beforehand. Any company confident in its own engineering quality will not flinch at this; the ones who get defensive about a technical vetting request are telling you something.

It's also worth checking claims about process, not just claims about people. If an agency says it does code review on every pull request, ask to see what that actually looks like — a real review thread, not a description of the policy. If it claims automated testing and CI, ask what the coverage looks like on a comparable past project. Process claims are cheap to make in a sales deck and expensive to fake in practice, which is exactly why asking for the artifact instead of the description is such a reliable filter.

A proposal tells you what a company is willing to promise. A trial sprint tells you what they're actually able to deliver — and those two things are rarely the same size.

Read the Contract for Ownership and Exit Terms, Not Just Price

The price on a proposal is the easiest thing to compare and the least important thing to get wrong. What actually protects you is the contract language around code ownership — do you own everything from day one, or only after final payment — IP assignment, what happens if you need to pause or exit, and whether a notice period lets you transition to another team without losing continuity. A company that looks good on price and terrible on these terms will cost you far more than the rate difference ever would.

Use the Vetting Process to Predict the Working Relationship

How a company vets you back — the questions they ask about your product, your users, your constraints — during their own sales process is a preview of how they'll actually work with you once the contract is signed. Teams that ask sharp, specific questions before you've paid them anything keep asking those questions once they're building. Teams that agree to everything you propose are telling you they haven't thought about it, or don't plan to push back when it matters. Vetting a software development company isn't a single yes/no gate — it's the first real sample of the relationship you're about to commit months of runway to.

For a closer look at how an engagement actually runs, see our delivery process.