Pilot a golden path with one willing team, one real journey and a fixed window of a few weeks. Agree up front what success looks like, collect feedback weekly, and decide at the end whether to widen, change or stop. A pilot is cheaper than a launch that misses.
Why pilot at all
DORA lists the "big bang" release as a common antipattern: attempting to build an all encompassing platform before releasing anything is high risk, because by the time the perfect platform launches, developer needs have likely changed. It also warns about building without user research. A pilot addresses both.
Choose the pilot team
Look for a team that:
- ships often enough to feel friction quickly,
- has an owner willing to give blunt feedback,
- uses the stack your road supports, and
- is not in the middle of a critical release.
Avoid picking the team that already loves the platform group. Their feedback will be kind.
A four week plan
| Week | Focus | Output |
|---|---|---|
| 1 | Map the journey and set a baseline | Steps and timings for the current way of working |
| 2 | Move the pilot service onto the road | A running pipeline with checks in report mode |
| 3 | Review findings and tune | Noise removed, one or two checks set to block |
| 4 | Retrospective and decision | A short write up and a go, change or stop call |
DORA suggests mapping out critical user journeys, such as spinning up a new service, to find the biggest points of friction. The baseline in week one is how you will know the road improved anything.
Decide the exit criteria before you start
Write three or four statements that you can check. For example:
- Time from "create service" to first green security check is lower than the baseline.
- The team did not need to file a ticket for the common case.
- The pilot team would choose the road again for the next service.
- Open exceptions are listed with an owner and a reason.
Keep the feedback loop short
Ask for feedback weekly, in person if you can. DORA's 2025 data found clear feedback on the outcome of tasks was the platform capability most correlated with a good user experience, so look closely at how failures are explained to the pilot team. If they have to ask what a message means, rewrite the message.
Expect a bumpy start
DORA notes that platform engineering often follows a J-curve: early gains, a dip as complexity increases, then recovery as the platform matures. Tell stakeholders in advance so a rough week two does not end the pilot.
After the pilot
Write down what changed, publish the road's page, and invite the next team. Do not widen until the first team is happy, since their word of mouth is your strongest adoption channel.
Where Safeguard fits
Safeguard's policies let you start checks in a non blocking mode and tighten them later, and its CLI and IDE plugins give pilot developers findings where they already work. You can try a free scan at gold.safeguard.sh/scan.
Quick check
How big should a pilot team be?
One team with one or two services is plenty. More services add noise without much extra learning.
What if the pilot team wants to leave the road?
Treat it as data. Find out what the road lacked, fix it if the cause is general, and record an exception if it is not.
Sources
Last reviewed: 19 October 2026.
