How to choose a software development partner / Vet a partner
How to run a paid trial project before you commit
References and interviews only tell you so much. A small, paid, real piece of work tells you how a team actually builds, communicates, and handles the difficult middle stage. It is the most informative vetting step you can take, and it is worth paying for.
Published July 27, 2026. Editorial.
Key takeaways
- A small paid trial reveals more than any pitch or reference call.
- Scope it as real work with a clear outcome, not an artificial test.
- Watch how they communicate and handle surprises, not just the final deliverable.
- Judge the trial on how the work felt and how well it kept working, then decide on the larger engagement.
You can interview a team for hours and still not know how they build. The fastest way to find out is to watch them do a small piece of the real thing. A paid trial project replaces a guess with evidence, and the cost of the trial is small compared with the cost of committing to the wrong partner for a year.
Why paid, and why real
Make it paid. A free trial attracts the wrong incentives on both sides and does not reflect how the team behaves when there is real accountability. Pay for the work and you get their real process, and you have a clean, professional relationship from the start.
Make it real. An artificial test does not tell you much, because real software work is about handling ambiguity and change, and a practice problem has neither. Pick an actual, bounded piece of your roadmap: a self-contained feature, a well-defined integration, a part of the product that works on its own. Real work with real consequences shows how the team actually behaves.
How to scope the trial
Choose something small enough to finish in two to four weeks and complete enough to work on its own. It should have a clear outcome you can judge, some genuine ambiguity so you see how they handle it, and few enough dependencies that they can actually deliver it without waiting on the rest of your roadmap. Write down what "done" means before they start, so you and they are judging against the same standard. The how to scope the first project page says more about scoping, and the same principles apply here.
What to watch while it runs
The deliverable matters, but how the work felt matters just as much, because that is what you will deal with for the whole engagement. Watch how they communicate: do you know the status without having to ask them repeatedly? Watch how they handle the first surprise, because there will be one: do they raise it early and propose a plan, or say nothing and hope it goes away? Watch whether they object when you ask for something that will hurt you later, or just say yes. And watch whether the senior people you were promised are actually the ones doing the work.
How to judge the result
At the end, ask three things. Did they deliver the outcome you agreed on, or explain honestly why it changed? Did working with them feel clear and calm, or did you spend energy managing them? And would your own engineers be comfortable owning what they built? A trial that delivers a decent result through a painful process is a warning, because the problems grow as the engagement grows. A trial that delivers well and felt easy is the strongest reason to hire them that you can get.
From trial to partnership
If the trial goes well, you have vetted a team and also started working as one. They now know a part of your product and your people, so the larger engagement starts at full speed instead of from zero. If the trial goes badly, you have learned that for the price of a few weeks rather than a year. Either way you made the big decision on evidence instead of a pitch, which is the whole point. Use what you learned with the main guide and decide with confidence.
Common questions
Should I run a trial project before hiring a development partner?
Yes. A small, paid, real trial project is the most informative way to vet a partner. It shows you how they build, communicate, and handle surprises, which no pitch or reference call can, and the cost is small compared with committing to the wrong partner.
How big should a trial project be?
Small enough to finish in two to four weeks and complete enough to work on its own, with a clear outcome, some genuine ambiguity, and few dependencies. Define what done means before they start so both sides judge against the same standard.
What should I watch for during a trial project?
How they communicate, how they handle the first surprise, whether they object to choices that would hurt you, and whether the senior people you were promised are doing the work. How the work feels predicts the whole engagement, not just the deliverable.
Should a trial project be free or paid?
Paid. A free trial attracts the wrong incentives on both sides and does not reflect how the team behaves when there is real accountability. Paying for the work gets you the team's real process and starts the relationship as a clean, professional arrangement from day one.
How do I judge whether a trial project went well?
Ask three things: did they deliver the agreed outcome or explain honestly why it changed, did working with them feel clear and calm, and would your own engineers be comfortable owning what they built. A result delivered through a painful process is a warning sign, since the problems grow as the engagement grows.
What should I define before a trial project starts?
Write down what done means before work begins, so you and the partner are judging against the same standard. The trial should also be small enough to finish in two to four weeks, with some genuine ambiguity so you can see how the team handles it.
Should a trial project be an artificial test or real work?
Real work. An artificial test does not tell you much, because real software work is about handling ambiguity and change, which a practice problem has neither of. Pick an actual, bounded piece of your roadmap, so real work with real consequences shows how the team actually behaves under pressure.
What happens after a trial project goes well?
You have vetted a team and also started working as one. They already know a part of your product and your people, so the larger engagement starts at full speed instead of from zero, which is the benefit of paying for real work upfront rather than a sales pitch.
More in Vet a partner
Questions to ask a software development partner before you hire
A good pitch tells you a company can sell. It does not tell you they can build. These questions change the conversation from the sales pitch to how the team actually works, which is the only thing that predicts how your project will go.
How to evaluate a development team's engineering quality
You do not need to be an engineer to judge engineering quality. You need to know which signals to look for. The strongest ones are how a team makes decisions, how they handle change, and whether their past work still runs well for the people who own it now.