Engineering teams that continuously deliver

We are constantly learning and adapting.

A perfect implementation isn’t necessary when a good implementation delivers value. We believe in iterating and recognize that we won’t have all of the answers up front. By taking bold, but educated steps to collect more information, we build a trove of data to drive future decisions. Engineers submit GitHub pull requests, which trigger linting, testing, and code quality scans before allowing a reviewer to approve it. After it’s approved, the PR triggers CircleCI to deploy to different environments (staging, prod, etc.). Automating our deployment pipelines allows us to deploy multiple times per day to production.

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.

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.

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.

Engineering candidates will often ask us, “When do you deploy?” and our answer is, “Whenever we feel like it.”

At WorkOS, we’re building a modern API platform that empowers any developer to quickly build and ship enterprise features. Everyone from early-stage startups to Fortune 500 companies rely on our platform to build enterprise-ready apps.

We are the antithesis of a slow-moving, big, technology company. Our customers are engineers as well, which means they can speak with a level of technical precision that enables us to iterate faster. We move quickly. We deploy many times a day. We keep a tight feedback loop with our customers.

We have a very active codebase and solicit input from the entire engineering org.

The life cycle of a project often starts with product requirements and engineers writing up an engineering design review. Unlike at other startups, Color invites the entire engineering team to participate in the design review of every design. On Tuesdays, the whole org gets together for an hour to take a look at all of the proposed engineering designs and provide feedback. Not only is it a great way to get a broader set of eyes on our work, but it also helps avoid silos with other teams and supports continuous delivery by keeping feedback loops tight.

Since most teams work on a weekly (or bi-weekly) sprint cadence, engineering designs can be implemented and shipped quickly. Production code deploys twice a day and we rely on both unit tests and end-to-end testing to ensure code ships smoothly. Rather than having a QA team, we rely on engineers to own their code’s quality through the CI testing, monitoring, and reporting process. Hand in hand with our focus on continuous delivery, is an emphasis on delivering reliably, and we’re always working to improve the performance of our database and queries. We integrate and test daily. This unique blend of systems engineering and bioinformatics enables us to build a revolutionary product that can easily scale, while keeping costs low.

We’re intentional about our onboarding process and try to lift up the entire engineering org by passing down best practices. To be on the same page, we try to make the codebase a clean, pleasant place to be with practices like automatic linting and formatting. As Anastassia, one of our senior software engineers says about the codebase, “It’s a nice house to be in.”

We release several times a day, and you can have code live on the site in as little as 20 minutes.

We believe that speed is one of the attributes that sets an organization apart, and we strive to support our engineers in moving as fast as possible. We place a heavy emphasis on automated tooling so we can write quality code and have it live in production without worrying about lingering issues. Our tests and live deployment previews are automatically run and built on every push. This avoids the need to run all tests locally and saves you precious time on your local machine. Our CodeBuild pipeline verifies and builds your changes, while Lerna enables you to deploy after your tests have passed.

We value not only code quality, but also speed. Tasks should take two hours, two days, or two weeks (and it’s never two weeks). This speed helps us remain nimble and fix previous issues quickly, so they don’t fester.

We release to production every single day with no downtime.

We invested heavily in automation from day one, so now all it takes to deploy is to approve and merge a GitHub pull request. Our staging environment is continuously updated every time anyone merges their branch to main, so our engineers can test their changes within 10 minutes against a full replica of our production environment.

Feature flags play a big role in helping us stay safe while moving fast. No matter how large a feature, we implement it in parts and wrap it in a flag so we can enable it just for ourselves and our friends in the product team. While our code never touches servers unless it has sufficient tests, uncovering unknowns in an environment where it's safe to make mistakes is what, at the end of the day, keeps our promises to our patients and users.

Researchers and clinicians from some of the leading neuro labs and hospitals in the country count on us to ensure their work helps everyone affected by brain disease. We've built Rune on the soundest principles of infrastructure and code management so we can bring them the data they need.

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 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 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!