Cover the journeys developers repeat most and where a mistake costs the most, usually creating a service, adding a dependency, changing code, deploying, and responding to a security alert. Start with one, make it clearly better, then add the next. DORA recommends mapping critical user journeys to find the biggest points of friction.
What a journey is
A journey is a task a developer performs from start to finish, such as "create a new service" or "debug a production issue", the two examples DORA gives. Mapping them tells you where time is lost and where security can be built in without extra steps.
Five candidate journeys
| Journey | Security work to build in | Friction to remove |
|---|---|---|
| Create a service | Safe template, shared pipeline, repository rules | Manual setup and ticket queues |
| Add a dependency | Check against policy at the pull request | Waiting for an approval email |
| Change code | Code scanning with clear results | Noisy findings that do not apply |
| Deploy | Gate with defined criteria | Unclear block reasons |
| Respond to an alert | A fix suggestion and an owner | Hunting for who should act |
How to choose the first one
Score each journey on three questions:
- Frequency. How often does it happen across teams?
- Pain. How much time or frustration does it cause today?
- Risk. What is the cost of getting it wrong?
Creating a service is often the first pick. It happens at the start of a project, it sets defaults for everything that follows, and the template and pipeline are easy to ship. Adding a dependency is a strong second, since it is frequent and directly tied to supply chain risk.
Map before you build
- Pick two or three teams. Different stacks give a fuller picture.
- Ask them to walk through the journey. Time each step and note waits.
- Mark the security steps. Which are manual, which are skipped, which cause delay?
- Choose the smallest change that helps. DORA suggests building just enough to make that journey demonstrably better.
- Measure the same steps after. Compare timings with the baseline.
Journey two: code changes
Code scanning on a pull request is a frequent journey. The value depends on result quality: a scanner that reports many findings that do not matter teaches developers to dismiss it. The demo below shows a code scan result, which you can use to think about what a developer would see.
Try it yourself
Click through it at your own pace, or open it full screen. Ask yourself whether each finding tells the developer what to do next.
Do not forget the journey of a security engineer
Developers are not the sole users. Security and compliance staff also have journeys: reviewing an exception, preparing evidence for an audit, checking coverage. A road that makes their work easier makes the whole program sustainable.
Where Safeguard fits
Safeguard covers several of these journeys: SBOM and dependency scanning for added packages, policies and gates on pull requests, and compliance and evidence automation for audits. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Should I cover all journeys before launch?
No. DORA warns against big bang releases. Ship the first journey, learn, then add the next.
How many teams should I interview?
Two or three with different stacks is enough to see the common friction.
Sources
Last reviewed: 19 October 2026.
