Overview
Crash Override gives engineering and security teams visibility across the software delivery lifecycle by tracking builds, deployments and the code behind them.
Customer feedback showed that existing integration-led setup was actively blocking proof-of-concepts, often requiring elevated permissions, security review and sign-off from platform owners. Prospects were therefore unable to experience the product’s value while waiting on dependencies outside their control. Existing onboarding also relied on Customer Success to create an organisation before setup could begin.
I led the end-to-end product design for the onboarding redesign, working with Product, Customer Success and Engineering to reduce friction and get customers to their first tracked build as quickly as possible.
The opportunity
The key reframing was that source-control and cloud integrations enrich Crash Override’s evidence, but are not prerequisites for tracking a build and experiencing its core value. Instead of making customers complete a broad implementation before they could evaluate the product, onboarding could start with one CI/CD workflow: a lower-effort, lower-permission path to meaningful value.
This was enabled by surfacing API-token authentication for GitHub Actions and GitLab CI/CD, allowing customers to add tracking without first integrating with their SCM platform.
This also required reframing onboarding as an ongoing journey rather than a checklist with a fixed endpoint. Reaching the first tracked build marked initial activation, not a complete implementation: customers could be receiving value while Crash Override still had visibility into only part of their software estate. The opportunity was to make that progress visible and guide customers towards the next most meaningful step in expanding coverage over time.
Tailoring setup to each customer
I redesigned onboarding around a self-serve start, removing the need for Customer Success to create an organisation before setup could begin.
From there, a short set of questions captures areas such as CI/CD platforms, build types and cloud infrastructure. These answers allow the subsequent experience to reflect the customer’s actual technology stack, surfacing relevant options and pre-populating later configuration.
Making the first tracked build the activation milestone
Onboarding now prioritises a first tracked build over complete setup. Customers add tracking to one CI/CD workflow, trigger a build and begin exploring real data — without first configuring source-control or cloud integrations.
To make this possible for GitHub Actions and GitLab CI/CD, I surfaced an existing API-token authentication path. Previously, guided setup only offered OIDC authentication, making an SCM integration a prerequisite; the new flow removes that dependency during a POC.
This creates a much shorter path to value: Configure one workflow → run a build → explore your build data. Only after demonstrating that initial value does onboarding progressively introduce the integrations and configuration required to enrich the experience.
From initial activation to progressive coverage
I designed the Getting Started dashboard as the place where customers could move beyond their first tracked build at their own pace. The goal was not to present setup as a checklist to complete, but to make the relationship between each action and broader software-estate visibility clear.
Previously, customers were redirected across separate integration pages, where they had to re-select platforms, configure each service in isolation and navigate back without a clear sense of overall progress.
With the customer’s technology stack already captured during initial setup, relevant platforms can be pre-selected and the required configuration steps presented directly on the dashboard. Tracking, integrations and supporting guidance all remain within the same experience, including permissions, prerequisites and documentation.
The dashboard makes progressive coverage visible: customers can see what is complete, what comes next and how much of their software estate Crash Override can see. This lets them recognise the first tracked build as an important activation moment while understanding the path towards a more complete implementation.
Outcome
The redesign changes onboarding from an integration-heavy configuration checklist into a progressive activation journey. Prospects can prove Crash Override’s value through a single tracked workflow before navigating the permissions, approvals and technical work required for a broader rollout. Customers then receive guidance tailored to their environment and a clear view of how each next step increases pipeline visibility.
Customer Success and design partners validated that the new flow removes a key source of POC friction: it lets evaluation teams make progress independently, rather than waiting for cross-functional approval to connect SCM or cloud platforms. The resulting experience creates a more credible path from initial product value to complete software-estate coverage.
