Stop a trial turning into free consulting by writing down the scope, limiting custom work to what the success criteria need, logging every hour either side spends and refusing one off services that you could not get after purchase. A fair trial shows the product, not an engineer you will not have later.
What the problem looks like
It starts helpfully. The vendor's engineer writes a custom parser for your odd build system. Then a custom report. Then a small script to tag findings. By week three the results look excellent, and nobody remembers that a person made them look that way.
The risk is not dishonesty. It is that you will judge the tool by a level of attention you will not get once you are one of many customers.
Five guardrails
1. Scope in writing
List what is in the trial and what is out. A short list works: three repositories, one CI integration, one ticketing integration, two weeks of scans. Anything outside the list needs a note and a reason.
2. A "no special work" rule
Agree up front that you will test the product as configured with documentation and normal support. If the vendor does custom work, record it as a finding: "needed a custom parser" is a real result and belongs in the scorecard.
3. An hours log
Track vendor hours and your hours on every task. At the end you can answer two questions: how much effort did setup take, and how much of it was vendor labour that will not repeat?
| Task | Your hours | Vendor hours | Documented step? |
|---|---|---|---|
| CI integration | 3 | 1 | Yes |
| Build parser fix | 1 | 6 | No |
| Ticket mapping | 2 | 0 | Yes |
Anything with a "No" in the last column is a risk to score.
4. A fair support test
Support is part of the product, so test it as an ordinary customer. Open tickets through the normal channel. Note how long the first useful reply takes. A direct line to a sales engineer is nice, but it is not the support model you are buying.
5. A clear exit
Decide what you owe the vendor at the end: an answer, not a contract. Say so kindly at kickoff. A vendor who supports a fair trial will not mind.
What you owe in return
Fairness works both ways. Give the vendor clear criteria, timely access and honest feedback. Do not run a trial just to collect ideas for building the capability in house, or to extract a free proof for a tool you have already chosen. If you have already decided, say so and save everyone's time.
When custom work is acceptable
Some customisation is normal in the real product, such as writing policy rules or mapping fields to your ticket workflow. The test is simple: could you do this yourself after purchase, using documentation? If yes, do it yourself in the trial. If it needs the vendor's help, ask whether that help is included in the contract or billed separately, and get the answer in writing.
A note on professional services
Some vendors sell onboarding services. That can be good value. Keep it separate from the trial, so the evidence you gather reflects the product, and so that a services quote does not colour your technical score.
Safeguard's free scan is an example of a self serve starting point: you run it yourself on your own project and see the output without anyone preparing it for you.
Quick check
Is custom work during a trial always a red flag?
No, but it must be recorded. Score what a normal customer could do alone, and note separately what needed vendor labour.
How do I log vendor hours?
Ask the vendor to share rough hours per task in a weekly note, and add your own. Compare totals at the readout.
Last reviewed: 19 October 2026.
