How to Vet a Software Development Partner: 10 Questions to Ask Before You Sign
Hiring an external software team is one of the highest-leverage decisions you'll make as a founder or product leader. Get it right and you ship a secure product fast, with a partner who tells you the truth and hands you the keys. Get it wrong and you spend six months and a chunk of your runway untangling code you can't read, can't deploy, and don't legally own.
The hard part is that you usually can't tell which one you signed up for until the money's spent. So you have to do your vetting up front, in the room, before the contract. The questions below are the ones we'd ask if we were sitting on your side of the table.
Why this decision is hard to reverse
Switching software partners mid-build is brutal. The new team has to read someone else's code, guess at the decisions that aren't written down, and rebuild trust with you while the old work quietly rots. That handover alone can cost a third of what you've already spent, and it almost always slows you down for a month or two.
There's a deeper trap, too. Bad architecture and weak security don't announce themselves on launch day. They show up later, as the breach you have to disclose, the feature that takes three weeks because everything's tangled, the audit you fail right before a funding round. By then the team that built it is long gone. A few sharp questions now are cheaper than any of that.
The ten questions
1. Who actually writes the code?
You want the names and the seniority of the people who'll be on your keyboard, not the impressive folks who showed up to the sales call and then vanish. A good answer is specific: here's the lead, here's their track record, here's how many people and at what level. A bad answer is vague about staffing or quietly routes your project to subcontractors you never get to meet. Ask who reviews the code, too. If nobody senior is reviewing, you're the QA.
2. How do you handle security?
Listen for whether security is baked into how they work or bolted on at the end (if at all). A strong partner talks about threat modeling early, secrets management, dependency scanning, least-privilege access, and security as part of code review, not a one-time audit you pay extra for. A weak one treats it as your problem, or promises a "security pass" right before launch. We think shipping insecure software fast is just shipping a liability fast, and the right team will say something similar without being prompted.
3. What does "done" mean to you?
For some shops, "done" means it ran once on their laptop. For a serious partner, done means tested, deployed, monitored, documented, and actually working in production under real load. Push them to define it concretely: what's the test coverage expectation, who owns the deploy, what happens when something breaks at 2am. If their definition of done is fuzzy, you'll be the one discovering everything that wasn't included.
4. Who owns the code and the IP?
This should be a one-word answer, and that word is "you." Full IP ownership, your repos, your cloud accounts, your domains, all in your name from day one. Watch out for teams that host your code in their accounts, reuse proprietary frameworks you can never take with you, or get cagey when you ask to read the contract's IP clause. If you can't walk away with everything, you don't have a partner, you have a landlord.
5. How will you communicate and report progress?
Ask what a normal week looks like. You want a predictable rhythm: a standing check-in, a shared board you can read without a translator, and a direct line to the people doing the work. Be wary of teams that funnel everything through an account manager, go quiet for a week and then surprise you, or only ever report good news. Honest status reports include the things that are behind and why.
6. Can I see and run the code during the build?
The answer should be an easy yes. You should get access to the repo on day one and be able to pull the latest build and run it yourself, or at least click through a live staging environment whenever you want. Teams that only show polished demos on their own machines are hiding something, usually the gap between the demo and the reality. Continuous access is the single best protection against a nasty surprise at the end.
7. How do you handle scope changes?
Scope will change. The question is whether they handle it like adults. A good partner welcomes the conversation, tells you the cost and the tradeoff honestly ("we can add that, but it pushes the launch two weeks, here's why"), and lets you decide. A bad one either nickel-and-dimes every tiny request through change orders, or says yes to everything and quietly blows the timeline. You want someone who treats your budget and your deadline as if they were their own.
8. What happens after launch?
Launch is the start, not the finish. Ask what support looks like in the weeks after go-live, who's on call when production hiccups, and how a clean handover to your internal team would work if you brought one on. A team planning to disappear at launch will be vague here. The good ones tell you exactly how the relationship continues, and exactly how it can end without you getting stranded.
9. Can you say no to me?
This one tells you the most. A partner worth hiring will push back when you're about to make an expensive mistake, even when agreeing would be easier and more profitable for them. Ask for a time they talked a client out of something. If they can't think of one, they're either inexperienced or they're order-takers, and an order-taker will happily build you the wrong thing on time and on budget. You're paying for judgment, not just hands.
10. Can I talk to a past client?
Real references, with phone numbers, are the closest thing to a money-back guarantee you'll get. A confident team connects you with someone who'll speak candidly, ideally a project that had a few bumps so you can hear how they handled trouble, not just a glowing testimonial. Hesitation here, or only carefully curated references, tells you what their other clients would say if you asked them the hard questions.
Red flags to walk away from
The bottom line
The best way to read a partner is to notice how they act before you've paid them a cent. Do they tell you things you don't want to hear? Do they care whether the thing you're building is the right thing, or just whether the invoice clears? The answers to these ten questions are less about technical chops (most decent shops can write code) and more about whether they'll treat your product like it's theirs.
That's the bar. For the length of the build, the right partner thinks like a co-founder: on the hook for the outcome, honest when it's awkward, security-minded by default, and happy to hand you every key on the way out. Hire that, and the rest gets a lot easier.