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 integration-led setup was actively blocking proof-of-concepts. Adding source-control and cloud integrations often required elevated permissions, security review and sign-off from platform owners — work that could not be completed quickly by the person evaluating Crash Override. 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 end-to-end product design for the onboarding redesign, partnering with the Product Manager, Customer Success and Engineering team to turn recurring POC feedback into a focused activation strategy, shaping the scope around reaching the first tracked build as quickly as possible. The resulting experience supports self-serve entry, rapid proof-of-concept setup, tailored guidance and a persistent dashboard for expanding coverage over time.
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 connecting their SCM platform, giving prospects a way to validate Crash Override during a POC while creating a natural path to deeper integration and broader coverage later.
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 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 each customer 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 this approach 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.
