Cased is your AI-native DevOps platform 🎛

CV Deep Dive

Today, we’re talking with Ted Nyman, Co-Founder and CEO of Cased.

Cased is a platform that simplifies deployments and operations for engineering teams, especially those in fast-growing organizations that may not have a dedicated DevOps team. Ted, who helped scale GitHub’s infrastructure and served as its CTO, founded Cased with the goal of bringing the same DevOps best practices used by top-tier engineering teams to everyone.

With Cased, teams can deploy more frequently, manage their apps, and implement DevOps best practices. Key features include branch deploys, which allow teams to ship quickly and safely, and post-deploy anomaly detection. By integrating with platforms like GitHub Actions, Cased makes it easy for developers to focus on their product while ensuring smooth, reliable operations.

In this conversation, Ted shares the journey of building Cased, their careful use of AI, how Cased emerged from a tool they originally built for themselves, and the impact it’s having on the way companies deploy software today.

Let’s dive in ⚡️

Read time: 8 mins

Our Chat with Ted 💬

Ted - welcome to Cerebral Valley! First off, give us a bit about your background!

Hey there! I’m the CEO of Cased. I've been in developer tools for most of my career. I started working at GitHub back in 2012. I was a systems engineer there, along with my co-founder Ben Bleikamp. He was actually my onboarding buddy at GitHub, although the main thing he did was show me where the snacks were in the office. Still a very good onboarding buddy. Before that I worked at BankSimple (later Simple), which was one of the first neobanks, and I built their initial services.

I was involved in scaling GitHub’s backend systems during heavy growth, and then I became GitHub’s first engineering leader, VP of Engineering, and then I was CTO after that. We founded Cased out of a lot of tech lessons we learned from GitHub.

What led you to co-found Cased?

While I was at GitHub, the focus was always on helping people write code. But I always felt like there was a lot of room to build better tools for what happens after you write code. Beyond just writing code, there’s the whole operations side—running things in production, debugging. Ben and I both had this idea of what it would be like to build better experiences for that.

At GitHub my focus was uptime, availability, and performance. People depended on GitHub for their basic operations, so we had to be as available as a utility company—or people would leave. Those things don't always get as much attention as flashy feature dev, but they’re critical for running websites and web applications at scale. So building a product for that was always something I found interesting. The big picture idea is that anyone should be able to run software well in production, deploy well—and also not necessarily have to pay a ton and get locked-in to a PaaS.

Give us a top level overview of Cased - how would you describe the startup to those who are maybe less familiar with you? 

Great deployments and DevOps for everyone with the right kind of AI built-in. When you think about developer tools, especially in DevOps, a lot of the advanced features are limited to those who already know how to run them. 

What we're aiming to do is bring all the benefits of modern practices to every engineer, without them having to run your software on a super expensive platform or become a full-time DevOps engineer.

The people getting the most value out of Cased right now are those in fast-growing organizations that don’t have a full DevOps team, but are still dealing with all the usual scaling challenges. Essentially, we're simplifying things for product developers and engineers—many of whom don't have a ops background—by making it easy to apply those best practices to their work.

To get going, you can start using Cased for something we call branch deploys. This was a key, actually the key, in GitHub’s ability to deploy dozens of times a day. You begin using Cased to deploy your software, and we integrate seamlessly with GitHub Actions and other CI/CD platforms, so you can be up and running in minutes deploying particular branches to production before a final merge to main. Branch deploys are a key part of a robust continuous deployment system, and you get them right away with Cased.

How do you measure the impact that Cased is having on your initial customers? Any stories that you’d like to share?  

A fun example is actually from our own experience. Last year we started thinking through different ways of applying LLMs to DevOps product works. During that experimentation time, we became really frustrated with not having the kind of workflows we were used to from GitHub. We were only deploying once or twice a day, and during rapid product iteration, this was especially frustrating. 

So, we ended up building an early version of Cased just for ourselves, with branch deploys. Our own deployments went from a couple of times a day to more than 40, with a very small team. As we talked to more people, it became clear this was something a lot of others wanted too. And deploys really do skyrocket once you’re liberated with branch deploys, so much they became hard to track. We added a feature to Cased itself just to see how many deploys an organization has that day because it’s easy to lose count when you're deploying that often. 

This came from using branch deploy technology, but not just that. It’s also the analytics and anomaly detection we built, so you have much more confidence in those deploys, and feel like it’s safe to deploy that much.

There’s been an explosion of interest in generative AI over the past 18 months. How has that shaped the way you’re thinking about building Cased? 

We built Cased with an AI-first mindset, thinking on how generative AI and machine learning could benefit people running software in production. We started by identifying small but significant and repetitive pain points that LLMs could solve. For example, when deploying software, teams want to know what exactly is being pushed out. So we can analyze a pull request or changeset and provide a quick bulleted summary to the entire organization. More time writing code.

This might seem like a minor task, but if you're deploying 30-40 times a day, having an LLM handle the analysis and reporting saves each developer a few minutes. Those minutes add up quickly.

Then, of course, classical ML and to some extent LLMs are very useful for anomaly analysis after a deployment. Consider logs. People often look through deploy logs and applications to and we found that LLMs are frankly better than we expected at analyzing both structured and unstructured logs. We can push LLMs pretty hard on this sort of work, so we’ve applied them to anomaly detection, change summarization, and log analysis. It’s been really effective, and we’re excited about all the potential for even more applications. I will say we’re probably a little more skeptical about tool use and function-calling than most people are, at least for a DevOps use case, but we’ll see.

How do you plan on Cased progressing over the next 6-12 months? Anything specific on your roadmap that new or existing customers should be excited for? 

We're really excited about using generative AI to streamline a lot of the grunt work involved in infrastructure as code. People are writing tons of Terraform and other infrastructure code, and we think that combining generative AI with our deployment tools, we can significantly speed up the process of setting up infrastructure. This will help engineers move quickly from zero to good infrastructure setups. That, in turn, can unlock cost savings of just using hyperscalers directly, or even running on bare metal without being locked into a specific platform. 

One of the core benefits of Cased is delivering world-class DevOps without platform lock-in. And so we’ll make it easier to get infrastructure up and running in the first place, which we see as a huge opportunity. We've already done a lot with deploys and visibility, but there’s so much more to do in the entire DevOps lifecycle.

Lastly, tell us a little bit about the team and culture at Cased. How big is the company now, and what do you look for in prospective team members that are joining?

We're a team of six, including the two founders, based in SF. Two of our team members work from Argentina, and they've had a strong influence on all of us, especially by introducing yerba mate instead of coffee, which is frankly critical to our success.

Culturally, our basic values are to ship fast and care more. Our product naturally pushes us to move quickly because we need to test our own product by deploying often. That feedback loop means we're shipping a lot and iterating fast—it’s just part of how we operate. Everyday you need to be deploying.

We're always on the lookout for talented people, and we mostly care about people who are passionate about developer tools. It seems obvious, but it’s true, you need to care deeply about developers to build developer tools, and that’s the mindset that matters here.

Conclusion

To stay up to date on the latest with Cased, learn more about them here.

Read our past few Deep Dives below:

• Our chat with Datastax's Chief Product Officer, Ed Anuff ❇️

• TensorStax is building Autonomous AI for MLOps 🌐

• Dashworks, your AI-powered internal search tool 🔍

• Delphi - the verified digital cloning platform 👥

• CodeGPT is intertwining human language with code 🌏

If you would like us to ‘Deep Dive’ a founder, team or product launch, please reply to this email ([email protected]) or DM us on Twitter or LinkedIn.

Join Slack | All Events | Jobs