Engineering teams that continuously deliver

On average we ship to production tens of times a day – and sometimes double that.

It’s safe to say that at Sibi, shipping is our heartbeat. We love quick iterations that refine our assumptions based on our learnings. That said, it’s not a madhouse. We lean heavily on feature flags and testing in production. If something goes wrong, we’re able to simply turn it off. We view everything we write as a hypothesis, and the goal is always to validate our assumptions in tiny bits and learn from each iteration. At the end of the day, if something goes wrong, recovery time is always more important to us than perfection. We work hard to create an environment where it’s safe to fail (see above).

Speed is the ultimate weapon.

We have a live test environment for every pull request and our latest “main” branch is always auto-deployed to our staging environment. We have one-click deployment to production and employ code reviews for every change, big or small. We invest into creating an excellent development and delivery experience to ensure users are constantly delighted with our progress (and so that we ourselves can enjoy working on our product!).

CI shouldn’t take more than 30 minutes to run – ideally less than 20.

We often ship to production multiple times a day and invest in automated testing, monitoring, and reporting (we use CircleCI for CI/CD). Engineers own their code’s quality throughout the software development process and we avoid latency by keeping CI under 30 minutes. When Jeremy (VP of Eng) first started, it was taking an hour and a half. We invested resources, refactored, and it now takes around 12-15 minutes to run our full test suite, build, and deploy.

On time. On target. Our word is bond.

We work on sprints primarily around planning, but we push to production every day. We strive to efficiently prioritize the features in our development pipeline and deploy as quickly as possible. The quicker we have a feature out, the quicker we can start iterating to provide our users with the functionality they really want. That’s not to say we’re not pragmatic! We take test coverage seriously. Millions of end users depend on our app, so if a bug happens during checkout, we’re losing people real business.

Still, we’re not fearful about deploying (and deploying quickly) because we trust our deployment process. Abe and Andy are always on-call and everyone else on the engineering team is on a weekly rotation. If you’re on-call, you’ll cycle in to help with our error alert feed. This helps expose everyone to different parts of the codebase, yet everyone has support should they need help figuring out an issue.

Shipping is our heartbeat.

We have built a continuous integration system and strongly believe that our shipping velocity differentiates us from our peers. As an engineer, you can expect to push to production multiple times a day. We have a lightweight process to ship through the different stages of our pipeline and no explicit separate release is needed.

We also run a mature test suite on all code commits, which we monitor continuously with failures fixed within a certain SLA. Tests take minutes to run with an expectation that they should be fast, reliable, and not the long pole to pushing features.

Check out our roadmap, which we recently introduced to detail features as they are rolled out. We keep a tight feedback loop with our users, and build all features with them in mind.

We believe the best way for clients to see the value of our work is to put it in front of them.

Part of our first sprint on every project is to push an MVP version of their product. We do this through multiple avenues, whether it’s using Netlify Deploy, GitHub Actions, or TravisCI. Our chosen method of delivery depends on the client team and their product, but we believe it’s the most important step for getting the feedback we need and streamlining our development process.

We’re regularly thinking about how to roll out the smallest version.

It’s far better to constantly iterate with small changes than it is to build something new. We always do code reviews (typically from someone furthest from the code), and try to release bug fixes and deploy new features into production safely and quickly. We use per-PR sandboxes to easily test out changes during code reviews, use feature flags to guard larger changes, and a pre-prod staging environment for final testing before deploying to production. We don’t have a QA team, and our engineers own their code’s quality throughout the software development process by investing heavily in automated and manual testing, monitoring, and reporting.

We strive to ship quickly (multiple times per week and sometimes daily) without sacrificing quality as we have so much to get to in our product roadmap! We invest in our processes and people. In February 2022, we raised a $20M Series A, so if any of the above interests you, we encourage you to reach out and apply!

We deploy 10 times a day – and sometimes even more.

Our approach to continuous delivery is a core part of our product development process. From the beginning, we’ve invested in multiple levels of automated testing, monitoring, and reporting. For example, we build on Blaze, which allows for fast, deterministic builds. We use Kubernetes to have parallel builds and we have a test leaderboard where we remove flaky tests. Engineers are responsible for owning their code’s quality throughout the software development process. Pull requests are approved by one reviewer and then automatically merged into the queue and deployed. We also actively use A/B tests and feature flags to get code safely into production quickly and often.

We raised a $100M Series D in October 2021 and are excited about modernizing the insurance industry. If working in a fast-paced, mission-driven environment speaks to you, we encourage you to check out our open roles!