Trial Project Software Vendor: How to Test One
How to run a trial project with a software vendor: pick the project, scope it to two weeks, measure what matters and set exit terms before you sign.
AI Engineer, Viithiisys
Why does a paid trial project beat a reference call?
A reference call shows how a vendor treated someone else's project. A paid trial project shows how they treat yours, with your codebase, your approvals and your deadlines, before you sign anything larger.
What a reference call cannot tell you
References are chosen by the vendor, so they skew positive. They also describe the past: a team that delivered well in 2023 may have lost its lead engineer since. A trial shows you the people who would actually staff your work, on a problem you picked.
What the public evidence says
No credible public source publishes a trial-to-full-engagement conversion rate for software vendors, so this post does not quote one. What does exist is guidance on buying in smaller pieces: the US government's TechFAR Hub documents agile and modular contracting as a way to limit the risk of a single large award. The same logic applies to a private buyer. Small, bounded purchases make a bad match cheap to discover.
How do you choose the right first project (three criteria)?
Pick a project that is real, bounded and testable. If it fails any one of the three, it will tell you little about the vendor and a lot about your own preparation.
Criterion 1: It is real work you would ship
A toy exercise gets toy effort. Choose something that will go into production or into an internal tool people use, so the vendor works under real review and real constraints.
Criterion 2: It is bounded and self-contained
Good candidates are a single integration, an internal dashboard, a document-processing step or one well-understood feature. Avoid your core platform, anything touching payments, and anything that needs six stakeholders to agree on requirements.
Criterion 3: It has a testable definition of done
Write acceptance criteria that a QA engineer could check without asking you a question. If you cannot, the project is not ready to be a trial. A vendor's QA and testing practice shows up quickly when the acceptance criteria are specific.
How do you scope a trial project to two weeks, not two months?
Cap the trial at two weeks of calendar time with a fixed scope, one named owner on each side and a demo on the last day. Anything longer stops being a test and becomes an unpriced commitment.
Why two weeks is enough
In ten working days you can see sprint planning, daily communication, a code review cycle, a deployment and at least one change request. That covers nearly every behaviour that separates a good vendor from a poor one. Month two mostly repeats what month one already showed you.
What to cut
Cut anything that needs discovery to be finished first. Cut polish, edge-case coverage beyond the agreed criteria, and any scope that depends on a third party you do not control. A trial that includes "and also integrate with the legacy ERP, whenever its owner replies" will measure your ERP team, not the vendor.
Scope it before it is quoted
A vendor should scope the trial in a short call, then quote against that scope. If the quote arrives before anyone asks you a question, treat that as a data point.
What to measure: velocity, communication, defect rate
Track three things: how much working software arrives and when, how the vendor communicates, and how many defects you find against the agreed criteria. Write targets down before day one, not after the demo.
Velocity: working software, not hours logged
Measure what was delivered against what was promised in the scope. The DORA research programme defines four delivery metrics, including lead time for changes and change failure rate. Even in a two-week trial, lead time from commit to a deployed environment is worth asking for.
Communication: response time and honesty about problems
Note how quickly questions get answered and whether bad news arrives early. A vendor who reports a blocker on day two is worth more than one who reports a miss on day ten. Count the surprises.
Defect rate: found by you versus found by them
Run the acceptance criteria yourself and log every defect. Also note whether the vendor's own tests caught problems first. If you want a consistent standard to hold code against, ask which practices the team follows from NIST's Secure Software Development Framework.
| Dimension | What to record | Healthy signal | Warning signal |
|---|---|---|---|
| Velocity | Scope delivered vs promised, deploy lead time | Working demo on the agreed day | Scope quietly shrinks near the end |
| Communication | Reply time, early flagging of blockers | Problems raised within a day | Surprises at the demo |
| Defect rate | Defects you found vs defects they found | Their tests catch most issues | You are the only tester |
What exit terms protect you?
Agree before day one that you can stop at the end of the trial with no penalty, own everything produced and keep full repository access. Those three terms turn the trial into a real option rather than a soft lock-in.
Ownership of the code
In the US, software written by an independent contractor is generally not a work made for hire unless it fits narrow categories and a signed agreement says so, as the US Copyright Office's circular on works made for hire explains. Do not rely on assumption. Get a written intellectual property assignment that covers the trial deliverables.
Access, handover and notice
Host the repository in your own account from the first commit, so the vendor commits into your infrastructure rather than handing you a zip file. Require a short handover note: how to run it, how to deploy it, what is unfinished. Set a fixed notice period for stopping, ideally none at the end of the trial.
Confidentiality and credit
Add a mutual non-disclosure agreement. Settle whether the trial fee is credited against a later build, because it is far easier to agree that now than after the demo.
What will a good vendor agree to?
A good vendor will agree to a fixed scope, a paid trial, your repository, a written ownership clause and a demo on a set date. Resistance to any of these is the most informative result of the whole exercise.
A vendor's willingness to be tested on your terms tells you more than any case study they can send you.
Terms to expect without a fight
Fixed scope and fixed date. Code in your repository. Named engineers, not "the team". A written assignment of intellectual property. A candid estimate, including what they would cut.
How Viithiisys structures a first engagement
Viithiisys has shipped software since 2007, with 500+ projects delivered for clients such as Paytm, Snapdeal, IKEA, Nestle, Shiprocket and Vikram Solar, from Mohali with a Canadian office in Markham, Ontario. For founders who want a bounded first step, Moonship delivers a working MVP in 30 days against a fixed scope. Smaller trials are scoped after a discovery call, never quoted before one. You can see the type of work in our case studies, or look at how we approach custom software development.
Ready to run one?
If you already have a workflow that keeps breaking, start by assessing the broken workflow so the trial targets a real problem. If you would rather talk the scope through first, contact us and describe the small project you have in mind.
FAQ
- How long should a trial project with a software vendor last?
- Two weeks is the practical sweet spot. It is long enough to see several delivery cycles, a code review loop and at least one change request, and short enough that a poor result costs you little. Past four weeks you are no longer testing the vendor, you are building the product.
- Should I pay for a trial project or ask for a free pilot?
- Pay for it. A free pilot gets the vendor's sales team, not its delivery team, and neither side has a reason to treat it as real work. A paid, scoped trial produces working code, honest estimates and a fair read on how the vendor behaves when money and deadlines are involved.
- What is a good first project for testing a development agency?
- Choose something real but non-critical: a self-contained feature, an internal tool or an integration with a clear interface and a testable definition of done. Avoid your core platform and avoid anything with unresolved requirements, because a vague brief tests your product thinking rather than the vendor.
- Who owns the code if I end the trial early?
- You should, in writing, from the first commit. Put an intellectual property assignment, repository access in your own account and a handover of documentation into the trial agreement. If the vendor will not sign that for two weeks of work, that is useful information about the longer engagement.