Your own engineers should drive the keyboard in a security tool trial. If a vendor engineer configures everything, you are measuring that person's skill, not the product's usability. Let the vendor answer questions and fix defects, but have your team do setup, scanning and triage using public documentation.
What goes wrong when the vendor drives
Sales engineers are very good at their product. They know the right settings, the right order and the workarounds. A trial run entirely by them produces results you will not reproduce after you sign, because nobody from the vendor will sit beside your developers every week.
You also lose information. Every moment of confusion that a vendor engineer smooths over is a moment your team would have faced.
A simple split of roles
| Task | Who does it | Why |
|---|---|---|
| Connect repositories, set up access | Your platform engineer | Shows real setup effort |
| Run scans, read results | Your security engineer | Tests the reading experience |
| Triage a sample of findings | A developer who owns the code | Tests developer fit |
| Answer product questions | Vendor | Saves time on dead ends |
| Fix confirmed defects | Vendor | Their job |
| Decide pass or fail | Your named owner | Keeps accountability |
Write this in the trial plan and share it with the vendor.
Rules that keep it fair
- Your team starts from the public documentation, with no live walk through first.
- Any help from the vendor is logged: what was asked, what was answered, how long it took.
- If the vendor makes a configuration change, a person from your side watches and records it.
- Vendor help counts as effort in your scorecard. A product that needs a lot of help scores lower on ease of use.
- Anything the vendor adds during the trial, such as a custom rule, is noted as a dependency.
This keeps the vendor helpful without letting them become the operator.
Count the help
At the end, tally the help log. How many questions were about missing documentation? How many hit defects? How many were requests to change settings you could not find? That tally is a good predictor of your support load after purchase, and it is a fair thing to discuss with the vendor.
Where hands on help is fine
Some things are legitimately vendor led: a security review call, architecture questions, and data handling clarifications. The line is simple. If a task would be part of your weekly routine after purchase, your team should do it in the trial.
A short example
Imagine two trials of the same product. In one, a vendor engineer connects everything in an hour. In the other, your platform engineer needs a day, hits two unclear permission prompts and files a documentation request. The second trial looks worse, but it is the one that predicts your experience. Record it, share it with the vendor and see how fast they close the gaps.
Where Safeguard fits
If you try Safeguard, the same approach applies. Your engineers can start unaided with the free scan at gold.safeguard.sh/scan, and note anything the documentation does not answer.
Quick check
Is it wrong to ask the vendor for a setup call?
No. Log it as help received, and make sure your own team does the hands on work.
What if our team lacks time?
Shorten the scope, not the independence. A smaller trial run by your team beats a larger one run by theirs.
Last reviewed: 19 October 2026.
