WarpBuild’s value proposition is built around a fundamental invariant - everybody wants builds to be faster, and everybody wants things cheaper[1].
Now, that means our primary job shifts from convincing developers to use our product to making people aware of the fact that our product exists. This shortens the funnel significantly. Once the user signs up to try the product, the onus is on the onboarding flow to ensure there is no drop-off and that is a challenge we took up very seriously.
We laid out some principles to deliver on this promise:
- Onboarding must be trivially easy
- High degree of polish is required for the product, from day 1
- Speed is a feature and critical to developer experience
The onboarding process
Switching a GitHub Actions workflow to WarpBuild is a one line change in the workflow file. Easy right? Not really. It's very common for repositories to have tens or even hundreds of GitHub Actions workflows.
Our single highest priority for a signed up user is that we want all the user’s workflows to run on WarpBuild. Changing 100s of workflows manually is frustrating, obviously. Asking our users to do that would be conducive to exactly two things: having our users hate us and ensuring they don't switch workflows.
We set out to solve this while designing the UI to:
- Pull information from GitHub about the connected repositories. Then parse and display the workflows present.
- Raise a PR with the user selected runner configuration for all selected workflows in one click.
- Open the PR in a new tab so users can review and merge.
This is how our onboarding workflow looks like now and it worked brilliantly!
The results
We had users move 50+ workflows in a few minutes and got good HN karma because of this. Our users love it! While the numbers are small to provide statistically significant analysis, we continue to see very high funnel progression and conversion to paid usage.
📚 Check out the documentation here
⚡️ Get started with WarpBuild in 2 minutes here
[1] Variant of this quote by Jeff Bezos.