Podcasts about launchdarkly

Take the 2026 AI Engineering Survey and get >$2k in credits and AIE WF tickets!This was recorded before Railway suffered a major GCP outage on May 19, despite being a multi-AZ, multi-zone mesh ring, with HA fiber interconnects between their Metal GCP AWS, because workload discoverability was unintentionally still tied to GCP. All has been resolved with a post-mortem.Railway did not start as an AI infrastructure company.It was founded in 2020 years before agents became the default way people thought about deploying software. Jake Cooper, formerly at Bloomberg and Uber, started Railway with a simple obsession: the activation energy to ship something to production should be near zero. Push code, get a URL, iterate. No Docker files, no Kubernetes manifests, no Ansible scripts stacked on Ansible scripts.For years, this was a slow grind. Railway spent its first 18 months hand-acquiring its first 100 users with Jake personally greeting every Discord signup on a second monitor.Today, Railway has raised $124m and is growing very fast. A 35-person team supports 3 million users, adding roughly 100,000 signups a week. Their bare metal data centers have a 3-month payback period vs. renting in the cloud, with 70% margins funding aggressive cloud bursting when needed. The servers they own have actually appreciated in value as RAM prices have climbed basically meaning the value of their hardware now exceeds the capital they've raised.From rebuilding Railway's network overlay over a weekend to moving the vast majority of workloads onto its own bare metal data centers, Jake Cooper is trying to build a new cloud for an agent-native world. In this episode, Railway's founder and “conductor” joins swyx and Alessio to unpack why the next era of software infrastructure is not just “Heroku but newer,” what agents need that humans did not, and why the old deployment loop of Git, PRs, CI/CD, and static cloud resources may be heading for a rewrite.We go deep on Railway's infrastructure stack: own-metal data centers, three-month cloud payback periods, cloud bursting, data center debt, Railpack, Nixpacks, Temporal, feature flags, Central Station, content-addressable filesystems, agent-safe production forks, and why the CLI may become more important than the canvas in an agent world. Jake also shares the founder journey behind Railway, how the company survived losing $500K/month, why it now serves millions of users with only 35 people, and why he believes the pull request is dying.We discuss:* How Railway went from a slow six-year grind to adding 100,000 users a week* How Railway thinks about agents as the next dominant software species* Why agents need version control, observability, compute, storage, and orchestration at 1000x scale* The economics of Railway's own-metal data centers and three-month payback* How Railway uses cloud bursting while scaling its own infrastructure* Why data center debt can be a better tool than venture debt for infra startups* Central Station, Railway's internal system for clustering customer feedback and incidents* Why responsible disclosure and over-communication matter for platforms* Why feature flags, progressive rollouts, and shadow traffic are essential for agents* Temporal's strengths, pain points, and why workflows matter for agents* Railpack, Nixpacks, Nix, and lazy-loaded content-addressable filesystems* Why “cattle, not pets” may change if you can clone the pets* Why Railway is building a new cloud from scratch instead of copying hyperscalers* The solo founder path, focus, writing, and how Jake thinks about company buildingRailway:* Website: https://railway.com/* X: https://x.com/RailwayJake Cooper:* LinkedIn: https://www.linkedin.com/in/thejakecooper/* X: https://x.com/JustJakeTimestamps00:00:00 Introduction: What Is Railway?00:02:07 Jake's Path to Railway00:06:13 Railway's Six-Year Growth Story00:08:52 Rebuilding the Business After the Free Tier00:11:17 Agents as the Next Software Platform00:13:29 Railway's Infrastructure Philosophy00:15:42 Bare Metal, Cloud Economics, and the Compute Crunch00:17:22 Cloud Bursting and Five-Cloud Networking00:20:20 Data Center Debt and Infra Financing00:23:31 Data Centers in Space00:25:24 What Agents Need From Infrastructure00:28:24 CLIs, Canvas, and Agent-Native UX00:35:15 Central Station, Incidents, and Responsible Disclosure00:40:30 Safe Rollouts, SRE Agents, and Production Forks00:45:00 AI SRE, Specs, Code, and Tests00:48:24 Self-Replicating Infrastructure and the New Serverless00:53:18 Heroku, Temporal, and Workflow Engines01:04:07 Railpack, Nixpacks, and Lazy-Loaded Filesystems01:06:01 Coding Agents, Token Spend, and Roadmap Acceleration01:10:56 The Pull Request Is Dying01:12:28 Feature Flags and the Agent-Era SDLC01:16:15 Cattle, Pets, and Cloning Machines01:19:29 Solo Founder Lessons01:24:12 Focus, GPUs, and Building a New Cloud01:28:20 Closing ThoughtsTranscriptAlessio [00:00:00]: Hey, everyone. Welcome to the Latent Space Podcast. This is Alessio, founder of Kernel Labs, and I'm joined by Swyx, editor of Latent Space.Swyx [00:00:10]: Hey, hey, hey. Today we're in the studio with Jake Cooper of Railway.Alessio [00:00:14]: Conductor of Railway.Swyx [00:00:15]: Conductor at Railway. Yeah.Alessio [00:00:16]: Choo-choo.Swyx [00:00:17]: Do you actually have that anywhere, like on your business card?Jake [00:00:20]: We call some of our volunteer moderators conductors. I don't have a business card. We're not that big yet. At some point I will. I got handed a nice business card from the Supermicro folks, and I was like, “Damn, this is pretty official.”Swyx [00:00:30]: Business cards are coming back.Jake [00:00:32]: They're cool. They're hip. The conductor thing is good. We're trying to figure out what we want to call each other internally. Some people think it's super cringe and say, “You don't need a name for people internally.” Some people want to call each other something. We still don't have a really good one.Jake [00:00:55]: We've got New Railcrews, Trainiacs. Nothing has stuck yet.Swyx [00:01:00]: I like Trainiac. Trainiac sounds good. Railwayians. For those who don't know, what is Railway? Let's give people a crisp definition up front.Jake [00:01:09]: Railway is the easiest way to ship anything. You go to the canvas, or you talk with Claude, and you say, “Deploy a Postgres instance, deploy my GitHub repository, run this code,” and you're off to the races.Swyx [00:01:22]: You've got a nice animation on the landing page.Jake [00:01:24]: Thank you. None of my work, by the way. They don't let me touch the design stuff anymore.Jake [00:01:25]: We want to make it trivially easy not just to deploy things, but to evolve applications over time. Most tooling right now stacks entropy on top of entropy: Docker, Kubernetes, Ansible scripts, and all these other things. If we can version all of your software and keep track of all the changes, then we can make it trivial to clone environments, fork into a parallel universe, get copies of production data, get copies of any services, make changes, validate them, and collapse them back in without reproducing everything across a staging environment.The Railway Origin Story: From Uber Systems to a New CloudSwyx [00:02:07]: I was looking at your background: Bloomberg, Uber. Nothing immediately stands out as, “This guy is going to found the next great platform as a service.” What prepared you for Railway?Jake [00:02:21]: It was curiosity to keep going deeper. I started out on front-end stuff, working on Wolfram Mathematica and porting it over. Then I briefly moved to Bloomberg, then toward Uber and distributed systems, taking the Jump Bikes systems and moving them to a distributed system built on top of Cadence, the pre-Temporal Temporal.Swyx [00:02:44]: Which, by the way, I'm happy to talk about, pros and cons.Jake [00:02:48]: Totally.Swyx [00:02:51]: But let's do the Railway story.Jake [00:02:52]: It has been a continual step of wanting an experience. Whether it's walking up to a bike, unlocking it, and having it work frictionlessly, or something else, the depth required to make that happen follows from the experience. A lot of the work I do, and a lot of the team does, is in service of that experience. We fundamentally don't care how deep we have to go. We will swim to the bottom of the swimming pool to get the experience.Jake [00:03:17]: I don't have a physics PhD. I did an EECS degree. It has always been about figuring out the next step: how do we get there? That's what led to starting Railway for that experience and then moving all the way to bare metal data centers. I was adding patches to the kernel this week to get the experience there because I can see how much better it can be.Swyx [00:03:49]: Other patches to the Linux kernel this week?Jake [00:03:51]: Yeah. Not upstream. Our fork.Swyx [00:03:52]: That's a flex. Railpack? No, this is different. This is the OS on top of Railpack?Jake [00:03:57]: No, this is an actual kernel patch. It's always literally: what do we have to do to get that experience? Then figure it out. Anything is figureoutable.Swyx [00:04:10]: Would you send the patch upstream, or does it not fit other use cases?Jake [00:04:13]: Maybe. We have to work out the experience internally. It has to do with the storage layer we're building for some of the agentic stuff. Maybe it'll be useful upstream, but it's deeply useful for us internally.Open Source, Forks, and Non-Deterministic VersioningSwyx [00:04:29]: You mentioned open source before. How do you think about starting from open source, and then coding agents letting you do a lot more from forks of it?Jake [00:04:38]: GitHub's original sin is that it's almost a series of broken pointers. You have this thing, then you clone it, and now you've lost the whole upstream. How do we make it trivial for people to modify really small pieces of it?Jake [00:04:51]: We think of Git in a discrete sense: I've either made a change and merged upstream, or I haven't. What would it look like if it were percentage-based, a little more non-deterministic, or a stream of changes that users traverse as a percentage rolled out in general and then rolled all the way up?Jake [00:05:13]: We have the open-source kickback program and let you deploy templates because we want to make it trivial for people to version these shards over time. It solves a large problem around authentication, authorization, and security. NPM has a way to define, “Don't take any new packages.” The ideal end state is that you roll out progressively to users with the minimum impact zone and continue rolling up. JPMorgan should probably be the last one on the patch line, for all our sakes, because our money and livelihoods are there.Jake [00:05:53]: It's okay if Johnny Vibe Coder gets a broken patch because there's so much entropy in the system that the rubber has to meet the road at some point. You have to test at varying levels.The Long Grind: First Users, Free Tier, and Making the Business WorkSwyx [00:06:13]: I wanted to pull up this glorious chart, which is your usage or number of daily signups?Jake [00:06:22]: Daily signups, I think.Swyx [00:06:24]: You started six years ago. It was a slow grind, and now you're on a rocket ship. You say, “Don't doubt your fight and don't quit.” Maybe pick out certain points that were key inflections for the company.Jake [00:06:40]: At the start, it's about getting your first 100 users, hell or high water. We had a website and a support link. The support link was the Discord channel. I had notifications on with two monitors: the monitor I was working on and the other monitor with Discord. If anybody came in, I was immediately like, “Hey, how's it going?” It was rare, so getting those first 100 users to come back was the start.Jake [00:07:14]: Then you build a consultancy factory because users want all these things. You have to go back to the board and ask, “What is the actual product offering I want to build on top of this?”Jake [00:07:28]: VCs want charts that always go up and to the right, but in reality you don't necessarily want charts that look like that. For us, there have been periods of expansion where we add features to test use cases, and periods of compaction where we ask, “If the experience we have is good, how do we make it significantly better?” Maybe we strip out features that don't fit our ICP anymore.Jake [00:07:57]: The boom from 2022 to 2023 came from the free tier. Everybody under the sun was using it.Swyx [00:08:09]: A lot of Reddit bots and Discord bots.Jake [00:08:12]: And crypto miners. When you build an open product on the internet where anybody can sign up, the internet is a horrible place with so many things. You go through periods of asking, “How do I reach as many people as possible?” Then, “How do I fit the exact use case for the people who really matter and are really excited about this specific thing?”Jake [00:08:39]: Then there was a two-year period of making the actual business work. During the free-tier era, we were losing about half a million dollars a month.Swyx [00:08:59]: On a $20 million bank account.Jake [00:09:02]: On a $20 million bank account with maybe $50,000 a month in revenue. That's a horrible business. I don't know how anybody invested. But you have to go through it and say, “We have an experience people love, but the business has to work.”Jake [00:09:17]: There are two schools of thought. You can run the horrible business all the way up with bad margins, or you can go back and make it work. We've always wanted a super lean team. We're 35 people right now. It's very small.Swyx [00:09:36]: Supporting three million already?Jake [00:09:38]: Yeah. We're adding 100,000 users a week right now, so it's growing fast. We don't want to add headcount for the sake of headcount or throw bodies at problems. We want to build systems. It's hard to build systems during expansion because you're adding things to the system because people are asking for them or things are breaking.Jake [00:10:00]: We had to cut off the free users for a little while, rebuild the business, and make sure it worked. We want to reach as many people as possible because software is important. It's become difficult to create things in the physical world, so it's important to make it easy for people to build in the virtual world and have access to creation. But there are legs to that journey.Jake [00:10:30]: You can see divots in the charts. If you follow between 2025 and 2026, it's either summer or winter. People go on holiday with family.Swyx [00:10:50]: It affects that much?Jake [00:10:51]: Yeah. It's kind of B2C and kind of B2B. People are shipping constantly, then they stop. Our activation curve now shows more people activating on weekdays because we have more business users, so it smooths out over time.Agents as the New Interface to DeploymentSwyx [00:11:17]: Was there a point where you started prioritizing AI development or agent development?Jake [00:11:24]: We've prioritized agentic as a top-of-funnel thing. Over the last six months, we've deeply prioritized agentic as a mechanism to build and deploy things because we believe the curve is so steep and that is how people will build and deploy software.Jake [00:11:42]: It almost fundamentally doesn't matter whether this is dot-com or not because we're all on the internet anyway. If agents are going to deploy a bunch of things and we hit an inference wall at some point, we'll fix those problems. The dominant species over the next 10 years is that we've moved from assembly to C to C++ to JavaScript to words. You're going to need to close that loop.Swyx [00:12:13]: When you say this is dot-com, did you mean buying the domain, or the general case?Jake [00:12:17]: I mean the dot-com era, when companies had a huge run-up because people understood the internet was important. Then they hit bottlenecks, fundamental laws of physics, math didn't work, and everybody came back down to earth. But it didn't matter because the internet became so impactful. If you operate on a long enough time horizon, you should build these things anyway because you can see where it's going.Jake [00:12:45]: That's where I think a lot of agent stuff is. You get to a point where you're running thousands of agents in parallel. What is the inference cost? What is the compute cost? How do you make that efficient? How do you coordinate all this? We have issues coordinating humans; we don't even have good tooling for that. Now we have to figure out how to get agents to coordinate, safely version changes, and know when to raise their hand for someone to intervene. Otherwise it becomes an interrupt factory.Railway's Infrastructure Thesis: Network, Compute, Storage, and MetalSwyx [00:13:19]: Let's go right into the technical side. What are the core infrastructure or architectural beliefs of Railway that allow you to do what you do?Jake [00:13:29]: The primitives matter a lot for us. We need network, compute, storage, and orchestration around it. You need control over a lot of those things. We've talked a lot about how we don't really use Kubernetes because we want higher-order control to place workloads in very specific places.Jake [00:13:48]: The reason is that you have to be very efficient with agents: memory reuse and all these other things, or you're going to massively blow up your cost structure. Being able to rack and stack your own servers and build your own metal unlocks performance and cost. Experiences where you're running 1,000 agents in parallel are not massively cost prohibitive.Jake [00:14:13]: Token use and compute use are blowing up. Over time, those things have to get a lot more efficient. You can get a lot of margin to make those experiences solid by building your own metal. That's all in service of offering a differentiated experience to as many people as humanly possible.Swyx [00:14:51]: You have a data center in Singapore.Jake [00:14:53]: Yeah. We have two in every other region now. In Singapore, we're adding a second one in Q3.Swyx [00:14:58]: What's it like? I've never built a data center. Do you go to Equinix and say, “I want some slots?”Jake [00:15:05]: Yeah. Equinix. You basically go and say, “I want power and I want a cage.” They say, “Great, here's what it's going to be.” You rent the cage for a period of time, fill it with racks and servers, and hook up internet to it. That's all the pieces.Swyx [00:15:36]: Then you handle everything else.Jake [00:15:37]: You handle everything else.Swyx [00:15:39]: What's the math versus clouds doing it for you?Jake [00:15:43]: If we rented in the cloud, our payback period when we go to metal is about three months.Swyx [00:15:50]: Which is crazy.Jake [00:15:51]: It's nuts. That's four years of depreciated hardware. You're going to see a lot of this compute crunch because hyperscalers are buying up a lot of stuff. We're working directly with OEMs, resellers, and people building these machines: Supermicro, Dell, and others.Jake [00:16:11]: Upstream, there's a bunch of supply pressure. When we raised our last round, between deploying capital for servers and now, the amount of money we've raised is less than the amount of money we have in the bank plus the value of the servers because the servers have appreciated as RAM has gone up. It's nuts how valuable hardware has become.Jake [00:16:50]: If you look at hyperscalers, they deployed around $80 billion of capital expenditures this year, and next year will be more. That's a massive infrastructure build-out. You look at that and think it's crazy that they're spending way more than the Manhattan Project. But if every person is going to run dozens or hundreds of agents in parallel, you have no conceptual idea how much compute is required to make that experience happen, even if you're deeply efficient and sharing resources. And that doesn't even count inference.Swyx [00:17:22]: How do you plan the build-out? The growth chart is so vertical. Are you usually at 100% utilization as soon as racks are live? How far ahead are you planning?Jake [00:17:33]: We still maintain cloud presence for bursting. We work with AWS, GCP, and a few other clouds. We can rent, and then the moment we get space or power, we compact those workloads off the cloud. We started on the clouds, then built a system to migrate to our own metal. There's nothing that says you can't continually do that again, and that's exactly what we do. We never want to be compute constrained.Jake [00:18:09]: At the start of the year, we actually became compute constrained because one upstream provider wasn't able to give us quota at the rate we needed, and the hardware was slower. I spent a weekend rebuilding our entire network overlay so we could straddle five clouds: Oracle, AWS, ourselves, GCP, and one other one. We can do more than that now.Jake [00:18:38]: We got into a spot where we were trying to pack instances tight because we couldn't get enough compute. That led to a few reliability issues, which are now past us. I made a tweet pointing out that it's becoming harder and harder to acquire compute at the rate these models need to acquire compute. We got bit by it.Swyx [00:19:15]: How do you think about pricing knowing you might not have your own metal available at all times? Are you pricing assuming you need extra margin if you end up going into the cloud?Jake [00:19:26]: Because we've built out our metal data centers, our margins on metal are around 70%. We can deeply subsidize the cloud business if we want to scale at a reasonable rate. We have a few levers: metal, which makes the margins; cloud burst; debt to buy servers; and venture capital. It's an interesting operational problem: how much cash do we have, how much should we raise, how quickly can we deploy it, and can we scale revenue as quickly as we scale compute?Jake [00:20:05]: If we continue making it trivially easy for people to build and deploy, then the faster we close that loop and the more operationally excellent we are with capital, the faster the business can scale. It's almost a straight linear deployment rate.Financing Infrastructure: Hardware Debt, VC, and Operational LeverageSwyx [00:20:20]: I think infra startups raising debt is a tool people don't utilize enough or know enough about. What can you tell us about that? Is it secured against your CPUs?Jake [00:20:32]: It's secured against our hardware.Swyx [00:20:37]: What rates do you get? Who are the lenders?Jake [00:20:39]: We pay prime plus a spread, and we can refinance any of the debt as rates go down. The terms are pretty good. The unfortunate thing is that Twitter has no nuance, so people say, “Venture debt bad.” But as with all things, there are specific tools and areas where you can be deliberate instead of using one tool as a hammer. Venture capital is not the hammer for everything. You have to explore and figure out what works.Swyx [00:21:12]: VC is usually the most expensive financing you can get.Jake [00:21:15]: Yeah. I also think people think about VC incorrectly from a capital-raising perspective. Most people think, “How do I raise as much money as possible from whoever is probably the best I can get at that time?” That's close to right, but what we've tried to do is figure out what unfair advantage we can buy with that equity.Jake [00:21:34]: It's the most expensive equity you're going to give away at that point in time, assuming the company keeps getting better. How do you use it to work with someone stellar who complements you? In the seed stage, I had never started a company. Ray Tonsing had good advice, and I could text him all the time. He was really fast. Awesome.Jake [00:22:01]: Then with John and Erica at Unusual, they said, “You roughly know what you're doing building a product. We'll mostly leave you alone and be available for advice.” Amazing. Then we got to Series A and the business was an operational tire fire because we didn't know how to scale a business. Work with Erica, and Jordan is over at Redpoint, so bonus.Jake [00:22:28]: Now we've raised from TQ and FPV as we're moving into enterprises. Every step of the way, we've asked: who can we partner with at this specific time to unlock the next section of the journey? I don't know enterprise sales. As an engineer, I can eyeball what features we might need, and we have wonderful people internally who can help. But you want boardroom dynamics where everyone is aligned and asking, “How do we win this?” instead of bickering about strategy.Data Centers in Space and the Physics of ComputeSwyx [00:23:31]: You had a tweet about data centers in space. Why no data centers in space?Jake [00:23:37]: It's not “no data centers in space.” My hot take is that I think it is solvable. I've just never seen anybody solve it.Swyx [00:23:49]: You said, “How are you going to dissipate that much heat in a vacuum?” You're making a physics claim.Jake [00:23:55]: I haven't seen anybody prove how you're going to dissipate that much heat in a vacuum. It doesn't mean it's not possible. It just means nobody has brought it up yet.Swyx [00:24:05]: Astrophage.Jake [00:24:06]: I don't know what that is.Swyx [00:24:07]: The Martian thing. Okay, you're very logical.Jake [00:24:09]: It could work. A lot of people are putting the cart before the horse. They say, “We're going to put data centers in space.” Okay, but how? “We have time to figure it out.” It's like in The Martian where they ask how they're going to intercept something and say, “We'll figure it out.”Swyx [00:24:36]: Making a bet on human invention is weird because you blind trust that it can be solved. But with physics, there are first-principles bounds you can put on it. Maybe not. Maybe you're asking to travel time or break a fundamental thermodynamic law.Jake [00:24:57]: I don't know how VCs do this either. How do you know what's not possible and a grift versus what's possible but sounds completely insane? “We're going to put data centers in space.” Coin flip as to which it is, and I guess you'll know in 10 years. That's one cycle.What Agents Need: Versioning, Observability, and 1,000x ScaleSwyx [00:25:23]: Moving back to agents. The branching, fast spin-up, and orchestration you do feels like pre-work that happened to be exactly what agents want. What do agents want differently than humans?Jake [00:25:37]: They want the ability to version things. It's not that different; it materializes slightly differently. Agents want a way to test changes incrementally. Engineers have feature flags. Is there a reason agents can't use feature flags? I don't think so.Jake [00:25:54]: They want version control. Can we use Git or not Git? That one is up in the air. I think something outside Git will emerge for how we version these things over time. They need observability. You need to query what happened, when it happened, which steps failed, traces, logs, metrics, and all the rest. They need network, compute, and storage. They need to write files, save files, iterate on files, and snapshot file systems.Jake [00:26:25]: A lot of what humans needed is in line with what agents need. Branching and forking are not different; we're just moving 1,000 times quicker. It can look like you need something massively different, but what you need is something massively better than what existed. You need orchestration massively better than Kubernetes. You need networking probably better than Envoy. It goes all the way down the stack.Jake [00:26:55]: If the workload profile doesn't change so much as it gets massively compressed because you need thousands of these things, what assumptions change? etcd is going to melt. You need to replace it with something. You can go all the way down the stack and say, “That part has to change, that part has to change, and that part has to change.”Jake [00:27:19]: The interesting thing about the super-exponential curve is that you have to build systems where you can rip out those parts at any time because a new bottleneck might emerge. You get good at parallel agents, and a different part of the system breaks. So it's similar to what humans needed, but at 1,000x scale.Jake [00:27:55]: How do you do code review in the age of agents?Swyx [00:28:00]: You throw more agents at it.Jake [00:28:01]: You don't. But then who reviews for CVEs and all these other things?Swyx [00:28:07]: More agents.Jake [00:28:08]: And that's how we hit the inference wall. You can continually throw agents at the problem, but I think there's a limit to the number of agents you can throw at a problem.CLI, Agent Handles, and Closing the LoopSwyx [00:28:24]: You already had a CLI before it was cool. How is the shape of what you're exposing changing, if at all?Jake [00:28:28]: CLIs have always been cool. The CLI changes because we think about how to give Claude, Codex, ChatGPT, or any model a handhold.Jake [00:28:50]: A CLI is a single command: deploy, get logs, and so on. Things that were prohibitively annoying to humans are not annoying to agents. They're nice. If I handed you a CLI with 40 arguments and 600 flags, you'd think, “I'm never going to use all of this.” But if you hand it to an agent, it says, “This is excellent. I have so many handles to work with.”Jake [00:29:24]: If you're going to expose things to agents that way, you want as many handles as possible where they can get information, query dynamic information, and close the loop quickly. Most problems right now are about how to close the loop as quickly as possible. Where does the agent get stuck, and how can you remove that?Jake [00:29:49]: Telemetry is important. If you can tell where the agent gets stuck from the CLI and say, “12% of people deviate from the happy path because of this, and now I add this argument and drive it down to 2%,” you massively increase the rate of loop closure.Jake [00:30:03]: That's how we think about not just the CLI, but every point in the dashboard. It's a user journey: I hear about Railway. I get something deployed. I get my first green build or aha moment. I see an endpoint, logs, whatever. Then I iterate. The iteration loop is indefinite. The user wants to deploy a new thing, a Postgres instance, change code, and keep iterating.Jake [00:30:36]: If you focus on the iteration loops and what's blocking them from closing quickly, one thing we say internally is: you never want to be waiting on compute anymore. You always want to be waiting on intelligence. If you're waiting on compute, there's a bottleneck that needs to be destroyed because eventually that bottleneck becomes so large that another workflow emerges to change it.Jake [00:31:04]: We've built a product where you push code, build it, and so on. But I fundamentally believe the push-pull loop is going away. We'll get to a point where you make a small change in production, that change is versioned across your infrastructure, you're working alongside copy-on-write versions of your database and infrastructure, and then you merge it in and it's instantaneously live. That's the holy grail of loops. The push-pull-rebuild thing is a point of friction that we're removing entirely.Canvas as Output: Dashboards, Context Anchors, and HyperstructuresSwyx [00:31:43]: It's incredibly fast. If anyone hasn't tried it, that fast feedback is great. My hot take is that Railway was famous for its canvas, which visualizes your infrastructure and lets you manipulate it visually. But that was for humans. For the next phase of growth, Railway CLI is more important than canvas.Jake [00:32:05]: The canvas is funny because it's a mechanism to show changes over time. You're right that previously we used it a lot as an input. Moving forward, its goal is more like an output. You would go to the canvas, make changes, see them, and watch your infrastructure evolve. Now agents have access to the CLI and can make those changes. So the canvas becomes an output: what information does the human need at this moment to make suitable decisions about control requests? Do I approve this or not?Jake [00:32:57]: It also has to be an anchor for your context, a port in the storm. Think of it like layers in a file system. You start with a project, then drill down into services, then into a function or code, because you want to represent the entire thing not just in your head, but in the canvas. Other people can share that representation, think on the same wavelength, and move quickly.Jake [00:33:33]: A lot of organizations get in trouble as they scale because all the context lives in someone's head. “How does this microservice work?” “I have no idea; go ask this person.” Then you have whole categories of products built around context discovery. A lot of that melts away if you have a solid hierarchy and can infinitely nest services, code, context, and everything else all the way down. That's what lets you build these structures over time.Jake [00:34:18]: It's also what lets us build what I've called hyperstructures: things that are way bigger. You look at the Golden Gate Bridge and ask, “How did we build that?” There's a meme that we lost the technology. To some extent, yes, because the coordination that built those things evolved and changed. We lost some of the art of building structure as we jammed everything into Slack.Swyx [00:34:52]: But you jam everything in Discord.Jake [00:34:53]: Same point. It doesn't matter. It's message passing and interrupts, message passing and interrupts.Swyx [00:35:00]: So you're arguing there should be something better and more structured than Slack?Jake [00:35:04]: Yeah. For sure. I think Slack is awful, and Discord is awful too.Central Station: Context Routing, Support, and Incident ClustersSwyx [00:35:09]: This is the equivalent of my mom test. What have you done that has your solution to this?Jake [00:35:15]: Internally, we've built a tool called Central Station that aggregates all the context from our users. Every piece of feedback, every customer support item, everything gets aggregated into clusters. If an incident is brewing, we can determine how many users are affected and break off a discussion based on that.Jake [00:35:40]: That is more helpful than long-running channels where you're trying to decide which channel to put something in. If you can dynamically aggregate information and dynamically route it to the right person based on context, it works better. We know internally that these four people are close to networking. If we see a networking thing, we can drill it down to those four people. If it's with this part, we can look at the commits. This is no longer a manual process internally.Jake [00:36:13]: If you go to station or help.railway.com, that's why we built it. We wanted to scale with a massive amount of leverage by aggregating feedback.Swyx [00:36:27]: This is built in-house?Jake [00:36:28]: Yep.Swyx [00:36:29]: I remember helping out on this one with Angelo in 2023. You scale a lot with a very small team.Jake [00:36:38]: Yeah. We're about 10 times bigger now.Swyx [00:36:40]: You have your full developer code here? Very cool.Jake [00:36:44]: If you go to railway.com/stats, we expose this as a pub-sub-able thing. It's all real-time metrics. There's a way to get it as JSON somewhere if you care.Jake [00:37:01]: We're big on trying to build everything in public and talk about what we're working on. We've had issues in the past, and we'll say, “Here's how we're fixing these things.” We've gotten compliments and flak for incident reports. We're always trying to make them better and talk with people.Incidents, Disclosure, and Progressive RolloutsSwyx [00:37:20]: You had a big one recently. I liked that it was scoped to 3,000. You presumably used Central Station. Talk through what happened and how you address it internally as a team.Jake [00:37:38]: Internally, this one really sucked. It had to do with an upstream provider that didn't do the behavior it said it documented, which is unfortunate given they wrote the RFC for how the behavior should work. We rolled those things out, and Central Station caught it initially when a couple users said caches weren't invalidating. We turned it off immediately.Jake [00:38:03]: When you roll out to a large user base of three million people, you get a lot of disparate behaviors. We tested in staging and had tests, but we hit an edge case. We've hardened those systems, and now we can make that better. But it was a tough one.Swyx [00:38:39]: I always wonder how private disclosure is supposed to work if people find an issue. Are they supposed to contact you first? When you run a platform, these things will happen. What channels should people pursue to quietly resolve it before it becomes a bigger incident?Jake [00:38:59]: There's responsible disclosure. We err on the side of over-disclosing and letting you know something is wrong versus having your provider gaslight you. We've erred on sharing those things more publicly, even if they impact a small subset of users. That's a decision we've made internally. We have four values. One is honor. The honorable thing is to notify people to the widest degree at which they may have been affected or there was an issue, and then confront it head-on: why did it happen, what can we do better?Swyx [00:39:45]: Not the whole user base. That's because of incremental rollouts and other things?Jake [00:39:50]: Yeah. Progressive rollouts.Swyx [00:39:54]: That should be the norm at all large platforms.Jake [00:39:58]: It should. A variety of companies do this. There's the quote that Meta runs 10,000 different versions of Meta. To our earlier point about agents, they need the same thing. They need shadow traffic and all these other things. We've built so much ceremony around production being sacred that we need to make it trivially easy to test different behaviors in a safe environment. Then you can make mistakes in a safe environment.Safe AI SRE: Customer Agents, Forked Environments, and Production ParityAlessio [00:40:30]: Do you see a world where these things get automatically caught, not necessarily by your agent, but by your customer's agent? The cache invalidation issue seems easy to check if you know to look for it.Jake [00:40:44]: It's hard because to determine it, we almost need to hook into your observability infrastructure. That's why we have the template loop on the platform: so you can roll things out progressively. You can roll out to Johnny Vibe Coder initially, or push a shard that someone consumes at their own leisure. Or you can roll it out over weeks: 0.1% of people, 1% of people, early adopters, then all the way up. That's the non-deterministic version control we talked about earlier.Jake [00:41:30]: I believe that's where most things should go, because most companies end up building staged rollout systems in-house. It's the same thing built again and again at every company. There's a massive opportunity to consolidate developer debt.Alessio [00:41:45]: You should have a free tier. Model providers give free tokens if you let them use the data. You could give free compute if someone is the number-one shard that goes out and lets you plug into their observability.Jake [00:41:55]: We do that. That's why we talked about the impact on 3,000 people. We start with lower-impact people. Larger companies on the platform are last to receive those rollouts so they have a version of the platform that's deeply stable.Alessio [00:42:16]: I have three services, so I'm sure I get the first rollout. You can nuke my thing at any time. There are all these SRE agent companies. Observability people also want agents that fix upstream problems. You have your own agent in the canvas now. How do you see that playing out?Jake [00:42:39]: It's the stacking entropy problem. If you don't have primitives to make iteration in production safe, it becomes difficult. If you're an observability provider saying, “Here's the fix to this error,” assume 80% are good and make sense. But in the last 20% long tail of complex issues, if you let somebody stamp it, you create an opportunity for an incident.Jake [00:43:08]: That's why forked environments are important. People have staging, but it always drifts from production. You need primitives, workflows, and experience built first-party on the platform so you can fork any service at any point in time.Jake [00:43:33]: I think of the canvas as a sheet of transparency paper. The agent is a little guy you push up into the canvas. It should say, “I need to copy that service and that service so I can test these two things.” It gets a read-only copy of production. Anything that's PII gets marked as a transform when we clone the database, create a copy-on-write version, or read from it. Then the agent makes changes and asks, “Does this actually work?” as close to production as possible.Jake [00:44:22]: That's how close you have to be, or you get massive drift. The system becomes unstable. You see this with massive systems built on Docker for local, Kubernetes for production, and a specific thing for something else. That complexity slows developers and becomes unstable at scale, making it hard to iterate. We want to compress that way down and say, “As close to prod as possible is where we want to be.”From AISRE Skeptic to Agent BelieverSwyx [00:45:00]: I was texting Erica for questions, and she says you were originally not a believer in AISRE. Have you come around on it?Jake [00:45:10]: I flipped, but I'm still not a believer in AISRE if you don't have the primitives to make it safe. If you unleash AISRE on production infrastructure without safe primitives for copying volumes and making sure things are fine, it's going to nuke your production database. It's not a matter of if, but when. I'm a big believer in making those loops safe.Jake [00:45:33]: I was a deep AI skeptic until 2023. In 2024, I thought, “Maybe I can roughly make this thing do it.” In 2025, I thought, “Now I can hold this.” Over winter break, everybody came back saying, “It's almost impossible to hold this.”Swyx [00:46:01]: Did you see this on the Claude docs? CloudBot? OpenCloud?Jake [00:46:06]: It's gotten to a point where it's harder to hold it wrong than to hold it right. There's a scene in Avengers where Vision picks up Thor's hammer and says it's terribly well-balanced. It self-balances and works well. I'm a deep believer at this point that this will be the dominant species: assembly, C, C++, JavaScript, words.Swyx [00:46:35]: It feels like a big jump.Jake [00:46:37]: It is. But it's not like you abandon CPU-based discrete logic and move straight to fuzzy logic. You need both. Your skills should call code or applications or some static structure. You can use skills to distill what the procedure should be or how the code should act.Jake [00:47:02]: I'm coming to a thesis: you need three points. You need a clear spec defining the system, the code, and the tests. When you say it out loud, if you've been in engineering long enough, you're like, “Of course. That's an RFC, tests, and code.” But they all matter. Having them together lets them reinforce each other: the spec and tests match, but the code doesn't, so reconcile it. Or the tests and code match but the spec doesn't, so reconcile that. That's the iteration loop.Jake [00:47:41]: That's why you're seeing people talk about software factories, docs, and reconciliation. Some of that is architectural astronomy if you don't implement it, but that loop is where most things will end up.Swyx [00:48:07]: For listeners, we've been talking about this on the pod for three years: the holy trinity of specs and tests. Itamar Friedman from Qodo is the reference if people want to look it up.Self-Modifying Infrastructure and the End of Push-Pull-RebuildSwyx [00:48:18]: One thing I want to mention on the OpenCloud idea is self-modification. I don't know how Railway would support it, but I have my OpenClaw, and I just tell it it has the Railway CLI and can do whatever. In theory, whatever capabilities or new infra it needs, it can call the Railway CLI, provision it, and add it to itself. The agent can modify its own infra.Jake [00:48:45]: It's nuts. I have a loop set up where you put the Railway CLI on top of something that runs on Railway. You're authenticated as whatever the current box is, and you can make any changes to it. Then you call Railway deploy, and it deploys itself.Jake [00:49:04]: It's like: “I need to spin up this instance of this environment. I already exist in this environment. Excellent, I have access to a Postgres instance now.” That's where we want to go with agentic, self-replicating infrastructure. That's your loop: iterate in production. You continue making changes. If it works, merge it upstream. If it doesn't, throw it away.Jake [00:49:37]: How do you make throwaway copies trivial to spin up and super cheap? The era of “I have an AWS instance with four vCPU and 16 gigs of RAM” is going to get destroyed. If you do that for agents, you need a thousand of those machines. It's prohibitively expensive compared with what we've spent a ton of time figuring out: the atomic unit of deploy, whether you call it isolates, sandboxes, or something else. Only pay for what you use, spin up instantaneously, and close the loop as quickly as possible.Jake [00:50:15]: If the system can self-replicate safely and say, “This is my environment, I'm making these changes,” it can come back with, “Does this look good? This is a new state of infrastructure given this prompt. I think I've solved it.” Then you go back and say, “Actually, it looks different.” It does the loop again. Then you say, “Cool. Apply.”Swyx [00:50:38]: That's retroactively obvious, which is the most useful kind. Any other comments on agent deployment on Railway?Jake [00:50:51]: It's getting better every day. I'm on X or Twitter. You can always yell at me about the parts not working as well as they should, because plenty of things should work way better.The New Serverless: Stateful, Long-Running, Pay-for-What-You-Use LinuxSwyx [00:51:04]: At this stage, when people want massively or embarrassingly parallel compute, they usually talk serverless. I feel like there's a new serverless compared to the previous five years of serverless. You're in that new bucket. Do you have comparisons or philosophical differences you want to call out?Jake [00:51:31]: It's somewhere in between. It's the ability to run stateful, long-running workflows or executions.Swyx [00:51:42]: Vercel has Fluid Compute, Cloudflare has some container thing, Google has App Runner and others.Jake [00:51:55]: That's where everything is roughly going, and it's why we've been working on this for six years. We believe users need access to a computer: a box that speaks Linux. They need to deploy what they want. Other systems change the surface area of what you can build. For us, users need a computer and need to deploy anything they truly want. That's why we've focused on the primitives: network, compute, storage. If we give you those and expose them so you can run things indefinitely, that's where we believe it's going.Jake [00:52:43]: Twitter has no nuance, so everyone says “servers” or “serverless.” It's always somewhere in the middle: I want to run it for a long time, but I don't want to provision the resource statically or pay for things I'm not using. That's been our thesis from day one: pay only for what you use, run it indefinitely, and it is full Linux.Swyx [00:53:12]: That's why I like the naming of Fluid. It's fluid. Flexible.Heroku, Focus, and Carrying the Torch Without Becoming the PastSwyx [00:53:18]: Another milestone is the Heroku official deprecation. You're one of the presumptive new Herokus. “New Heroku” has been a category for as long as I've been in developer tooling. It's finally happening. What was that like? Any behind-the-scenes of, “This is the moment”?Jake [00:53:42]: You have people where you're like, “You were running stuff on here? You, as this company?” It's crazy that names you would know are running on it and now coming to us saying, “We want to move a lot of this off.”Swyx [00:54:00]: Any behind-the-scenes on why Salesforce let Heroku stagnate?Jake [00:54:05]: I can only guess. It's hard when it's not your business. Salesforce's business is to build a great CRM. That's their focus. Then you acquire a compute business as an offshoot. A lot of early Meta people talk about focus. Boz has a write-up about how in the early days of Meta they had no money, so they were forced to focus. Then they turned on the money tree and had no reason not to split their focus.Jake [00:54:52]: But that dilutes your product. You get offshoots where you ask, “Is this the focus of the business?” If it's not core, it languishes. A lot of companies get in trouble when they split focus because they're fighting a multi-front war, not just externally but internally for alignment. Where are we going? What are we doing? What is our purpose?Jake [00:55:24]: If you're Salesforce-built and mission-driven, you want to work on Salesforce. Heroku is off to the side. It's not core to the business. Getting resources, budget, focus, and alignment internally becomes hard. It was a matter of time.Swyx [00:56:06]: Kudos for them to call it out instead of leaving it unknown.Jake [00:56:12]: Their release was a little odd. They called it out, but they didn't say they were shutting it down. Behind the scenes, I think they issued messages to people saying they should close accounts and that they were going to deprecate and remove things over time.Jake [00:56:30]: It's crazy because some of my first deployment experiences were on Heroku. You start with dragging things into an FTP server, then you try to get a deploy working, and then it's Heroku. It was the on-ramp for us. But the wheel turns. New things emerge. We're happy to carry the torch for a lot of that. But we don't want to be the new Heroku. We want to be the way people build and deploy software, and ultimately the way people monetize software over time.Swyx [00:57:19]: It's still a big crown to be the new Heroku. There are 50 companies that fought for that.Jake [00:57:23]: Everybody is holding some portion of it. We're happy to support people and companies. The platform works differently. The game loop is similar, but we've been dogmatic about where these things are going: primitives, agents, fan-out. Some things fit; some workflows need to change. We have an approximation of Heroku pipelines with the environment system. It's exciting. We've got a ton of people we can support, and it's growing a lot.Temporal, Workflow Engines, and State MachinesSwyx [00:58:12]: I have one more technical question about Temporal. I've sold my shares. You're a power user and one of our earliest customers. I met you through Temporal. You built on Temporal. You have complaints. This may be the most neutral and informed conversation anyone will hear about Temporal without someone working at the company.Jake [00:58:39]: That's fair. I've used Temporal for almost 10 years because of Cadence at Uber.Swyx [00:58:52]: Give people a sense of what Cadence was at Uber.Jake [00:58:57]: Cadence was the precursor to Temporal. It powers trip actions, rides, when you rent a Jump bike or scooter or car. You're running workflows for a period of time and saying, “This ride will run indefinitely until it finishes.” You attach information: you paused in this zone, so add this charge to the bill. When you end the trip, the workflow is done. That experience was powered by Cadence at the time.Swyx [00:59:34]: I used to say it's like programming the entire user journey top-down as one function.Jake [00:59:39]: It's a powerful idea and important. It's also important for the next phase of the agentic journey. You want an agent to do a specific task, be complete or incomplete on that task, and move on to the next thing. You need a way to manage workflows dynamically.Jake [00:59:59]: Temporal was always great in theory, and great when you got it working the way you wanted in production. But it required you to model the entire journey in your head. If you didn't, you could cause issues where replaying the state of the workflow causes non-determinism.Swyx [01:00:25]: Because it works on deterministic workflow history.Jake [01:00:28]: Exactly. I describe it as a jet engine. If you know how to operate it and run it, it's great. But you can't hand it to people trying to build complicated things if they don't have the whole state in their head.Jake [01:00:48]: We run our whole deployment pipeline on top of it. That's a reasonably complicated workflow: pre-commit hooks, signaling, queuing, and all the rest. We ran into the same thing at Uber. As you express a large workflow, it gets more complicated, with more states in the state machine that you have to map back to the workflow.Swyx [01:01:15]: It's a lot of ifs.Jake [01:01:16]: Exactly. At Uber, we built a system for doing the state machine and testing it. We've started to build some of those things here because it's grown heavily. It's not quite love-hate. When it works well, it works super well. But if someone who doesn't have full context puts something into the system that invalidates state or causes non-determinism, or spins off a ton of activities, you have to keep track of underlying SRE knobs like activity slots. Those should scale with memory, vCPU, and so on. It becomes a bear to scale.Swyx [01:02:10]: You need a capable sysadmin running things behind the scenes. If you moved off, what would you do?Jake [01:02:19]: We'd build our own workflow engine. We have a few internally that we've worked on.Swyx [01:02:27]: This is one of those classes of things you typically wouldn't vibe code, but I'm wondering if you can.Jake [01:02:33]: I still don't think you should vibe code it. You still want to run decent tests to make sure it works.Swyx [01:02:39]: Timo didn't invent that from scratch either. There are libraries you can run. On top of that, it's just a state machine that you have to map out. Ultimately, you define the instructions you want and run them through a state machine.Jake [01:03:00]: It's very doable. Workflow stuff is interesting. Restate is doing neat stuff here.Swyx [01:03:10]: You're tied into JavaScript. Are you a JavaScript maxi?Jake [01:03:13]: Internally, we have TypeScript, Rust, and Go. We don't add more languages. Actually, we have a little C because we write BPF code and hooks. But those are the languages.Swyx [01:03:28]: Is this for sidecars?Jake [01:03:32]: No. It's for the networking stack, volumes, and things like that. We use TypeScript a lot because it powers the dashboard, but we're moving a lot of workflow stuff off the dashboard stack and into the infrastructure stack.Railpack, Nixpacks, and Content-Addressable FilesystemsSwyx [01:04:00]: Cool. Any other technical infrastructure stuff? Railpacks?Jake [01:04:07]: We built an engine for determining dependencies based on source code. It's called Railpack. We built the first version, Nixpacks, on top of Nix, and then we moved.Swyx [01:04:17]: People have been trying to get me to adopt Nix and NixOS for four years. Is it ever going to be a thing?Jake [01:04:23]: I don't know. We're excited about it, but it has pain points. Think of it as a stack of versioned binaries at specific slices in time. If you want version X and version Y, you bloat the package space, which blows up image size and makes real-world workloads difficult.Swyx [01:04:53]: But you content-address it and cache it. In theory, there are optimizations.Jake [01:05:00]: In theory, yes. But with a large enough user base and disparate enough machines, you run into a problem Meta described in the XFAAS paper, their internal serverless system. It becomes difficult at scale unless you break out specific runtimes.Jake [01:05:24]: We didn't want to do that because we wanted to truly allow you to deploy anything. That was our initial thing with Nix. But we've moved toward interesting work around content-addressable file systems that can lazy-load anything from any point and page it into memory.Swyx [01:05:48]: Amazing.Jake [01:05:49]: The future is very bright. It's crazy, and it's going to be nuts.Coding Agent Spend, Roadmaps, and Token ROISwyx [01:05:54]: Founder journey stuff?Alessio [01:05:56]: Your cloud usage: you tweeted you're going to spend $300K this month?Jake [01:06:01]: I think we got to $200K.Alessio [01:06:02]: Coding agents?Jake [01:06:03]: Yeah.Swyx [01:06:04]: Across the company?Alessio [01:06:05]: You only have 35 people, so I'm sure they're not all spending $10K a month. What's the distribution?Jake [01:06:10]: I think I'm at about $25K. We have power users all the way down. We came back from winter break, and I basically said, “If you're writing code by hand, you're doing this wrong.” The tools are good enough now that you can move extremely quickly. There are issues and pain points, but you should be reviewing the code you are writing instead of writing it by hand.Jake [01:06:40]: Architectural patterns matter more now than ever, but you shouldn't spend your time generating code you would write. If you know how to write it, ask the agent to write it and reconcile it until it looks like you would have written it yourself.Jake [01:06:58]: People misconstrue my propensity to push people toward agents as connected to our growth and some reliability bumps. They're not necessarily related. The tools are good enough to move extremely quickly and build things way larger than you could before.Jake [01:07:19]: To the earlier point about cooling data centers in space: I don't know. But with software, you can ask, “How would I build block storage from scratch? How would I do these things?” I have ideas because I have history and have read papers. Let me work them out and build massive test benches with thousands of tests, because those are now free to author. If you're not using AI systems to speed-run your roadmap and reconcile your existing system onto the future, you're missing a large point of what's happening.Alessio [01:08:12]: What's the path to spending $3 million a month? Is it bound by ideas and things customers can absorb?Jake [01:08:19]: For most companies, it's bound by deployment at this point. That's why we've seen a massive boom in users and companies, from Fortune 50s down, asking how to get developers to move faster. You'll probably hit your CFO before any technical limits because they'll look at the eye-watering amount of money spent on tokens. Inference costs have to come down, but we're inference constrained now. There will be price discovery around what makes sense for an org to adopt.Jake [01:09:06]: I think you'll end up with the F1 driver concept. If someone is really adept at these things, it makes sense to put them in a $3 million car. If they're not, it probably doesn't make sense. You'll take a few people and say, “You can drive the F1 car. We need to go in this direction. Figure out if it works and prototype it.”Jake [01:09:33]: We've done some of that and vastly accelerated our roadmap. We thought we'd ship something in a few years; now we can probably ship it in a few months because we validated it and don't have to build it incrementally. We can skip steps and move toward our vision.Alessio [01:09:58]: A lot of people are realizing the roadmap doesn't always have a business impact, so they say tokens are too expensive. But if your roadmap were built to make more money by the time you built it, you'd have token pricing for it, the same way you do with sales. You'd spend a billion dollars on sales if you knew you would get $2 billion of revenue.Jake [01:10:19]: Exactly. A naive way to measure this is the percentage of tokens that end up in production. If you can measure impact because those tokens end up in production, that's awesome. But the burden of proof will rise. Internally, we have a growing number of pull requests that haven't merged. The question becomes: how do you get this into production? It's about how quickly you can build and deploy software, which is exciting because that's our whole thing.The SDLC Shift: Prompt Requests, Feature Flags, and Safe RolloutsSwyx [01:10:56]: The SDLC is changing. One thesis is that the pull request is dying. It's going to be the prompt request. Beyond that, code review is also kind of dying if you have all the other systems in place. What else is changing about the SDLC?Jake [01:11:19]: The AISRE and the tools to make it happen. AISRE is pie-in-the-sky aspirational. What does it take to get an AISRE? What tools do you need to build?Swyx [01:11:32]: You should expose your tooling to customers at some point. The Central Station command center.Jake [01:11:39]: We have it for template maintainers. Template maintainers can deploy and maintain templates, and they get feedback. We're going to expose those things incrementally.Swyx [01:11:51]: Clustering around incidents. Everyone has a version of that, but I don't think anyone has solved it.Jake [01:11:56]: I won't say we've solved it internally, but it's gotten so good that we can see incidents forming pretty quickly. At some point, those will be things either someone else builds or we build. We've always built things purpose-built for us. If it makes sense to make it useful for users, monetize it, or turn that loop into a profit center instead of a cost center, we want to do that.Jake [01:12:28]: Pull request is definitely dying.Swyx [01:12:29]: Do you do first-party feature flagging and incremental rollout stuff?Jake [01:12:34]: We have a feature-flagging engine we built internally and will eventually roll out.Swyx [01:12:38]: I don't see it as a user. How come you didn't give us what you have?Jake [01:12:43]: We have to beta test it. We care a lot about the quality of the things. There's plenty we've used internally that doesn't make it all the way through the journey because it fails. It works for one service but not multiple services. We'd have to build it for multiple services and know that if we released it, we'd rebuild it again and again. Some things are worth that, but many inform the roadmap.Jake [01:13:18]: We don't want to dilute the experience by saying, “This works, but only for this service,” unless it's a core initiative. Over the next few months, we'll roll out things that work for a single service, then multiple services, then multiple services across the environment. You have to be deliberate. Otherwise you create broken disparate experiences and support load because people ask how to use the feature.Jake [01:13:52]: It's the earlier expansion and compaction pattern. You expand the company to get features, then compact and smooth them out so the experience is stellar. You told me in the hallway, “It's gotten so much better.” Internally we're saying, “This part really sucks. We need to make it significantly better.”Swyx [01:14:11]: I can attest to that over the last three years watching you build Railway. For listeners, feature flagging is a huge part of Uber culture. So much so that they have too many feature flags and another thing to remove feature flags. Facebook has Gatekeeper. Agents are going to need this. It's fundamental to incremental rollouts. OpenAI acquired Statsig. GPT-5 is routing and flagging through different models.Jake [01:14:56]: It's super important. If the software development lifecycle is going to change because we're doing things 1,000 times faster and 1,000 times more concurrently, what becomes important at scale?Jake [01:15:16]: Before I started Railway, I built a feature-flagging product and tried to sell it. It was an easier version of LaunchDarkly. I ran into a problem: anyone small enough to adopt your technology doesn't care about feature flags, and anyone large enough to need feature flags needs so much scale that you have to build out all the infrastructure. I scrapped it.Jake [01:15:42]: But what is old is new again. Companies are trying to move quickly, but you can't YOLO a vibe-coded thing straight into production. You need to say, “Here's my blast radius, my impact, and I want to shadow it for these users.” Feature flags. You're going to need the tools larger companies built to maintain their structures. Everything gets compressed by 1,000x so everybody can build those structures quickly.Jake [01:16:07]: That's exactly where we are: compressing the software development lifecycle, then expanding it and adding more new things.Cattle, Pets, and Clonable InfrastructureSwyx [01:16:15]: Another term that comes to mind for newer developers is “cattle, not pets.” People treat production like a pet. It has a name. You baby it and keep it alive. With cattle, you can mass farm, roll out, portion parts out, and kill them.Jake [01:16:37]: I think that might change. You can move toward having pets as long as you have a cloning machine for your pets.Swyx [01:16:52]: Yeah.Jake [01:16:52]: If you can snapshot every single thing at every frame, it doesn't matter if something gets obliterated because you have a snapshot of it. The things we've built right now are designed to block changes from the hermetically sealed DevOps line. You have to write a Dockerfile because you nee

In this episode with Dave Rubinstein, Cameron Etezadi, CTO of LaunchDarkly, discussed the challenges and misconceptions around Vibe coding. He highlighted that while code production has sped up, confidence in the quality of the code has decreased, with 91% of customers being less confident.  He noted that 94% of customers are shipping more code but struggle with validation and quality.He noted that 94% of customers are shipping more code but struggle with validation and quality.

In this episode of the ProductLed Podcast, Wes Bush and Esben Friis-Jensen sit down with Edith Harbaugh, CEO and co-founder of LaunchDarkly, the feature management platform used by more than 5,000 customers, including 25% of the Fortune 500. Edith shares how her experience at TripIt led to the insight behind LaunchDarkly, and why feature management became such a critical part of modern software delivery. She explains what it actually took to create a category in the early days, when many companies were still shipping software only a few times a year, and why listening to customer pain mattered more than trying to force a new movement on the market. The conversation also dives into LaunchDarkly's unusual balance of product-led and enterprise sales, why the company kept its free tier even as it grew upmarket, and the story behind its first real enterprise deal. Edith also opens up about returning as CEO, how AI is reshaping software delivery, and why she now sees LaunchDarkly as runtime control for the AI era. One of the biggest themes throughout the episode is Edith's leadership philosophy: work should be fun. For her, that means helping teams reduce toil, build better software, and stay connected to the real impact they have on customers. Key Highlights: 01:59 - What Feature Management Actually Does Edith breaks down feature management in simple terms, from beta rollouts and experimentation to location-based access and safe runtime control. 03:09 - The TripIt Insight Behind LaunchDarkly How constant mobile and backend releases at TripIt revealed a problem most software teams still had not solved. 04:47 - How to Create a Category People Want Edith explains why category creation was much harder than it looked, and how meeting customers where they were helped LaunchDarkly gain traction. 07:00 - Why Early Customers Chose Buy Over Build A look at how teams with homegrown flagging systems became some of LaunchDarkly's best early customers. 08:50 - Market Pull Matters More Than Pushing Why category creation only works when buyers already feel the pain, and how Edith looked for real pull instead of forcing the message. 12:23 - The Free Tier That Survived Enterprise Sales Edith shares why LaunchDarkly kept its free motion, even after realizing the company was becoming an enterprise sales business. 13:57 - The First Enterprise Deal Changed Everything The story of a customer who refused to buy on a credit card, and how that revealed the buying behavior that shaped the company's go-to-market. 21:02 - Why Edith Came Back as CEO Edith talks about stepping away, returning to the role, and why AI created the kind of moment that called for founder-led leadership again. 22:11 - LaunchDarkly as Runtime Control for AI As AI accelerates code production, Edith explains why launch, measurement, and control are becoming even more important. 27:11 - Why Founders Should Make Work Fun Edith shares her leadership philosophy on reducing toil, helping teams enjoy the craft, and building in markets you genuinely care about. Resources:

Sam Jacobs (CEO, Pavilion), AJ Bruno (CEO, QuotaPath), and Asad Zaman (CEO, Sales Talent Agency) debate exactly how to handle team members resisting AI adoption. When to leave them, when to nudge them, and when to fire them. The discussion highlights real-world data, including how leading companies reach the top decile of AI adoption and the mechanics of running a 24-hour, four-squad AI hackathon to force experimentation. We also cover a critical performance heuristic from the past CPO of LaunchDarkly: if your team cannot execute simple tasks in a single day, you are falling behind. The conversation covers change management for revenue leaders, how to integrate AI into your daily enterprise pipeline generation, and why optimizing your GTM strategy means making hard decisions about personnel who refuse to adapt. Key Takeaways: >Driving AI adoption requires clear communication and rewarding good behavior, but AJ Bruno warns that leaders will ultimately have to "leave behind a handful of folks that are just not going to get on the bus, that aren't getting on board." >When implementing new AI tools across your teams, Asad Zaman notes that expectations must scale with seniority, stating "I have more tolerance as I move lower in the org and less tolerance at the higher levels." >AI should be treated as a creative partner for deeper analysis rather than a shortcut for unedited output, a reality Sam Jacobs emphasizes by warning "If you are just the pass through, you will be fired." Connect with the Hosts Host: Sam Jacobs - https://www.linkedin.com/in/samfjacobs/  Host: AJ Bruno - https://www.linkedin.com/in/ajbruno3/  Host: Asad Zaman - https://www.linkedin.com/in/azaman1/   Topline is more than a YouTube Channel:  Subscribe to Topline Newsletter: https://www.joinpavilion.com/topline-newsletter  Tune into Topline Podcast, the #1 podcast for founders, operators, and investors in B2B tech: https://www.joinpavilion.com/topline-podcast  Join the free Topline Slack channel to connect with 600+ revenue leaders to keep the conversation going beyond the podcast: https://www.joinpavilion.com/topline-slack Chapters: 00:00 Intro 00:35 The Question: Employees resisting AI 01:39 Convert them or fire them? 02:07 Running internal AI hackathons 03:54 How CEOs drive adoption 05:08 Mapping tasks to AI agents 06:27 The "Robot Layer" in emails 07:40 Claire Vo's anti-dinosaur framework 08:07 The One-Day Execution Heuristic 12:52 Why you should be scared 14:30 Elevating junior AI talent 16:35 Reducing 3 hours of work to 45 mins 18:54 Summary: How to uplevel the org 21:09 The tension between speed and depth 21:52 Pass-through? Fired! FIRED!!!  

In this debut episode of Third Loop, James Governor, Kim Harrison, Heidi Waterhouse, and Adam Zimman explore how the concept of Progressive Delivery emerged from real-world frustrations with how the industry talked about shipping software. Drawing on experiences from companies like GitHub and LaunchDarkly, they explain how practices like feature flags, experimentation, and observability came together to form a new delivery model. The conversation also sets the stage for the podcast's broader mission: examining technology through the perspectives of builders, users, and observers.

Emmanuel et Guillaume discutent de divers sujets liés à la programmation, notamment les systèmes de fichiers en Java, le Data Oriented Programming, les défis de JPA avec Kotlin, et les nouvelles fonctionnalités de Quarkus. Ils explorent également des sujets un peu fous comme la création de datacenters dans l'espace. Pas mal d'architecture aussi. Enregistré le 13 février 2026 Téléchargement de l'épisode LesCastCodeurs-Episode-337.mp3 ou en vidéo sur YouTube. News Langages Comment implémenter un file system en Java https://foojay.io/today/bootstrapping-a-java-file-system/ Créer un système de fichiers Java personnalisé avec NIO.2 pour des usages variés (VCS, archives, systèmes distants). Évolution Java: java.io.File (1.0) -> NIO (1.4) -> NIO.2 (1.7) pour personnalisation via FileSystem. Recommander conception préalable; API Java est orientée POSIX. Composants clés à considérer: Conception URI (scheme unique, chemin). Gestion de l'arborescence (BD, métadonnées, efficacité). Stockage binaire (emplacement, chiffrement, versions). Minimum pour démarrer (4 composants): Implémenter Path (représente fichier/répertoire). Étendre FileSystem (instance du système). Étendre FileSystemProvider (moteur, enregistré par scheme). Enregistrer FileSystemProvider via META-INF/services. Étapes suivantes: Couche BD (arborescence), opérations répertoire/fichier de base, stockage, tests. Processus long et exigeant, mais gratifiant.   Un article de brian goetz sur le futur du data oriented programming en Java https://openjdk.org/projects/amber/design-notes/beyond-records Le projet Amber de Java introduit les "carrier classes", une évolution des records qui permet plus de flexibilité tout en gardant les avantages du pattern matching et de la reconstruction Les records imposent des contraintes strictes (immutabilité, représentation exacte de l'état) qui limitent leur usage pour des classes avec état muable ou dérivé Les carrier classes permettent de déclarer une state description complète et canonique sans imposer que la représentation interne corresponde exactement à l'API publique Le modificateur "component" sur les champs permet au compilateur de dériver automatiquement les accesseurs pour les composants alignés avec la state description Les compact constructors sont généralisés aux carrier classes, générant automatiquement l'initialisation des component fields Les carrier classes supportent la déconstruction via pattern matching comme les records, rendant possible leur usage dans les instanceof et switch Les carrier interfaces permettent de définir une state description sur une interface, obligeant les implémentations à fournir les accesseurs correspondants L'extension entre carrier classes est possible, avec dérivation automatique des appels super() quand les composants parent sont subsumés par l'enfant Les records deviennent un cas particulier de carrier classes avec des contraintes supplémentaires (final, extends Record, component fields privés et finaux obligatoires) L'évolution compatible des records est améliorée en permettant l'ajout de composants en fin de liste et la déconstruction partielle par préfixe Comment éviter les pièges courants avec JPA et Kotlin - https://blog.jetbrains.com/idea/2026/01/how-to-avoid-common-pitfalls-with-jpa-and-kotlin/ JPA est une spécification Java pour la persistance objet-relationnel, mais son utilisation avec Kotlin présente des incompatibilités dues aux différences de conception des deux langages Les classes Kotlin sont finales par défaut, ce qui empêche la création de proxies par JPA pour le lazy loading et les opérations transactionnelles Le plugin kotlin-jpa génère automatiquement des constructeurs sans argument et rend les classes open, résolvant les problèmes de compatibilité Les data classes Kotlin ne sont pas adaptées aux entités JPA car elles génèrent equals/hashCode basés sur tous les champs, causant des problèmes avec les relations lazy L'utilisation de lateinit var pour les relations peut provoquer des exceptions si on accède aux propriétés avant leur initialisation par JPA Les types non-nullables Kotlin peuvent entrer en conflit avec le comportement de JPA qui initialise les entités avec des valeurs null temporaires Le backing field direct dans les getters/setters personnalisés peut contourner la logique de JPA et casser le lazy loading IntelliJ IDEA 2024.3 introduit des inspections pour détecter automatiquement ces problèmes et propose des quick-fixes L'IDE détecte les entités finales, les data classes inappropriées, les problèmes de constructeurs et l'usage incorrect de lateinit Ces nouvelles fonctionnalités aident les développeurs à éviter les bugs subtils liés à l'utilisation de JPA avec Kotlin Librairies Guide sur MapStruct @IterableMapping - https://www.baeldung.com/java-mapstruct-iterablemapping MapStruct est une bibliothèque Java pour générer automatiquement des mappers entre beans, l'annotation @IterableMapping permet de configurer finement le mapping de collections L'attribut dateFormat permet de formater automatiquement des dates lors du mapping de listes sans écrire de boucle manuelle L'attribut qualifiedByName permet de spécifier quelle méthode custom appliquer sur chaque élément de la collection à mapper Exemple d'usage : filtrer des données sensibles comme des mots de passe en mappant uniquement certains champs via une méthode dédiée L'attribut nullValueMappingStrategy permet de contrôler le comportement quand la collection source est null (retourner null ou une collection vide) L'annotation fonctionne pour tous types de collections Java (List, Set, etc.) et génère le code de boucle nécessaire Possibilité d'appliquer des formats numériques avec numberFormat pour convertir des nombres en chaînes avec un format spécifique MapStruct génère l'implémentation complète du mapper au moment de la compilation, éliminant le code boilerplate L'annotation peut être combinée avec @Named pour créer des méthodes de mapping réutilisables et nommées Le mapping des collections supporte les conversions de types complexes au-delà des simples conversions de types primitifs Accès aux fichiers Samba depuis Java avec JCIFS - https://www.baeldung.com/java-samba-jcifs JCIFS est une bibliothèque Java permettant d'accéder aux partages Samba/SMB sans monter de lecteur réseau, supportant le protocole SMB3 on pense aux galériens qui doivent se connecter aux systèmes dit legacy La configuration nécessite un contexte CIFS (CIFSContext) et des objets SmbFile pour représenter les ressources distantes L'authentification se fait via NtlmPasswordAuthenticator avec domaine, nom d'utilisateur et mot de passe La bibliothèque permet de lister les fichiers et dossiers avec listFiles() et vérifier leurs propriétés (taille, date de modification) Création de fichiers avec createNewFile() et de dossiers avec mkdir() ou mkdirs() pour créer toute une arborescence Suppression via delete() qui peut parcourir et supprimer récursivement des arborescences entières Copie de fichiers entre partages Samba avec copyTo(), mais impossibilité de copier depuis le système de fichiers local Pour copier depuis le système local, utilisation des streams SmbFileInputStream et SmbFileOutputStream Les opérations peuvent cibler différents serveurs Samba et différents partages (anonymes ou protégés par mot de passe) La bibliothèque s'intègre dans des blocs try-with-resources pour une gestion automatique des ressources Quarkus 3.31 - Support complet Java 25, nouveau packaging Maven et Panache Next - https://quarkus.io/blog/quarkus-3-31-released/ Support complet de Java 25 avec images runtime et native Nouveau packaging Maven de type quarkus avec lifecycle optimisé pour des builds plus rapides voici un article complet pour plus de detail https://quarkus.io/blog/building-large-applications/ Introduction de Panache Next, nouvelle génération avec meilleure expérience développeur et API unifiée ORM/Reactive Mise à jour vers Hibernate ORM 7.2, Reactive 3.2, Search 8.2 Support de Hibernate Spatial pour les données géospatiales Passage à Testcontainers 2 et JUnit 6 Annotations de sécurité supportées sur les repositories Jakarta Data Chiffrement des tokens OIDC pour les implémentations custom TokenStateManager Support OAuth 2.0 Pushed Authorization Requests dans l'extension OIDC Maven 3.9 maintenant requis minimum pour les projets Quarkus A2A Java SDK 1.0.0.Alpha1 - Alignement avec la spécification 1.0 du protocole Agent2Agent - https://quarkus.io/blog/a2a-java-sdk-1-0-0-alpha1/ Le SDK Java A2A implémente le protocole Agent2Agent qui permet la communication standardisée entre agents IA pour découvrir des capacités, déléguer des tâches et collaborer Passage à la version 1.0 de la spécification marque la transition d'expérimental à production-ready avec des changements cassants assumés Modernisation complète du module spec avec des Java records partout remplaçant le mix précédent de classes et records pour plus de cohérence Adoption de Protocol Buffers comme source de vérité avec des mappers MapStruct pour la conversion et Gson pour JSON-RPC Les builders utilisent maintenant des méthodes factory statiques au lieu de constructeurs publics suivant les best practices Java modernes Introduction de trois BOMs Maven pour simplifier la gestion des dépendances du SDK core, des extensions et des implémentations de référence Quarkus AgentCard évolue avec une liste supportedInterfaces remplaçant url et preferredTransport pour plus de flexibilité dans la déclaration des protocoles Support de la pagination ajouté pour ListTasks et les endpoints de configuration des notifications push avec des wrappers Result appropriés Interface A2AHttpClient pluggable permettant des implémentations HTTP personnalisées avec une implémentation Vert.x fournie Travail continu vers la conformité complète avec le TCK 1.0 en cours de développement parallèlement à la finalisation de la spécification Pourquoi Quarkus finit par "cliquer" : les 10 questions que se posent les développeurs Java - https://www.the-main-thread.com/p/quarkus-java-developers-top-questions-2025 un article qui revele et repond aux questions des gens qui ont utilisé Quarkus depuis 4-6 mois, les non noob questions Quarkus est un framework Java moderne optimisé pour le cloud qui propose des temps de démarrage ultra-rapides et une empreinte mémoire réduite Pourquoi Quarkus démarre si vite ? Le framework effectue le travail lourd au moment du build (scanning, indexation, génération de bytecode) plutôt qu'au runtime Quand utiliser le mode réactif plutôt qu'impératif ? Le réactif est pertinent pour les workloads avec haute concurrence et dominance I/O, l'impératif reste plus simple dans les autres cas Quelle est la différence entre Dev Services et Testcontainers ? Dev Services utilise Testcontainers en gérant automatiquement le cycle de vie, les ports et la configuration sans cérémonie Comment la DI de Quarkus diffère de Spring ? CDI est un standard basé sur la sécurité des types et la découverte au build-time, différent de l'approche framework de Spring Comment gérer la configuration entre environnements ? Quarkus permet de scaler depuis le développement local jusqu'à Kubernetes avec des profils, fichiers multiples et configuration externe Comment tester correctement les applications Quarkus ? @QuarkusTest démarre l'application une fois pour toute la suite de tests, changeant le modèle mental par rapport à Spring Boot Que fait vraiment Panache en coulisses ? Panache est du JPA avec des opinions fortes et des défauts propres, enveloppant Hibernate avec un style Active Record Doit-on utiliser les images natives et quand ? Les images natives brillent pour le serverless et l'edge grâce au démarrage rapide et la faible empreinte mémoire, mais tous les apps n'en bénéficient pas Comment Quarkus s'intègre avec Kubernetes ? Le framework génère automatiquement les ressources Kubernetes, gère les health checks et métriques comme s'il était nativement conçu pour cet écosystème Comment intégrer l'IA dans une application Quarkus ? LangChain4j permet d'ajouter embeddings, retrieval, guardrails et observabilité directement en Java sans passer par Python Infrastructure Les alternatives à MinIO https://rmoff.net/2026/01/14/alternatives-to-minio-for-single-node-local-s3/ MinIO a abandonné le support single-node fin 2025 pour des raisons commerciales, cassant de nombreuses démos et pipelines CI/CD qui l'utilisaient pour émuler S3 localement L'auteur cherche un remplacement simple avec image Docker, compatibilité S3, licence open source, déploiement mono-nœud facile et communauté active S3Proxy est très léger et facile à configurer, semble être l'option la plus simple mais repose sur un seul contributeur RustFS est facile à utiliser et inclut une GUI, mais c'est un projet très récent en version alpha avec une faille de sécurité majeure récente SeaweedFS existe depuis 2012 avec support S3 depuis 2018, relativement facile à configurer et dispose d'une interface web basique Zenko CloudServer remplace facilement MinIO mais la documentation et le branding (cloudserver/zenko/scality) peuvent prêter à confusion Garage nécessite une configuration complexe avec fichier TOML et conteneur d'initialisation séparé, pas un simple remplacement drop-in Apache Ozone requiert au minimum quatre nœuds pour fonctionner, beaucoup trop lourd pour un usage local simple L'auteur recommande SeaweedFS et S3Proxy comme remplaçants viables, RustFS en maybe, et élimine Garage et Ozone pour leur complexité Garage a une histoire tres associative, il vient du collectif https://deuxfleurs.fr/ qui offre un cloud distribué sans datacenter C'est certainement pas une bonne idée, les datacenters dans l'espace https://taranis.ie/datacenters-in-space-are-a-terrible-horrible-no-good-idea/ Avis d'expert (ex-NASA/Google, Dr en électronique spatiale) : Centres de données spatiaux, une "terrible" idée. Incompatibilité fondamentale : L'électronique (surtout IA/GPU) est inadaptée à l'environnement spatial. Énergie : Accès limité. Le solaire (type ISS) est insuffisant pour l'échelle de l'IA. Le nucléaire (RTG) est trop faible. Refroidissement : L'espace n'est pas "froid" ; absence de convection. Nécessite des radiateurs gigantesques (ex: 531m² pour 200kW). Radiations : Provoque erreurs (SEU, SEL) et dommages. Les GPU sont très vulnérables. Blindage lourd et inefficace. Les puces "durcies" sont très lentes. Communications : Bande passante très limitée (1Gbps radio vs 100Gbps terrestre). Le laser est tributaire des conditions atmosphériques. Conclusion : Projet extrêmement difficile, coûteux et aux performances médiocres. Data et Intelligence Artificielle Guillaume a développé un serveur MCP pour arXiv (le site de publication de papiers de recherche) en Java avec le framework Quarkus https://glaforge.dev/posts/2026/01/18/implementing-an-arxiv-mcp-server-with-quarkus-in-java/ Implémentation d'un serveur MCP (Model Context Protocol) arXiv en Java avec Quarkus. Objectif : Accéder aux publications arXiv et illustrer les fonctionnalités moins connues du protocole MCP. Mise en œuvre : Utilisation du framework Quarkus (Java) et son support MCP étendu. Assistance par Antigravity (IDE agentique) pour le développement et l'intégration de l'API arXiv. Interaction avec l'API arXiv : requêtes HTTP, format XML Atom pour les résultats, parser XML Jackson. Fonctionnalités MCP exposées : Outils (@Tool) : Recherche de publications (search_papers). Ressources (@Resource, @ResourceTemplate) : Taxonomie des catégories arXiv, métadonnées des articles (via un template d'URI). Prompts (@Prompt) : Exemples pour résumer des articles ou construire des requêtes de recherche. Configuration : Le serveur peut fonctionner en STDIO (local) ou via HTTP Streamable (local ou distant), avec une configuration simple dans des clients comme Gemini CLI. Conclusion : Quarkus simplifie la création de serveurs MCP riches en fonctionnalités, rendant les données et services "prêts pour l'IA" avec l'aide d'outils d'IA comme Antigravity. Anthropic ne mettra pas de pub dans Claude https://www.anthropic.com/news/claude-is-a-space-to-think c'est en reaction au plan non public d'OpenAi de mettre de la pub pour pousser les gens au mode payant OpenAI a besoin de cash et est probablement le plus utilisé pour gratuit au monde Anthropic annonce que Claude restera sans publicité pour préserver son rôle d'assistant conversationnel dédié au travail et à la réflexion approfondie. Les conversations avec Claude sont souvent sensibles, personnelles ou impliquent des tâches complexes d'ingénierie logicielle où les publicités seraient inappropriées. L'analyse des conversations montre qu'une part significative aborde des sujets délicats similaires à ceux évoqués avec un conseiller de confiance. Un modèle publicitaire créerait des incitations contradictoires avec le principe fondamental d'être "genuinely helpful" inscrit dans la Constitution de Claude. Les publicités introduiraient un conflit d'intérêt potentiel où les recommandations pourraient être influencées par des motivations commerciales plutôt que par l'intérêt de l'utilisateur. Le modèle économique d'Anthropic repose sur les contrats entreprise et les abonnements payants, permettant de réinvestir dans l'amélioration de Claude. Anthropic maintient l'accès gratuit avec des modèles de pointe et propose des tarifs réduits pour les ONG et l'éducation dans plus de 60 pays. Le commerce "agentique" sera supporté mais uniquement à l'initiative de l'utilisateur, jamais des annonceurs, pour préserver la confiance. Les intégrations tierces comme Figma, Asana ou Canva continueront d'être développées en gardant l'utilisateur aux commandes. Anthropic compare Claude à un cahier ou un tableau blanc : des espaces de pensée purs, sans publicité. Infinispan 16.1 est sorti https://infinispan.org/blog/2026/02/04/infinispan-16-1 déjà le nom de la release mérite une mention Le memory bounded par cache et par ensemble de cache s est pas facile à faire en Java Une nouvelle api OpenAPI AOT caché dans les images container Un serveur MCP local juste avec un fichier Java ? C'est possible avec LangChain4j et JBang https://glaforge.dev/posts/2026/02/11/zero-boilerplate-java-stdio-mcp-servers-with-langchain4j-and-jbang/ Création rapide de serveurs MCP Java sans boilerplate. MCP (Model Context Protocol): standard pour connecter les LLM à des outils et données. Le tutoriel répond au manque d'options simples pour les développeurs Java, face à une prédominance de Python/TypeScript dans l'écosystème MCP. La solution utilise: LangChain4j: qui intègre un nouveau module serveur MCP pour le protocole STDIO. JBang: permet d'exécuter des fichiers Java comme des scripts, éliminant les fichiers de build (pom.xml, Gradle). Implémentation: se fait via un seul fichier .java. JBang gère automatiquement les dépendances (//DEPS). L'annotation @Tool de LangChain4j expose les méthodes Java aux LLM. StdioMcpServerTransport gère la communication JSON-RPC via l'entrée/sortie standard (STDIO). Point crucial: Les logs doivent impérativement être redirigés vers System.err pour éviter de corrompre System.out, qui est réservé à la communication MCP (messages JSON-RPC). Facilite l'intégration locale avec des outils comme Gemini CLI, Claude Code, etc. Reciprocal Rank Fusion : un algorithme utile et souvent utilisé pour faire de la recherche hybride, pour mélanger du RAG et des recherches par mots-clé https://glaforge.dev/posts/2026/02/10/advanced-rag-understanding-reciprocal-rank-fusion-in-hybrid-search/ RAG : Qualité LLM dépend de la récupération. Recherche Hybride : Combiner vectoriel et mots-clés (BM25) est optimal. Défi : Fusionner des scores d'échelles différentes. Solution : Reciprocal Rank Fusion (RRF). RRF : Algorithme robuste qui fusionne des listes de résultats en se basant uniquement sur le rang des documents, ignorant les scores. Avantages RRF : Pas de normalisation de scores, scalable, excellente première étape de réorganisation. Architecture RAG fréquente : RRF (large sélection) + Cross-Encoder / modèle de reranking (précision fine). RAG-Fusion : Utilise un LLM pour générer plusieurs variantes de requête, puis RRF agrège tous les résultats pour renforcer le consensus et réduire les hallucinations. Implémentation : LangChain4j utilise RRF par défaut pour agréger les résultats de plusieurs retrievers. Les dernières fonctionnalités de Gemini et Nano Banana supportées dans LangChain4j https://glaforge.dev/posts/2026/02/06/latest-gemini-and-nano-banana-enhancements-in-langchain4j/ Nouveaux modèles d'images Nano Banana (Gemini 2.5/3.0) pour génération et édition (jusqu'à 4K). "Grounding" via Google Search (pour images et texte) et Google Maps (localisation, Gemini 2.5). Outil de contexte URL (Gemini 3.0) pour lecture directe de pages web. Agents multimodaux (AiServices) capables de générer des images. Configuration de la réflexion (profondeur Chain-of-Thought) pour Gemini 3.0. Métadonnées enrichies : usage des tokens et détails des sources de "grounding". Comment configurer Gemini CLI comment agent de code dans IntelliJ grâce au protocole ACP https://glaforge.dev/posts/2026/02/01/how-to-integrate-gemini-cli-with-intellij-idea-using-acp/ But : Intégrer Gemini CLI à IntelliJ IDEA via l'Agent Client Protocol (ACP). Prérequis : IntelliJ IDEA 2025.3+, Node.js (v20+), Gemini CLI. Étapes : Installer Gemini CLI (npm install -g @google/gemini-cli). Localiser l'exécutable gemini. Configurer ~/.jetbrains/acp.json (chemin exécutable, --experimental-acp, use_idea_mcp: true). Redémarrer IDEA, sélectionner "Gemini CLI" dans l'Assistant IA. Usage : Gemini interagit avec le code et exécute des commandes (contexte projet). Important : S'assurer du flag --experimental-acp dans la configuration. Outillage PipeNet, une alternative (open source aussi) à LocalTunnel, mais un plus évoluée https://pipenet.dev/ pipenet: Alternative open-source et moderne à localtunnel (client + serveur). Usages: Développement local (partage, webhooks), intégration SDK, auto-hébergement sécurisé. Fonctionnalités: Client (expose ports locaux, sous-domaines), Serveur (déploiement, domaines personnalisés, optimisé cloud mono-port). Avantages vs localtunnel: Déploiement cloud sur un seul port, support multi-domaines, TypeScript/ESM, maintenance active. Protocoles: HTTP/S, WebSocket, SSE, HTTP Streaming. Intégration: CLI ou SDK JavaScript. JSON-IO — une librairie comme Jackson ou GSON, supportant JSON5, TOON, et qui pourrait être utile pour l'utilisation du "structured output" des LLMs quand ils ne produisent pas du JSON parfait https://github.com/jdereg/json-io json-io : Librairie Java pour la sérialisation et désérialisation JSON/TOON. Gère les graphes d'objets complexes, les références cycliques et les types polymorphes. Support complet JSON5 (lecture et écriture), y compris des fonctionnalités non prises en charge par Jackson/Gson. Format TOON : Notation orientée token, optimisée pour les LLM, réduisant l'utilisation de tokens de 40 à 50% par rapport au JSON. Légère : Aucune dépendance externe (sauf java-util), taille de JAR réduite (~330K). Compatible JDK 1.8 à 24, ainsi qu'avec les environnements JPMS et OSGi. Deux modes de conversion : vers des objets Java typés (toJava()) ou vers des Map (toMaps()). Options de configuration étendues via ReadOptionsBuilder et WriteOptionsBuilder. Optimisée pour les déploiements cloud natifs et les architectures de microservices. Utiliser mailpit et testcontainer pour tester vos envois d'emails https://foojay.io/today/testing-emails-with-testcontainers-and-mailpit/ l'article montre via SpringBoot et sans. Et voici l'extension Quarkus https://quarkus.io/extensions/io.quarkiverse.mailpit/quarkus-mailpit/?tab=docs Tester l'envoi d'emails en développement est complexe car on ne peut pas utiliser de vrais serveurs SMTP Mailpit est un serveur SMTP de test qui capture les emails et propose une interface web pour les consulter Testcontainers permet de démarrer Mailpit dans un conteneur Docker pour les tests d'intégration L'article montre comment configurer une application SpringBoot pour envoyer des emails via JavaMail Un module Testcontainers dédié à Mailpit facilite son intégration dans les tests Le conteneur Mailpit expose un port SMTP (1025) et une API HTTP (8025) pour vérifier les emails reçus Les tests peuvent interroger l'API HTTP de Mailpit pour valider le contenu des emails envoyés Cette approche évite d'utiliser des mocks et teste réellement l'envoi d'emails Mailpit peut aussi servir en développement local pour visualiser les emails sans les envoyer réellement La solution fonctionne avec n'importe quel framework Java supportant JavaMail Architecture Comment scaler un système de 0 à 10 millions d'utilisateurs https://blog.algomaster.io/p/scaling-a-system-from-0-to-10-million-users Philosophie : Scalabilité incrémentale, résoudre les goulots d'étranglement sans sur-ingénierie. 0-100 utilisateurs : Serveur unique (app, DB, jobs). 100-1K : Séparer app et DB (services gérés, pooling). 1K-10K : Équilibreur de charge, multi-serveurs d'app (stateless via sessions partagées). 10K-100K : Caching, réplicas de lecture DB, CDN (réduire charge DB). 100K-500K : Auto-scaling, applications stateless (authentification JWT). 500K-10M : Sharding DB, microservices, files de messages (traitement asynchrone). 10M+ : Déploiement multi-régions, CQRS, persistance polyglotte, infra personnalisée. Principes clés : Simplicité, mesure, stateless essentiel, cache/asynchrone, sharding prudent, compromis (CAP), coût de la complexité. Patterns d'Architecture 2026 - Du Hype à la Réalité du Terrain (Part 1/2) - https://blog.ippon.fr/2026/01/30/patterns-darchitecture-2026-part-1/ L'article présente quatre patterns d'architecture logicielle pour répondre aux enjeux de scalabilité, résilience et agilité business dans les systèmes modernes Il présentent leurs raisons et leurs pièges Un bon rappel L'Event-Driven Architecture permet une communication asynchrone entre systèmes via des événements publiés et consommés, évitant le couplage direct Les bénéfices de l'EDA incluent la scalabilité indépendante des composants, la résilience face aux pannes et l'ajout facile de nouveaux cas d'usage Le pattern API-First associé à un API Gateway centralise la sécurité, le routage et l'observabilité des APIs avec un catalogue unifié Le Backend for Frontend crée des APIs spécifiques par canal (mobile, web, partenaires) pour optimiser l'expérience utilisateur CQRS sépare les modèles de lecture et d'écriture avec des bases optimisées distinctes, tandis que l'Event Sourcing stocke tous les événements plutôt que l'état actuel Le Saga Pattern gère les transactions distribuées via orchestration centralisée ou chorégraphie événementielle pour coordonner plusieurs microservices Les pièges courants incluent l'explosion d'événements granulaires, la complexité du debugging distribué, et la mauvaise gestion de la cohérence finale Les technologies phares sont Kafka pour l'event streaming, Kong pour l'API Gateway, EventStoreDB pour l'Event Sourcing et Temporal pour les Sagas Ces patterns nécessitent une maturité technique et ne sont pas adaptés aux applications CRUD simples ou aux équipes junior Patterns d'architecture 2026 : du hype à la réalité terrain part. 2 - https://blog.ippon.fr/2026/02/04/patterns-darchitecture-2026-part-2/ Deuxième partie d'un guide pratique sur les patterns d'architecture logicielle et système éprouvés pour moderniser et structurer les applications en 2026 Strangler Fig permet de migrer progressivement un système legacy en l'enveloppant petit à petit plutôt que de tout réécrire d'un coup (70% d'échec pour les big bang) Anti-Corruption Layer protège votre nouveau domaine métier des modèles externes et legacy en créant une couche de traduction entre les systèmes Service Mesh gère automatiquement la communication inter-services dans les architectures microservices (sécurité mTLS, observabilité, résilience) Architecture Hexagonale sépare le coeur métier des détails techniques via des ports et adaptateurs pour améliorer la testabilité et l'évolutivité Chaque pattern est illustré par un cas client concret avec résultats mesurables et liste des pièges à éviter lors de l'implémentation Les technologies 2026 mentionnées incluent Istio, Linkerd pour service mesh, LaunchDarkly pour feature flags, NGINX et Kong pour API gateway Tableau comparatif final aide à choisir le bon pattern selon la complexité, le scope et le use case spécifique du projet L'article insiste sur une approche pragmatique : ne pas utiliser un pattern juste parce qu'il est moderne mais parce qu'il résout un problème réel Pour les systèmes simples type CRUD ou avec peu de services, ces patterns peuvent introduire une complexité inutile qu'il faut savoir éviter Méthodologies Le rêve récurrent de remplacer voire supprimer les développeurs https://www.caimito.net/en/blog/2025/12/07/the-recurring-dream-of-replacing-developers.html Depuis 1969, chaque décennie voit une tentative de réduire le besoin de développeurs (de COBOL, UML, visual builders… à IA). Motivation : frustration des dirigeants face aux délais et coûts de développement. La complexité logicielle est intrinsèque et intellectuelle, non pas une question d'outils. Chaque vague technologique apporte de la valeur mais ne supprime pas l'expertise humaine. L'IA assiste les développeurs, améliore l'efficacité, mais ne remplace ni le jugement ni la gestion de la complexité. La demande de logiciels excède l'offre car la contrainte majeure est la réflexion nécessaire pour gérer cette complexité. Pour les dirigeants : les outils rendent-ils nos développeurs plus efficaces sur les problèmes complexes et réduisent-ils les tâches répétitives ? Le "rêve" de remplacer les développeurs, irréalisable, est un moteur d'innovation créant des outils précieux. Comment creuser des sujets à l'ère de l'IA générative. Quid du partage et la curation de ces recherches ? https://glaforge.dev/posts/2026/02/04/researching-topics-in-the-age-of-ai-rock-solid-webhooks-case-study/ Recherche initiale de l'auteur sur les webhooks en 2019, processus long et manuel. L'IA (Deep Research, Gemini, NotebookLM) facilite désormais la recherche approfondie, l'exploration de sujets et le partage des résultats. L'IA a identifié et validé des pratiques clés pour des déploiements de webhooks résilients, en grande partie les mêmes que celles trouvées précédemment par l'auteur. Génération d'artefacts par l'IA : rapport détaillé, résumé concis, illustration sketchnote, et même une présentation (slide deck). Guillaume s'interroge sur le partage public de ces rapports de recherche générés par l'IA, tout en souhaitant éviter le "AI Slop". Loi, société et organisation Le logiciel menacé par le vibe coding https://www.techbuzz.ai/articles/we-built-a-monday-com-clone-in-under-an-hour-with-ai Deux journalistes de CNBC sans expérience de code ont créé un clone fonctionnel de Monday.com en moins de 60 minutes pour 5 à 15 dollars. L'expérience valide les craintes des investisseurs qui ont provoqué une baisse de 30% des actions des entreprises SaaS. L'IA a non seulement reproduit les fonctionnalités de base mais a aussi recherché Monday.com de manière autonome pour identifier et recréer ses fonctionnalités clés. Cette technique appelée "vibe-coding" permet aux non-développeurs de construire des applications via des instructions en anglais courant. Les entreprises les plus vulnérables sont celles offrant des outils "qui se posent sur le travail" comme Atlassian, Adobe, HubSpot, Zendesk et Smartsheet. Les entreprises de cybersécurité comme CrowdStrike et Palo Alto sont considérées plus protégées grâce aux effets de réseau et aux barrières réglementaires. Les systèmes d'enregistrement comme Salesforce restent plus difficiles à répliquer en raison de leur profondeur d'intégration et de données d'entreprise. Le coût de 5 à 15 dollars par construction permet aux entreprises de prototyper plusieurs solutions personnalisées pour moins cher qu'une seule licence Monday.com. L'expérience soulève des questions sur la pérennité du marché de 5 milliards de dollars des outils de gestion de projet face à l'IA générative. Conférences En complément de l'agenda des conférences de Aurélie Vache, il y a également le site https://javaconferences.org/ (fait par Brian Vermeer) avec toutes les conférences Java à venir ! La liste des conférences provenant de Developers Conferences Agenda/List par Aurélie Vache et contributeurs : 12-13 février 2026 : Touraine Tech #26 - Tours (France) 12-13 février 2026 : World Artificial Intelligence Cannes Festival - Cannes (France) 19 février 2026 : ObservabilityCON on the Road - Paris (France) 6 mars 2026 : WordCamp Nice 2026 - Nice (France) 18 mars 2026 : Jupyter Workshops: AI in Jupyter: Building Extensible AI Capabilities for Interactive Computing - Saint-Maur-des-Fossés (France) 18-19 mars 2026 : Agile Niort 2026 - Niort (France) 20 mars 2026 : Atlantique Day 2026 - Nantes (France) 26 mars 2026 : Data Days Lille - Lille (France) 26-27 mars 2026 : SymfonyLive Paris 2026 - Paris (France) 26-27 mars 2026 : REACT PARIS - Paris (France) 27-29 mars 2026 : Shift - Nantes (France) 31 mars 2026 : ParisTestConf - Paris (France) 31 mars 2026-1 avril 2026 : FlowCon France 2026 - Paris (France) 1 avril 2026 : AWS Summit Paris - Paris (France) 2 avril 2026 : Pragma Cannes 2026 - Cannes (France) 2-3 avril 2026 : Xen Spring Meetup 2026 - Grenoble (France) 7 avril 2026 : PyTorch Conference Europe - Paris (France) 9-10 avril 2026 : Android Makers by droidcon 2026 - Paris (France) 9-11 avril 2026 : Drupalcamp Grenoble 2026 - Grenoble (France) 16-17 avril 2026 : MiXiT 2026 - Lyon (France) 17-18 avril 2026 : Faiseuses du Web 5 - Dinan (France) 22-24 avril 2026 : Devoxx France 2026 - Paris (France) 23-25 avril 2026 : Devoxx Greece - Athens (Greece) 6-7 mai 2026 : Devoxx UK 2026 - London (UK) 12 mai 2026 : Lead Innovation Day - Leadership Edition - Paris (France) 19 mai 2026 : La Product Conf Paris 2026 - Paris (France) 21-22 mai 2026 : Flupa UX Days 2026 - Paris (France) 22 mai 2026 : AFUP Day 2026 Lille - Lille (France) 22 mai 2026 : AFUP Day 2026 Paris - Paris (France) 22 mai 2026 : AFUP Day 2026 Bordeaux - Bordeaux (France) 22 mai 2026 : AFUP Day 2026 Lyon - Lyon (France) 28 mai 2026 : DevCon 27 : I.A. & Vibe Coding - Paris (France) 28 mai 2026 : Cloud Toulouse 2026 - Toulouse (France) 29 mai 2026 : NG Baguette Conf 2026 - Paris (France) 29 mai 2026 : Agile Tour Strasbourg 2026 - Strasbourg (France) 2-3 juin 2026 : Agile Tour Rennes 2026 - Rennes (France) 2-3 juin 2026 : OW2Con - Paris-Châtillon (France) 3 juin 2026 : IA–NA - La Rochelle (France) 5 juin 2026 : TechReady - Nantes (France) 5 juin 2026 : Fork it! - Rouen - Rouen (France) 6 juin 2026 : Polycloud - Montpellier (France) 9 juin 2026 : JFTL - Montrouge (France) 9 juin 2026 : C: - Caen (France) 11-12 juin 2026 : DevQuest Niort - Niort (France) 11-12 juin 2026 : DevLille 2026 - Lille (France) 12 juin 2026 : Tech F'Est 2026 - Nancy (France) 16 juin 2026 : Mobilis In Mobile 2026 - Nantes (France) 17-19 juin 2026 : Devoxx Poland - Krakow (Poland) 17-20 juin 2026 : VivaTech - Paris (France) 18 juin 2026 : Tech'Work - Lyon (France) 22-26 juin 2026 : Galaxy Community Conference - Clermont-Ferrand (France) 24-25 juin 2026 : Agi'Lille 2026 - Lille (France) 24-26 juin 2026 : BreizhCamp 2026 - Rennes (France) 2 juillet 2026 : Azur Tech Summer 2026 - Valbonne (France) 2-3 juillet 2026 : Sunny Tech - Montpellier (France) 3 juillet 2026 : Agile Lyon 2026 - Lyon (France) 6-8 juillet 2026 : Riviera Dev - Sophia Antipolis (France) 2 août 2026 : 4th Tech Summit on Artificial Intelligence & Robotics - Paris (France) 20-22 août 2026 : 4th Tech Summit on AI & Robotics - Paris (France) & Online 4 septembre 2026 : JUG Summer Camp 2026 - La Rochelle (France) 17-18 septembre 2026 : API Platform Conference 2026 - Lille (France) 24 septembre 2026 : PlatformCon Live Day Paris 2026 - Paris (France) 1 octobre 2026 : WAX 2026 - Marseille (France) 1-2 octobre 2026 : Volcamp - Clermont-Ferrand (France) 5-9 octobre 2026 : Devoxx Belgium - Antwerp (Belgium) Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via X/twitter https://twitter.com/lescastcodeurs ou Bluesky https://bsky.app/profile/lescastcodeurs.com Faire un crowdcast ou une crowdquestion Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Tous les épisodes et toutes les infos sur https://lescastcodeurs.com/

In this episode, we sit down with Adam Zimman, author and VC advisor, to explore the world of progressive delivery and why shipping software is only the beginning. Adam shares his fascinating journey through tech—from his early days as a fire juggler to leadership roles at EMC, VMware, GitHub, and LaunchDarkly – and how those... Read more »

Mike sits down with Tom Totenberg to discuss disastrous Friday night deployments, selective feature flags, Launch Darkly and more general development goodness. Alice for Power BI (https://alice.dev/alice-power-bi/) Mike on X (https://x.com/dominucco) Mike on BlueSky (https://bsky.app/profile/dominucco.bsky.social) Coder on X (https://x.com/coderradioshow) Show Discord (https://discord.gg/k8e7gKUpEp) Alice & Custom Dev (https://alice.dev) Mike's Recent Omakub Blog Post (https://dominickm.com/omakhub-review/) Tom's LinkedIn (https://www.linkedin.com/in/thomas-totenberg/) LaunchDarkly (https://launchdarkly.com/)

What makes a great tech infrastructure startup? And how do the best ones successfully navigate, and stand out from, the overcrowded market?In this episode, Yaniv is joined by Joseph Ruscio, General Partner at Heavybit and former CTO of Vibrato, to unpack the dos and don'ts of tech infrastructure startups, how open source fuels growth, and why AI is changing the way software is built.With over 20 years in system software and a portfolio including LaunchDarkly, Netlify, and PagerDuty, Joe brings a front-row perspective to the future of startup building. The conversation dives into bottom-up growth, developer adoption, and the open source strategies that give founders leverage—and how AI agents are reshaping the role of the software engineer.In this episode, you will:Understand why bottom-up adoption often beats enterprise sales for startup growthLearn how AWS scaled from startups to Fortune 500s—and what founders can copyDiscover the power of open source as a go-to-market strategy (and its pitfalls)See why giving away your product can actually accelerate growth and community adoptionExplore how AI is changing developer workflows and the future role of engineersIdentify the risks of being “too close to your own pain” as a technical founderApply practical guidelines for choosing your startup's tech stack without overthinkingDevGuild Open Source: http://heavybit.com/devguild/open-source The Pact Honor the Startup Podcast Pact! If you have listened to TSP and gotten value from it, please:Follow, rate, and review us in your listening appSubscribe to the TSP Mailing List to gain access to exclusive newsletter-only content and early access to information on upcoming episodes: https://thestartuppodcast.beehiiv.com/subscribe Secure your official TSP merchandise at https://shop.tsp.show/  Follow us here on YouTube for full-video episodes: https://www.youtube.com/channel/UCNjm1MTdjysRRV07fSf0yGg Give us a public shout-out on LinkedIn or anywhere you have a social media followingKey linksGet your question in for our next Q&A episode: https://forms.gle/NZzgNWVLiFmwvFA2A The Startup Podcast website: https://www.tsp.show/episodes/Learn more about Chris and YanivWork 1:1 with Chris: http://chrissaad.com/advisory/  Follow Chris on Linkedin: https://www.linkedin.com/in/chrissaad/  Follow Yaniv on Linkedin: https://www.linkedin.com/in/ybernstein/Producer: Justin McArthur https://www.linkedin.com/in/justin-mcarthurIntro Voice: Jeremiah Owyang https://web-strategist.com/

**Automate 80% of your repetitive writing, thinking, and creative tasks****Try Spiral made by Dan Shipper & Every: https://spiral.computer?utm_source=youtube**Claire Vo built ChatPRD—an on-demand chief product officer powered by AI. It's now used by over 10,000 product managers and is pulling in six figures in revenue. The best part?Claire has a demanding day job as the CPO at LaunchDarkly. So she built all of ChatPRD herself—over the weekend—with AI.I sat down with Claire to talk about how ChatPRD works, how she built it as a side hustle using AI, and all of the ways she's using AI tools to accelerate her work and life. We get into:- How she used AI to build ChatPRD over Thanksgiving break- The part of product management that Claire thinks AI will disrupt- Why the PMs of tomorrow will be “proto-managers” who create prototypes rather than just specs- How junior PMs can use AI to upskill faster- The ways in which ChatPRD is baked into her own workflow- How building ChatPRD is making Claire a better PM- How Claire uses AI as a tech-forward parentThis is a must-watch for anyone interested in turning their side hustle into a thriving business or who works in product.If you found this episode interesting, please like, subscribe, comment, and share! Thanks to Google and LTX Studio for sponsoring this episode! The Gemini 2.5 family of models is now generally available. 2.5 Pro, the most advanced model, is great for reasoning over complex tasks; next up, 2.5 Flash finds the sweet spot between performance and price; and finally, 2.5 Flash Lite is ideal for low-latency, high-volume tasks. Start building in Google AI Studio at ⁠https://ai.dev/⁠LTX Studio is helping storytellers go from concept to delivery in one seamless platform. Whether you're storyboarding your next film, prototyping ad concepts, or creating pixel-ready assets, LTX Studio allows you to fully realize your imaginations. Check them out here: ⁠https://tinyurl.com/2d5nx3ut⁠ Want even more?Sign up for Every to unlock our ultimate guide to prompting ChatGPT here: https://every.ck.page/ultimate-guide-to-prompting-chatgpt. It's usually only for paying subscribers, but you can get it here for free.To hear more from Dan Shipper:- Subscribe to Every: https://every.to/subscribe- Follow him on X: https://twitter.com/danshipperLinks to resources mentioned in the episode:- Claire Vo: https://x.com/clairevo; @chiefproductofficer- ChatPRD: https://www.chatprd.ai/; https://x.com/chatprd; https://www.linkedin.com/company/chatprd/; https://www.youtube.com/@ChatPRD - Some of the AI tools that Claire used to build ChatPRD: http://Clerk.dev; https://tiptap.dev/ - Greeking Out, the Greek mythology podcast that Claire's son enjoys: https://www.nationalgeographic.com/podcasts/greeking-out

In this episode of the Thread Podcast, host Justin Vandehey speaks with Karan Singh, SVP of Go-to-Market Strategy and Operations at LaunchDarkly. They discuss Karan's extensive background in various tech companies, the evolving role of AI in sales, and the importance of human connection in go-to-market strategies. Karan emphasizes the need for productivity over leanness in sales organizations and highlights the challenges of training and developing sellers in a fast-paced environment. He also shares insights for new revenue operations professionals, stressing the importance of seller readiness and effective onboarding processes.TakeawaysKaran Singh has a diverse background in tech, having worked in cybersecurity, data warehousing, and vertical SaaS.AI tools should enhance human connections rather than replace them in sales processes.Productivity is more important than leanness in sales organizations.The average tenure of a seller is around 18 months, highlighting the need for effective training.Investing in seller readiness early can lead to long-term success in sales organizations.Automation can help sellers focus on meaningful human interactions.Sales training should be consistent and comprehensive to ensure seller success.Understanding customer needs is crucial for effective sales conversations.Karan emphasizes the importance of developing B sellers into A sellers.The role of Rev Ops is multifaceted, requiring a focus on strategy, systems, and seller enablement.Chapters02:26 Karan Singh's Journey in Go-to-Market Strategy07:15 The Role of AI in Sales and Human Connection10:36 Productivity vs. Leanness in Sales Organizations14:13 Challenges in Seller Training and Development18:53 Key Insights for New Rev Ops Hires

In this episode, Dave interviews Jenn Wei, senior vice president of product at LaunchDarkly.They discuss:The importance of creating a culture for AI experimentationNeeding to shift from building features to managing dynamic learning systemsThe role of leadership in driving innovation

What can a satirical HBO series teach you about building a scalable, high-impact B2B marketing engine? A lot—if you ask Manish Gupta.In this episode, 4-Time CMO Manish Gupta joins Caspian CEO Ian Faison to deconstruct the show Silicon Valley and extract lessons on marketing, storytelling, team dynamics, and startup chaos. Together, they explore how to translate complex technology to engage your audience, prioritizing content in your marketing, and including human moments to build brand trust.About our guest, Manish GuptaManish Gupta is a 4x CMO, having led marketing at companies like LaunchDarkly, Sonar and Redis. Manish brings deep experience scaling B2B technology businesses across public and private markets, including acquisitions and strategic transitions.His leadership spans category-defining companies such as Redis, Sonar, Liaison, Oracle, and Apple, where he has successfully driven both product-led and sales-led growth. With domain expertise in software infrastructure, AI, SaaS, cloud, and communications, Manish is known for navigating complex business models and delivering sustainable growth.He has also served as an advisor, board member, and investor in early-stage startups. Manish holds Master's and Bachelor's degrees in Engineering from Georgia Tech and an MBA from Santa Clara University.What B2B Companies Can Learn From Silicon Valley:Tech needs a translator. Technology is hard to understand—even for your audience. “Translating really complex technologies into simple-to-deliver messaging is an art form,” Manish says. “Great technology needs a great story, right? The narrative is so important, and how you deliver the narrative and how you package it is key to the success.”Content is the engine. Not the garnish. Manish makes it clear: “The whole marketing engine should be built around content.” That means investing in formats your audience truly wants—like hands-on guides and short-form videos—and making sure every asset is tailored to a specific persona and stage in the journey.Human moments build brand trust. Whether it's the "Not Hotdog" app or the team playing their bizarre “Always Blue” game, Silicon Valley nails the emotional truth of startup life. That same humanity should be visible in your marketing. Quotes*“ We as marketing leaders have to be very mindful that not everything and everybody in every marketing organization can evolve and move at an exponentially improved pace just because you have the tools. Yes, it has to move on that trajectory, but there has to be a level of reality put into the expectation. Otherwise there's gonna be burnout.”*”I think particularly in the B2B tech space, you've got almost a bifurcation of folks that use the technology but don't have any budget ownership, versus people that have the decision-making authority and the budget ownership but aren't necessarily very close to the technology. And I think marketing has to deal with that two-pronged approach in everything that it does and the channels that get activated. The messaging that has to align with the audience is certainly the content that has to be created, and that can be complicated. Balancing that is a nuanced execution for marketing teams.”*”A CMO should run the entire marketing engine around content. And this is not to invoke the old adage of ‘Content is king,' but, you know, what are you at the end of the day? Delivering or communicating to your target audience, whether it's an existing customer or a prospect you're trying to win over. It is content and how you package that content, how you position it, what story and narrative is wrapped around the technology to deliver is really, at the end of the day, what matters.”Time Stamps[00:55] Meet Manish Gupta, 4-Time CMO[01:05] Why Silicon Valley?[08:22] What is Silicon Valley?[16:01] B2B Marketing Takeaways from Silicon Valley[24:02] Balancing Predictability and Innovation[28:10] Targeting Practitioners vs. Decision Makers[30:26] Creating How-To Content[33:18] Importance of Content[39:33] Measuring ROI Around a Series of Content[42:13] Advice for CMOs on Content Strategy[43:25] Final Thoughts and TakeawaysLinksConnect with Manish on LinkedInAbout Remarkable!Remarkable! is created by the team at Caspian Studios, the premier B2B Podcast-as-a-Service company. Caspian creates both nonfiction and fiction series for B2B companies. If you want a fiction series check out our new offering - The Business Thriller - Hollywood style storytelling for B2B. Learn more at CaspianStudios.com. In today's episode, you heard from Ian Faison (CEO of Caspian Studios) and Meredith Gooderham (Head of Production). Remarkable was produced this week by Jess Avellino, mixed by Scott Goodrich, and our theme song is “Solomon” by FALAK. Create something remarkable. Rise above the noise.

Scaling a company requires more than just great ideas — it demands execution, urgency and adaptability. In this episode, Dan Rogers, CEO of LaunchDarkly, shares how he has built high-performance teams and driven sustained success, drawing from his experience leading growth at Microsoft, Amazon, Salesforce and ServiceNow.Specifically, Dan covers:(03:24) Dan's passion for technology led to an early start and a journey to Silicon Valley.(06:01) Why owning a number early in a career builds strong leadership skills.(11:28) Technical audiences want guidance, not marketing — stay product-focused.(25:25) Why customer insights should shape business decisions, not pre-set playbooks.(27:19) The role of execution in validating strategy and driving competitive advantage.(30:33) Competition is a sign of success — embrace it as part of growth.(37:45) AI application releases need control; rolling back and adjusting prompts is essential.(43:04) The importance of maintaining innovation speed while ensuring software reliability.(47:50) How feature flagging and controlled rollouts help companies move fast without breaking things.(51:49) Longevity in business requires discipline — prioritize fitness, diet and personal time with the same intensity as work.Resources Mentioned:Dan Rogershttps://www.linkedin.com/in/dan-rogers-a1717a/LaunchDarkly | LinkedInhttps://www.linkedin.com/company/launchdarkly/LaunchDarkly | Websitehttps://www.launchdarkly.comThis episode is brought to you by:Leverage community-led growth to skyrocket your business. “From Grassroots to Greatness” by author Lloyed Lobo will help you master 13 game-changing rules from some of the most iconic brands in the world — like Apple, Atlassian, CrossFit, Harley-Davidson, HubSpot, Red Bull and many more — to attract superfans of your own that will propel you to new heights. Grab your copy today at FromGrassrootsToGreatness.com.Each year the US and Canadian governments provide more than $20 billion in R&D tax credits and innovation incentives to fund businesses. But the application process is cumbersome, prone to costly audits and receiving the money can take as long as 16 months. Boast automates this process, enabling companies to get more money faster without the paperwork and audit risk. We don't get paid until you do! Find out if you qualify today at https://Boast.AI.Launch Academy is one of the top global tech hubs for international entrepreneurs and a designated organization for Canada's Startup Visa. Since 2012, Launch has worked with more than 6,000 entrepreneurs from over 100 countries, of which 300 have grown their startups to seed and Series A stage and raised over $2 billion in funding. To learn more about Launch's programs or the Canadian Startup Visa, visit https://LaunchAcademy.ca.Content Allies helps B2B companies build revenue-generating podcasts. We recommend them to any B2B company that is looking to launch or streamline its podcast production. Learn more at https://contentallies.com.#Leadership #StartupGrowth #SoftwareDevelopment #Product #Marketing #Innovation #StartUp #GenerativeAI #AI

This is the Engineering Culture Podcast, from the people behind InfoQ.com and the QCon conferences. In this podcast Shane Hastie, Lead Editor for Culture & Methods spoke to Claire Vo, Chief Product and Technology Officer at LaunchDarkly, about building high-performing, customer-centric teams, fostering a culture of experimentation, and preparing for the future of AI-driven software development. Read a transcript of this interview: https://bit.ly/4ih8MFY Subscribe to the Software Architects' Newsletter for your monthly guide to the essential news and experience from industry peers on emerging patterns and technologies: https://www.infoq.com/software-architects-newsletter Upcoming Events: QCon London (April 7-10, 2025) Discover new ideas and insights from senior practitioners driving change and innovation in software development. https://qconlondon.com/ InfoQ Dev Summit Boston (June 9-10, 2025) Actionable insights on today's critical dev priorities. devsummit.infoq.com/conference/boston2025 InfoQ Dev Summit Munich (October 15-16, 2025) Essential insights on critical software development priorities. https://devsummit.infoq.com/conference/munich2025 QCon San Francisco 2025 (17-21, 2025) Get practical inspiration and best practices on emerging software trends directly from senior software developers at early adopter companies. https://qconsf.com/ InfoQ Dev Summit New York (Save the date - December 2025) https://devsummit.infoq.com/ The InfoQ Podcasts: Weekly inspiration to drive innovation and build great teams from senior software leaders. Listen to all our podcasts and read interview transcripts: - The InfoQ Podcast https://www.infoq.com/podcasts/ - Engineering Culture Podcast by InfoQ https://www.infoq.com/podcasts/#engineering_culture - Generally AI: https://www.infoq.com/generally-ai-podcast/ Follow InfoQ: - Mastodon: https://techhub.social/@infoq - Twitter: twitter.com/InfoQ - LinkedIn: www.linkedin.com/company/infoq - Facebook: bit.ly/2jmlyG8 - Instagram: @infoqdotcom - Youtube: www.youtube.com/infoq Write for InfoQ: Learn and share the changes and innovations in professional software development. - Join a community of experts. - Increase your visibility. - Grow your career. https://www.infoq.com/write-for-infoq

Our guest for Episode 72 is Karan Singh, VP GTM Strategy, Revenue Operations & Enablement, LaunchDarkly. Before joining LaunchDarkly, Karan held senior leadership positions at Sapphire Ventures, Procore Technologies, and SalesSource, where he spearheaded major product rollouts and guided organizational growth. In this episode, Ross and Karan discuss the importance of establishing consistent rituals and cadences, break down how to set and track SMART goals, and examine how technology can act as a force multiplier.

Executives from DataRobot, LaunchDarkly and ServiceNow share strategies, actions and recommendations to achieve profitable growth in today's competitive SaaS landscape.Topics Include:Introduction of panelists from DataRobot, LaunchDarkly & ServiceNowServiceNow's journey from service management to workflow orchestration platform.DataRobot's evolution as comprehensive AI platform before AI boom.LaunchDarkly's focus on helping teams decouple release from deploy.Rule of 40: balancing revenue growth and profit margin.ServiceNow exceeding standards with Rule of 50-60 approach.Vertical markets expansion as key strategy for sustainable growth.AWS Marketplace enabling largest-ever deal for ServiceNow.R&D investment effectiveness through experimentation and feature management.Developer efficiency as driver of profitable SaaS growth.Competition through data-driven decisions rather than guesswork.Speed and iteration frequency determining competitive advantage in SaaS.Balancing innovation with early customer adoption for AI products.Product managers should adopt revenue goals and variable compensation.Product-led growth versus sales-led motion: strategies and frictions.Sales-led growth optimized for enterprise; PLG for practitioners.Marketplace-led growth as complementary go-to-market strategy.Customer acquisition cost (CAC) as primary driver of margin erosion.Pricing and packaging philosophy: platform versus consumption models.Value realization must precede pricing and packaging discussions.Good-better-best pricing model used by LaunchDarkly.Security as foundation of trust in software delivery.LaunchDarkly's Guardian Edition for high-risk software release scenarios.Security for regulated industries through public cloud partnerships.GenAI security: benchmarks, tests, and governance to prevent issues.M&A strategy: ServiceNow's 33 acquisitions for features, not revenue.Replatforming acquisitions into core architecture for consistent experience.Balancing technology integration with people aspects during acquisitions.Trends in buying groups: AI budgets and tool consolidation.Implementing revenue goals in product teams for new initiatives.Participants:Prajakta Damle – Head of Product / SVP of Product, DataRobotClaire Vo – Chief Product & Technology Officer, LaunchDarklyAnshuman Didwania – VP/GM, Hyperscalers Business Group, ServiceNowAkshay Patel – Global SaaS Strategist, Amazon Web ServicesSee how Amazon Web Services gives you the freedom to migrate, innovate, and scale your software company at https://aws.amazon/isv/

Corey Quinn welcomes Adam Zimman back to Screaming in the Cloud for a sponsored episode featuring Heroku by Salesforce. As Head of Product Marketing, Adam discusses after years of stagnation following its Salesforce acquisition. Recent investments and a dedicated team signal a renewed focus on developer experience. The duo explores Heroku's impact on modern app development, its role in popularizing the 12-Factor App model, and the decision to retire its free tier. Adam highlights key updates, including Kubernetes replatforming, .NET support, and AI tools for managed inference and agents. He also teases his upcoming book, Progressive Delivery, set for release next year.Show Highlights(0:00) Intro(1:01) Heroku sponsor read(1:39) How Heroku became resurgent(5:46) Heroku's legacy(9:53) Adam's thoughts on people's response to the free tier going away(10:55) Heroku's target customer(s)(13:51) Heroku sponsor read(14:19) How Heroku saves organizations money and developed over time(20:08) Heroku's re:Invent announcements(24:53) How modern-day developers have reacted to Heroku's resurgence(27:47) Where people can learn more about Heroku About Adam ZimmanAdam Zimman is Technologist and Author currently serving as the Head of Product Marketing at Heroku by SalesForce. Previously, he was a Venture Capital Advisor providing guidance on leadership, platform architecture, product marketing, and GTM strategy. He has over 20 years of experience working in a variety of roles from software engineering to technical sales. He has worked in both enterprise and consumer companies such as VMware, EMC, GitHub, and LaunchDarkly.Adam is driven by a passion for inclusive leadership and solving problems with technology. He is a co-author of Progressive Delivery: Build the right thing, for the right people, at the right time. His perspective has been shaped by a degree (AB) from Bowdoin College with a dual-focus in  Physics and Visual Art, an ongoing adventure as a husband and father, and a childhood career as a fire juggler.LinksHeroku's website: https://www.heroku.com/Adam's Bluesky: https://bsky.app/profile/azimman.bsky.socialAdam's Mastodon: https://hachyderm.io/@azAdam's LinkedIn: https://www.linkedin.com/in/adamzimman/Personal site: https://progressivedelivery.com/SponsorHeroku: http://heroku.com/

Follow me @samirkaji for my thoughts on the venture market, with a focus on the continued evolution of the VC landscape.Today I'm excited to speak with the founding team of Chemistry, a new venture firm led by Kristina Shen, Ethan Kurzweil, and Mark Goldberg, who recently spun-out of blue chip firms Andreessen Horowitz, Bessemer, and Index Ventures, respectively. The firm just announced a significantly oversubscribed $350MM debut fund. As a new entrant to the market (in the toughest time to start a new firm in over a decade), I wanted to ask them about their blueprint for building a firm, including how they chose to partner up and the work they did beforehand, LP strategies and selection, and what they felt was their unique reason to exist in a highly competitive market. About Kristina ShenKristina Shen is Co-Founder and Managing Partner at Chemistry Ventures, overseeing a $350M fund focused on early-stage software investments. Formerly a General Partner at Andreessen Horowitz (2019-2024), she led significant investments in Mux, Pave, Wrapbook, and Rutter. Kristina specialized in high-growth startups.She began her venture career as a Partner at Bessemer Venture Partners (2013-2019), working with companies such as Gainsight, Instructure, and ServiceTitan. Previously, she worked in investment banking at Goldman Sachs and Credit Suisse, focusing on technology sectors.About Mark GoldbergMark Goldberg is Co-Founder and Managing Partner at Chemistry Ventures since, investing in seed and Series A software startups. Previously, a Partner at Index Ventures (2015-2023), he worked with companies such as Plaid, Pilot, Intercom, and Motive, establishing a strong fintech and software portfolio.Prior to Index, Mark worked at Dropbox in Business Strategy & Operations and Strategic Finance (2013-2015), where he contributed to growth strategies during Dropbox's scaling phase.He started his career as an Analyst at Morgan Stanley (2007-2010) before joining Hudson Clean Energy as a Senior Associate. Mark holds an AB in International Relations from Brown University.About Ethan KurzweilEthan Kurzweil is Co-Founder and Managing Partner at Chemistry Ventures, leading investments at the seed stage for tech-driven startups. He also serves as a board member for companies like Intercom and LaunchDarkly.Previously, Ethan was a Partner at Bessemer Venture Partners (2008-2024), where he worked with companies such as HashiCorp, Twilio, and Twitch. His focus on software and digital platforms spanned roles as board member and investor, contributing to significant IPOs and acquisitions.Early in his career, Ethan worked in business development at Linden Lab (creators of Second Life) and served as a Senior Manager in the CEO's Office at Dow Jones. He holds an MBA from Harvard Business School and an AB in Economics from Stanford University.In this episode, we discuss:* (01:43): Importance of Team Chemistry and Partnership Formation* (03:27): Challenges of Building a Firm in the Current Environment* (08:00): Unique Value Proposition for Early-Stage Founders* (10:18): Early-Stage Focus and Differentiation from Large VC Firms* (16:12): Fundraising Insights and LP Relationship Building* (19:00): Choosing Aligned LPs and Targeting Long-Term Partnerships* (27:23): Single-Trigger Investment Decision-Making Model* (30:12): Balancing Conviction with Collaborative Feedback* (35:23): Independent Decision-Making for Follow-On Investments* (39:19): Personal Contrarian Beliefs about the Venture Industry* (42:18): Closing Remarks on Building a New Venture FranchiseI'd love to know what you took away from this conversation with Kristina, Mark, and Ethan. Follow me @SamirKaji and give me your insights and questions with the hashtag #ventureunlocked. If you'd like to be considered as a guest or have someone you'd like to hear from (GP or LP), drop me a direct message on Twitter.Podcast Production support provided by Agent Bee This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit ventureunlocked.substack.com

Sales leadership is one of the hardest jobs in the company. Your success is black and white—you've either hit your number, or you haven't—and getting a group of sellers moving in the same direction isn't easy, as anyone in RevOps knows.Today we're joined by Kyle Asay to dig into what separates top-performing sales leaders from the rest. We talk about how to scale sales excellence, balance standardization with creativity, and build trust and rapport at every stage of the sales process. Kyle also shares his insights on navigating the transition from individual contributor to sales leader, the real role of AI in outbound, and how to build a side hustle while leading a team. Packed with practical frameworks and hard-won lessons, this conversation is a must-listen for sales leaders, individual sellers, and revenue operators supporting sales teams. Thanks to Our SponsorMany thanks to the sponsor of this episode - Knak. If you don't know them (you should), Knak is an amazing email and landing page builder that integrates directly with your marketing automation platform. You set the brand guidelines and then give your users a building experience that's slick, modern and beautiful. When they're done, everything goes to your MAP at the push of a button. What's more, it supports global teams, approval workflows, and it's got your integrations. Click the link below to get a special offer just for my listeners. Try Knak About Today's Guest Kyle Asay started his career in sales as an SDR at Qualtrics, where he qualified for five consecutive President's Clubs as an AE, front-line leader, and second-line leader. After an incredible 8.5 years at Qualtrics, he's gone on to serve as a sales leader for MongoDB and currently at LaunchDarkly. You can also find him sharing his frameworks with over 10,000 sellers at SalesIntroverts.comhttps://www.linkedin.com/in/kyleasay/Key Topics[00:00] - Introduction[01:52] - Current selling environment[04:46] - Scaling sales excellence[10:05] - Right-sizing discovery phase[12:39] - Building trust and rapport[17:53] - Transitioning from sales IC to sales leader[20:46] - The job of a sales leader[24:10] - Identifying the right people[27:47] - Standardized process vs. individual ingenuity[30:59] - Handling the pressure of sales leadership[34:55] - AEs and SDR alignment [42:47] - AI SDRs[44:59] - Sales and RevOps relationship[48:23] - Building a side hustle Thanks to Our SponsorThis November, MOps-Apalooza is back in sunny, Anaheim, California, and it's going to be the marketing ops event of the year, packed with hands-on learning from real practitioners. This is the only truly community-led tech-agnostic MOPS conference out there. It's got the best speakers, the best networking, the best social events, and maybe even a trip to Disneyland. This isn't your 50,000 person tech company conference. It's an intimate gathering of folks who are in the trenches every day. Registration is capped at 700 attendees, and tickets are going fast. MOps-Apalooza 2024 Resource LinksSales Introverts Learn MoreVisit the RevOps FM Substack for our weekly newsletter: Newsletter

On this episode, Carolyn Beaudoin joins us on the podcast. Carolyn is a seasoned copywriter and conversion rate optimizer. Working freelance, agency-side, and in-house, she's worked with some of the fastest-growing brands on the planet, including LaunchDarkly, Resident Home, Glowforge, Nextiva, and Shopify Plus.  Now, Carolyn is the co-founder and Head of Creative Strategy at […] The post 365: Unconventional Email Design Approaches that Work Every Time first appeared on Persuasion by the Pint.

Episode SummaryIn this episode Bill Kenney shares his journey from an art school student to a business owner, and how he co-founded Focus Lab with a business partner. The discussion covers common reasons why companies need to rebrand, such as company maturity, M&A activity, and addressing trademark issues. Bill offers tips for successful branding projects, including setting expectations, keeping the core team small, and trusting the process even when faced with criticism. He emphasizes maintaining a company's core values and culture while adapting to changing market needs. The episode also explores potential pitfalls in B2B branding, such as over-relying on competitors and seeking too many subjective opinions. About the guest Bill Kenney is the Co-founder, Partner, and CEO of Focus Lab and Odi, two global B2B branding agencies. Past clients include Marketo, Salesloft, Zuora, Braze, Outreach, LaunchDarkly, Twilio, Adobe, ASAPP, Luminate, Netflix, Shopify, and many others. Bill is also the author of the Amazon best-seller "Conquer Your Rebrand." When he's not working you can find Bill in one of three places: his couch, the local Jiu-Jitsu gym, or his camper in Vermont. Connect with Bill Kenney Key takeaways- Common reasons for rebranding include company maturity, M&A activity, trademark issues, and the need to differentiate from competitors. - Tips for successful branding projects include setting expectations, keeping the core team small, and trusting the process even when faced with criticism. - Maintaining a company's core values and culture is crucial when rebranding, as it helps bring the brand's heart and soul forward. - Potential pitfalls in B2B branding include over-relying on competitors, seeking too many subjective opinions, and over-emphasizing measuring ROI. - AI can be a useful tool in enhancing visual storytelling, but it cannot replace the human interaction and strategic decision-making required for successful branding. Quotes"The brand is going to be so much larger and different in received through different meanings than what it is when you're creating it." -Bill Kenney Recommended Resource Books: - “Daring Greatly” by Brene Brown - “Can't Hurt Me” by David Goggins - “Traction” by Gino Wickman - “The Infinite Game” by Simon Sinek Podcasts:- A Bit of Optimism hosted by Simon Sinek ⁠Connect with Bill Kenney⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ | ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Follow us on LinkedIn ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ |⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Website

Claire Vo built ChatPRD—an on-demand chief product officer powered by AI. It's now used by over 10,000 product managers and is pulling in six figures in revenue. The best part? Claire has a demanding day job as the CPO at LaunchDarkly. So she built all of ChatPRD herself—over the weekend—with AI. I sat down with Claire to talk about how ChatPRD works, how she built it as a side hustle using AI, and all of the ways she's using AI tools to accelerate her work and life. We get into: How she used AI to build ChatPRD over Thanksgiving break The part of product management that Claire thinks AI will disrupt Why the PMs of tomorrow will be “proto-managers” who create prototypes rather than just specs How junior PMs can use AI to upskill faster The ways in which ChatPRD is baked into her own workflow How building ChatPRD is making Claire a better PM How Claire uses AI as a tech-forward parent This is a must-watch for anyone interested in turning their side hustle into a thriving business or who works in product. If you found this episode interesting, please like, subscribe, comment, and share! Want even more? Sign up for Every to unlock our ultimate guide to prompting ChatGPT here. It's usually only for paying subscribers, but you can get it here for free. To hear more from Dan Shipper: Subscribe to Every: https://every.to/subscribe Follow him on X: https://twitter.com/danshipper Links to resources mentioned in the episode: Claire Vo: https://x.com/clairevo ChatPRD: https://www.chatprd.ai/; https://x.com/chatprd; https://www.linkedin.com/company/chatprd/; https://www.youtube.com/@ChatPRD Some of the AI tools that Claire used to build ChatPRD: http://Clerk.dev; https://tiptap.dev/ Greeking Out, the Greek mythology podcast that Claire's son enjoys: https://www.nationalgeographic.com/podcasts/greeking-out

Today we have Brian Rinaldi from LaunchDarkly on the show. This is the final episode of our in person coverage at the SHIFT Conference in Miami. And although Brian works at LaunchDarkly, we actually didn't talk at all about his employer and instead chatted about Jamstack. Brian has a long history with Jamstack, has written a lot about it. Jamstack was popularized and created by Netlify. And there's been a lot of history of controversy with the term. Some people think of it's merely a branding ploy or a marketing thing, and others find it simply confusing because we have terms like LAMP stack, MEAN stack and MERN stack. So Jamstack automatically gets lumped in with those, but it's not actually a technology stack. It's an architectural pattern. Recently, Jamstack has been giving away to what is known as composable frontends and we picked Brian's brain on this and what this means not only for Jamstack, but also the future web development.

Revolutionizing Productivity: Feedback on Loom, Linear, and Even LaunchDarkly w/ Claire Vo In part two of our "Unsolicited Feedback," host Fareed Mosavat and our esteemed guest, Claire Vo (CPO at LaunchDarkly, Founder of ChatPRD), explore significant advancements in AI and collaboration tools, with a spotlight on Loom and Linear's latest innovations. The episode delves into how these tools are not only enhancing productivity but also potentially reshaping communication norms in professional environments. Check out a full summary of the takeaways and lessons at ➡️ https://www.unsolicitedfeedback.co/ 00:00 Introduction 02:17 Exploring Loom's Innovations and Atlassian Integration 06:57 The Future of Collaboration: Video, Audio, and AI 14:42 Loom's Role in Atlassian's Ecosystem and Future Directions 17:33 Linear's Approach to Enhancing Product Development 20:55 The Challenge of Integrating Docs and Tasks 30:41 The Power of Being Your Own Customer 35:47 Embracing New User Experience and Onboarding Thank you for listening to Unsolicited Feedback! Don't forget to hit subscribe on the podcast network of your choice! And sign up for our mailing list at ➡️ https://www.unsolicitedfeedback.co/

Building ChatPRD and

Claire Vo is the chief product officer at LaunchDarkly and the founder of ChatPRD, likely the most popular PM-specific AI product out there. Before LaunchDarkly, she was a longtime chief product officer at Color and Optimizely. Claire has founded and managed two other companies, Pretty HQ and Experiment Engine, the latter of which Optimizely acquired in 2017. In our conversation, we discuss:• Knowing what you want in your career and being clear about it• Finding your zone of genius and how to operate within it• How to maintain a fast pace in larger companies• How to make it easy for your boss to help you achieve your goals• Advice for navigating the tech industry as a woman• The role of a CPTO and the benefits it brings to organizations• Why she built ChatPRD• Tips for building your own AI tools• The impact of AI on product management and what skills will continue to be important—Brought to you by:• Orb—The flexible billing engine for modern pricing• Dovetail—Bring your customer into every decision• Vanta—Automate compliance. Simplify security—Find the full transcript at: https://www.lennysnewsletter.com/p/bending-the-universe-in-your-favor—Where to find Claire Vo:• X: https://twitter.com/clairevo• LinkedIn: https://www.linkedin.com/in/clairevo/• TikTok: https://www.tiktok.com/@chiefproductofficer—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• X: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—In this episode, we cover:(00:00) Claire's background(04:50) How to achieve career progression(10:11) Avoiding promotion obsession(13:50) How Claire stepped into leadership roles(17:24) Operating in your zone of genius(23:03) How to maintain a fast pace(27:46) Setting a high bar for quality and talent(29:54) Normalizing feedback(33:09) Being a woman in tech(47:09) The role of a CPTO(54:19) Building ChatPRD(59:39) Tips for building a GPT(01:02:27) The impact of AI on product management(01:08:08) How AI is changing the product management role(01:14:36) Efficiency gains with ChatPRD(01:16:39) Contrarian corner: sales-led product organizations(01:20:11) Lightning round—Referenced:• LaunchDarkly: https://launchdarkly.com/• Define your zone of genius: Laura Garnett at TEDxMillRiver: https://www.youtube.com/watch?v=gQ7_r2oWlrw• Energy Audit: https://beta.mocharymethod.com/blog-post/energy-audit• How to fire people with grace, work through fear, and nurture innovation | Matt Mochary: https://www.lennyspodcast.com/videos/how-to-fire-people-with-grace-work-through-fear-and-nurture-innovation-matt-mochary/• Radical Candor: From theory to practice with author Kim Scott: https://www.lennyspodcast.com/radical-candor-from-theory-to-practice-with-author-kim-scott/• Optimizely: https://www.optimizely.com/• GitLab: https://about.gitlab.com/• ChatPRD: https://www.chatprd.ai/• You should be playing with GPTs at work: https://www.lennysnewsletter.com/p/you-should-be-playing-with-gpts-at• SpaceX's Starship: https://www.spacex.com/vehicles/starship/• GitHub Copilot: https://github.com/features/copilot• Product management theater | Marty Cagan (Silicon Valley Product Group): https://www.lennyspodcast.com/product-management-theater-marty-cagan-silicon-valley-product-group/• High Growth Handbook: Scaling Startups from 10 to 10,000 People: https://www.amazon.com/High-Growth-Handbook-Elad-Gil/dp/1732265100• Scaling People: Tactics for Management and Company Building: https://www.amazon.com/Scaling-People-Tactics-Management-Building/dp/1953953212• Stripe Press: https://press.stripe.com/• Circe: https://www.amazon.com/Circe-Madeline-Miller/dp/0316556327• Poor Things: https://www.imdb.com/title/tt14230458/• Mythic Quest on AppleTV+: https://tv.apple.com/us/show/mythic-quest/umc.cmc.1nfdfd5zlk05fo1bwwetzldy3• Silicon Valley on HBO: https://www.hbo.com/silicon-valley• Chrysler Pacifica: https://www.chrysler.com/pacifica.html• Waymo: https://waymo.com/—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.—Lenny may be an investor in the companies discussed. Get full access to Lenny's Newsletter at www.lennysnewsletter.com/subscribe

As the Chief Revenue Officer at Skyflow, Tammy Sexton is responsible for driving revenue growth and scaling the go-to-market team for the company's innovative data privacy platform. With more than 20 years of experience in enterprise sales,Tammy has a proven track record of leading and developing high-performing sales teams, building strategic partnerships, and delivering value to customers across various industries and regions. She has successfully managed and grown sales organizations at early and mid-stage startups, such as LaunchDarkly, LogicHub, and Sumo Logic, as well as established companies, such as PagerDuty, EMC, and PTC.In this episode of the Revenue Builders Podcast, Tammy discusses the importance of data privacy and how Skyflow's data vault as a service helps companies protect sensitive information. She shares insights on the impact of data breaches on brand reputation and revenue, as well as the role of data privacy in building customer trust. Tammy also reflects on her journey as a sales leader and provides valuable lessons on transitioning from an account executive to a manager, managing managers, and becoming a CRO.Tune in to this conversation with John McMahon and John Kaplan on the Revenue Builders podcast.HERE ARE SOME KEY SECTIONS TO CHECK OUT[00:01:19] Tammy Sexton's background and role at Skyflow[00:03:48] Examples of companies that use data vaults for privacy protection[00:05:18] Skyflow's certification program and compliance benefits[00:07:53] Tammy Sexton's experience and lessons learned in sales leadership[00:10:22] Avoiding the mistake of becoming a "super rep" as a manager[00:14:12] Coaching first line managers on recruitment and finding the right fit for the company[00:20:17] Focusing on the basics and fundamentals as a second line manager to make a big difference[00:27:48] Challenges of managing different groups as a CRO[00:40:48] Key things to learn as a new CRO in a company[01:06:44] Discovery and pain metrics drive urgencyADDITIONAL RESOURCESLearn more about Tammy Sexton and about their company.LinkedIn: https://www.linkedin.com/in/tammy-sexton/Company LinkedIn: https://www.linkedin.com/company/skyflow/Email: Tammy Sexton tammy@skyflow.comDownload our Sales Transformation Guide for Leaders:https://forc.mx/3sdtEZJHIGHLIGHT QUOTES[00:50:55] "So it's not just about the data. It's not just about necessarily the numbers at the top, but the conversion numbers, the SC conversion from POV to win, the AE conversion at each stage. So if I can sit down with a manager that has six AEs and help that manager with data that says this AE always gets stuck at this part of the sales cycle. Why do they have a 20 percent POV win rate and technical win rate when all the other AEs have a 60 percent chance of moving to the next stage."[01:06:26] "Nothing better than good discovery and good pain and good influence on decision criteria. And at the end of the day, the metric will drive the urgency. If you did it right. If you did it right, go back to the basics."

Rachel Dines, Head of Product and Technical Marketing at Chronosphere, joins Corey on Screaming in the Cloud to discuss why creating a cloud-native observability strategy is so critical, and the challenges that come with both defining and accomplishing that strategy to fit your current and future observability needs. Rachel explains how Chronosphere is taking an open-source approach to observability, and why it's more important than ever to acknowledge that the stakes and costs are much higher when it comes to observability in the cloud. About RachelRachel leads product and technical marketing for Chronosphere. Previously, Rachel wore lots of marketing hats at CloudHealth (acquired by VMware), and before that, she led product marketing for cloud-integrated storage at NetApp. She also spent many years as an analyst at Forrester Research. Outside of work, Rachel tries to keep up with her young son and hyper-active dog, and when she has time, enjoys crafting and eating out at local restaurants in Boston where she's based.Links Referenced: Chronosphere: https://chronosphere.io/ LinkedIn: https://www.linkedin.com/in/rdines/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Today's featured guest episode is brought to us by our friends at Chronosphere, and they have also brought us Rachel Dines, their Head of Product and Solutions Marketing. Rachel, great to talk to you again.Rachel: Hi, Corey. Yeah, great to talk to you, too.Corey: Watching your trajectory has been really interesting, just because starting off, when we first started, I guess, learning who each other were, you were working at CloudHealth which has since become VMware. And I was trying to figure out, huh, the cloud runs on money. How about that? It feels like it was a thousand years ago, but neither one of us is quite that old.Rachel: It does feel like several lifetimes ago. You were just this snarky guy with a few followers on Twitter, and I was trying to figure out what you were doing mucking around with my customers [laugh]. Then [laugh] we kind of both figured out what we're doing, right?Corey: So, speaking of that iterative process, today, you are at Chronosphere, which is an observability company. We would have called it a monitoring company five years ago, but now that's become an insult after the observability war dust has settled. So, I want to talk to you about something that I've been kicking around for a while because I feel like there's a gap somewhere. Let's say that I build a crappy web app—because all of my web apps inherently are crappy—and it makes money through some mystical form of alchemy. And I have a bunch of users, and I eventually realize, huh, I should probably have a better observability story than waiting for the phone to ring and a customer telling me it's broken.So, I start instrumenting various aspects of it that seem to make sense. Maybe I go too low level, like looking at all the discs on every server to tell me if they're getting full or not, like their ancient servers. Maybe I just have a Pingdom equivalent of is the website up enough to respond to a packet? And as I wind up experiencing different failure modes and getting yelled at by different constituencies—in my own career trajectory, my own boss—you start instrumenting for all those different kinds of breakages, you start aggregating the logs somewhere and the volume gets bigger and bigger with time. But it feels like it's sort of a reactive process as you stumble through that entire environment.And I know it's not just me because I've seen this unfold in similar ways in a bunch of different companies. It feels to me, very strongly, like it is something that happens to you, rather than something you set about from day one with a strategy in mind. What's your take on an effective way to think about strategy when it comes to observability?Rachel: You just nailed it. That's exactly the kind of progression that we so often see. And that's what I really was excited to talk with you about today—Corey: Oh, thank God. I was worried for a minute there that you'd be like, “What the hell are you talking about? Are you just, like, some sort of crap engineer?” And, “Yes, but it's mean of you to say it.” But yeah, what I'm trying to figure out is there some magic that I just was never connecting? Because it always feels like you're in trouble because the site's always broken, and oh, like, if the disk fills up, yeah, oh, now we're going to start monitoring to make sure the disk doesn't fill up. Then you wind up getting barraged with alerts, and no one wins, and it's an uncomfortable period of time.Rachel: Uncomfortable period of time. That is one very polite way to put it. I mean, I will say, it is very rare to find a company that actually sits down and thinks, “This is our observability strategy. This is what we want to get out of observability.” Like, you can think about a strategy and, like, the old school sense, and you know, as an industry analyst, so I'm going to have to go back to, like, my roots at Forrester with thinking about, like, the people, and the process, and the technology.But really what the bigger component here is like, what's the business impact? What do you want to get out of your observability platform? What are you trying to achieve? And a lot of the time, people have thought, “Oh, observability strategy. Great, I'm just going to buy a tool. That's it. Like, that's my strategy.”And I hate to bring it to you, but buying tools is not a strategy. I'm not going to say, like, buy this tool. I'm not even going to say, “Buy Chronosphere.” That's not a strategy. Well, you should buy Chronosphere. But that's not a strategy.Corey: Of course. I'm going to throw the money by the wheelbarrow at various observability vendors, and hope it solves my problem. But if that solved the problem—I've got to be direct—I've never spoken to those customers.Rachel: Exactly. I mean, that's why this space is such a great one to come in and be very disruptive in. And I think, back in the days when we were running in data centers, maybe even before virtual machines, you could probably get away with not having a monitoring strategy—I'm not going to call it observability; it's not we call the back then—you could get away with not having a strategy because what was the worst that was going to happen, right? It wasn't like there was a finite amount that your monitoring bill could be, there was a finite amount that your customer impact could be. Like, you're paying the penny slots, right?We're not on the penny slots anymore. We're in the $50 craps table, and it's Las Vegas, and if you lose the game, you're going to have to run down the street without your shirt. Like, the game and the stakes have changed, and we're still pretending like we're playing penny slots, and we're not anymore.Corey: That's a good way of framing it. I mean, I still remember some of my biggest observability challenges were building highly available rsyslog clusters so that you could bounce a member and not lose any log data because some of that was transactionally important. And we've gone beyond that to a stupendous degree, but it still feels like you don't wind up building this into the application from day one. More's the pity because if you did, and did that intelligently, that opens up a whole world of possibilities. I dream of that changing where one day, whenever you start to build an app, oh, and we just push the button and automatically instrument with OTel, so you instrument the thing once everywhere it makes sense to do it, and then you can do your vendor selection and what you said were decisions later in time. But these days, we're not there.Rachel: Well, I mean, and there's also the question of just the legacy environment and the tech debt. Even if you wanted to, the—actually I was having a beer yesterday with a friend who's a VP of Engineering, and he's got his new environment that they're building with observability instrumented from the start. How beautiful. They've got OTel, they're going to have tracing. And then he's got his legacy environment, which is a hot mess.So, you know, there's always going to be this bridge of the old and the new. But this was where it comes back to no matter where you're at, you can stop and think, like, “What are we doing and why?” What is the cost of this? And not just cost in dollars, which I know you and I could talk about very deeply for a long period of time, but like, the opportunity costs. Developers are working on stuff that they could be working on something that's more valuable.Or like the cost of making people work round the clock, trying to troubleshoot issues when there could be an easier way. So, I think it's like stepping back and thinking about cost in terms of dollar sense, time, opportunity, and then also impact, and starting to make some decisions about what you're going to do in the future that's different. Once again, you might be stuck with some legacy stuff that you can't really change that much, but [laugh] you got to be realistic about where you're at.Corey: I think that that is a… it's a hard lesson to be very direct, in that, companies need to learn it the hard way, for better or worse. Honestly, this is one of the things that I always noticed in startup land, where you had a whole bunch of, frankly, relatively early-career engineers in their early-20s, if not younger. But then the ops person was always significantly older because the thing you actually want to hear from your ops person, regardless of how you slice it, is, “Oh, yeah, I've seen this kind of problem before. Here's how we fixed it.” Or even better, “Here's the thing we're doing, and I know how that's going to become a problem. Let's fix it before it does.” It's the, “What are you buying by bringing that person in?” “Experience, mostly.”Rachel: Yeah, that's an interesting point you make, and it kind of leads me down this little bit of a side note, but a really interesting antipattern that I've been seeing in a lot of companies is that more seasoned ops person, they're the one who everyone calls when something goes wrong. Like, they're the one who, like, “Oh, my God, I don't know how to fix it. This is a big hairy problem,” I call that one ops person, or I call that very experienced person. That experience person then becomes this huge bottleneck into solving problems that people don't really—they might even be the only one who knows how to use the observability tool. So, if we can't find a way to democratize our observability tooling a little bit more so, like, just day-to-day engineers, like, more junior engineers, newer ones, people who are still ramping, can actually use the tool and be successful, we're going to have a big problem when these ops people walk out the door, maybe they retire, maybe they just get sick of it. We have these massive bottlenecks in organizations, whether it's ops or DevOps or whatever, that I see often exacerbated by observability tools. Just a side note.Corey: Yeah. On some level, it feels like a lot of these things can be fixed with tooling. And I'm not going to say that tools aren't important. You ever tried to implement observability by hand? It doesn't work. There have to be computers somewhere in the loop, if nothing else.And then it just seems to devolve into a giant swamp of different companies, doing different things, taking different approaches. And, on some level, whenever you read the marketing or hear the stories any of these companies tell you also to normalize it from translating from whatever marketing language they've got into something that comports with the reality of your own environment and seeing if they align. And that feels like it is so much easier said than done.Rachel: This is a noisy space, that is for sure. And you know, I think we could go out to ten people right now and ask those ten people to define observability, and we would come back with ten different definitions. And then if you throw a marketing person in the mix, right—guilty as charged, and I know you're a marketing person, too, Corey, so you got to take some of the blame—it gets mucky, right? But like I said a minute ago, the answer is not tools. Tools can be part of the strategy, but if you're just thinking, “I'm going to buy a tool and that's going to solve my problem,” you're going to end up like this company I was talking to recently that has 25 different observability tools.And not only do they have 25 different observability tools, what's worse is they have 25 different definitions for their SLOs and 25 different names for the same metric. And to be honest, it's just a mess. I'm not saying, like, go be Draconian and, you know, tell all the engineers, like, “You can only use this tool [unintelligible 00:10:34] use that tool,” you got to figure out this kind of balance of, like, hands-on, hands-off, you know? How much do you centralize, how much do you push and standardize? Otherwise, you end up with just a huge mess.Corey: On some level, it feels like it was easier back in the days of building it yourself with Nagios because there's only one answer, and it sucks, unless you want to start going down the world of HP OpenView. Which step one: hire a 50-person team to manage OpenView. Okay, that's not going to solve my problem either. So, let's get a little more specific. How does Chronosphere approach this?Because historically, when I've spoken to folks at Chronosphere, there isn't that much of a day one story, in that, “I'm going to build a crappy web app. Let's instrument it for Chronosphere.” There's a certain, “You must be at least this tall to ride,” implicit expectation built into the product just based upon its origins. And I'm not saying that doesn't make sense, but it also means there's really no such thing as a greenfield build out for you either.Rachel: Well, yes and no. I mean, I think there's no green fields out there because everyone's doing something for observability, or monitoring, or whatever you want to call it, right? Whether they've got Nagios, whether they've got the Dog, whether they've got something else in there, they have some way of introspecting their systems, right? So, one of the things that Chronosphere is built on, that I actually think this is part of something—a way you might think about building out an observability strategy as well, is this concept of control and open-source compatibility. So, we only can collect data via open-source standards. You have to send this data via Prometheus, via Open Telemetry, it could be older standards, like, you know, statsd, Graphite, but we don't have any proprietary instrumentation.And if I was making a recommendation to somebody building out their observability strategy right now, I would say open, open, open, all day long because that gives you a huge amount of flexibility in the future. Because guess what? You know, you might put together an observability strategy that seems like it makes sense for right now—actually, I was talking to a B2B SaaS company that told me that they made a choice a couple of years ago on an observability tool. It seemed like the right choice at the time. They were growing so fast, they very quickly realized it was a terrible choice.But now, it's going to be really hard for them to migrate because it's all based on proprietary standards. Now, of course, a few years ago, they didn't have the luxury of Open Telemetry and all of these, but now that we have this, we can use these to kind of future-proof our mistakes. So, that's one big area that, once again, both my recommendation and happens to be our approach at Chronosphere.Corey: I think that that's a fair way of viewing it. It's a constant challenge, too, just because increasingly—you mentioned the Dog earlier, for example—I will say that for years, I have been asked whether or not at The Duckbill Group, we look at Azure bills or GCP bills. Nope, we are pure AWS. Recently, we started to hear that same inquiry specifically around Datadog, to the point where it has become a board-level concern at very large companies. And that is a challenge, on some level.I don't deviate from my typical path of I fix AWS bills, and that's enough impossible problems for one lifetime, but there is a strong sense of you want to record as much as possible for a variety of excellent reasons, but there's an implicit cost to doing that, and in many cases, the cost of observability becomes a massive contributor to the overall cost. Netflix has said in talks before that they're effectively an observability company that also happens to stream movies, just because it takes so much effort, engineering, and raw computing resources in order to get that data do something actionable with it. It's a hard problem.Rachel: It's a huge problem, and it's a big part of why I work at Chronosphere, to be honest. Because when I was—you know, towards the tail end at my previous company in cloud cost management, I had a lot of customers coming to me saying, “Hey, when are you going to tackle our Dog or our New Relic or whatever?” Similar to the experience you're having now, Corey, this was happening to me three, four years ago. And I noticed that there is definitely a correlation between people who are having these really big challenges with their observability bills and people that were adopting, like Kubernetes, and microservices and cloud-native. And it was around that time that I met the Chronosphere team, which is exactly what we do, right? We focus on observability for these cloud-native environments where observability data just goes, like, wild.We see 10X 20X as much observability data and that's what's driving up these costs. And yeah, it is becoming a board-level concern. I mean, and coming back to the concept of strategy, like if observability is the second or third most expensive item in your engineering bill—like, obviously, cloud infrastructure, number one—number two and number three is probably observability. How can you not have a strategy for that? How can this be something the board asks you about, and you're like, “What are we trying to get out of this? What's our purpose?” “Uhhhh… troubleshooting?”Corey: Right because it turns into business metrics as well. It's not just about is the site up or not. There's a—like, one of the things that always drove me nuts not just in the observability space, but even in cloud costing is where, okay, your costs have gone up this week so you get a frowny face, or it's in red, like traffic light coloring. Cool, but for a lot of architectures and a lot of customers, that's because you're doing a lot more volume. That translates directly into increased revenues, increased things you care about. You don't have the position or the context to say, “That's good,” or, “That's bad.” It simply is. And you can start deriving business insight from that. And I think that is the real observability story that I think has largely gone untold at tech conferences, at least.Rachel: It's so right. I mean, spending more on something is not inherently bad if you're getting more value out of it. And it definitely a challenge on the cloud cost management side. “My costs are going up, but my revenue is going up a lot faster, so I'm okay.” And I think some of the plays, like you know, we put observability in this box of, like, it's for low-level troubleshooting, but really, if you step back and think about it, there's a lot of larger, bigger picture initiatives that observability can contribute to in an org, like digital transformation. I know that's a buzzword, but, like that is a legit thing that a lot of CTOs are out there thinking about. Like, how do we, you know, get out of the tech debt world, and how do we get into cloud-native?Maybe it's developer efficiency. God, there's a lot of people talking about developer efficiency. Last week at KubeCon, that was one of the big, big topics. I mean, and yeah, what [laugh] what about cost savings? To me, we've put observability in a smaller box, and it needs to bust out.And I see this also in our customer base, you know? Customers like DoorDash use observability, not just to look at their infrastructure and their applications, but also look at their business. At any given minute, they know how many Dashers are on the road, how many orders are being placed, cut by geos, down to the—actually down to the second, and they can use that to make decisions.Corey: This is one of those things that I always found a little strange coming from the world of running systems in large [unintelligible 00:17:28] environments to fixing AWS bills. There's nothing that even resembles a fast, reactive response in the world of AWS billing. You wind up with a runaway bill, they're going to resolve that over a period of weeks, on Seattle business hours. If you wind up spinning something up that creates a whole bunch of very expensive drivers behind your bill, it's going to take three days, in most cases, before that starts showing up anywhere that you can reasonably expect to get at it. The idea of near real time is a lie unless you want to start instrumenting everything that you're doing to trap the calls and then run cost extrapolation from there. That's hard to do.Observability is a very different story, where latencies start to matter, where being able to get leading indicators of certain events—be a technical or business—start to be very important. But it seems like it's so hard to wind up getting there from where most people are. Because I know we like to talk dismissively about the past, but let's face it, conference-ware is the stuff we're the proudest of. The reality is the burning dumpster of regret in our data centers that still also drives giant piles of revenue, so you can't turn it off, nor would you want to, but you feel bad about it as a result. It just feels like it's such a big leap.Rachel: It is a big leap. And I think the very first step I would say is trying to get to this point of clarity and being honest with yourself about where you're at and where you want to be. And sometimes not making a choice is a choice, right, as well. So, sticking with the status quo is making a choice. And so, like, as we get into things like the holiday season right now, and I know there's going to be people that are on-call 24/7 during the holidays, potentially, to keep something that's just duct-taped together barely up and running, I'm making a choice; you're make a choice to do that. So, I think that's like the first step is the kind of… at least acknowledging where you're at, where you want to be, and if you're not going to make a change, just understanding the cost and being realistic about it.Corey: Yeah, being realistic, I think, is one of the hardest challenges because it's easy to wind up going for the aspirational story of, “In the future when everything's great.” Like, “Okay, cool. I appreciate the need to plant that flag on the hill somewhere. What's the next step? What can we get done by the end of this week that materially improves us from where we started the week?” And I think that with the aspirational conference-ware stories, it's hard to break that down into things that are actionable, that don't feel like they're going to be an interminable slog across your entire existing environment.Rachel: No, I get it. And for things like, you know, instrumenting and adding tracing and adding OTEL, a lot of the time, the return that you get on that investment is… it's not quite like, “I put a dollar in, I get a dollar out,” I mean, something like tracing, you can't get to 60% instrumentation and get 60% of the value. You need to be able to get to, like, 80, 90%, and then you'll get a huge amount of value. So, it's sort of like you're trudging up this hill, you're charging up this hill, and then finally you get to the plateau, and it's beautiful. But that hill is steep, and it's long, and it's not pretty. And I don't know what to say other than there's a plateau near the top. And those companies that do this well really get a ton of value out of it. And that's the dream, that we want to help customers get up that hill. But yeah, I'm not going to lie, the hill can be steep.Corey: One thing that I find interesting is there's almost a bimodal distribution in companies that I talk to. On the one side, you have companies like, I don't know, a Chronosphere is a good example of this. Presumably you have a cloud bill somewhere and the majority of your cloud spend will be on what amounts to a single application, probably in your case called, I don't know, Chronosphere. It shares the name of the company. The other side of that distribution is the large enterprise conglomerates where they're spending, I don't know, $400 million a year on cloud, but their largest workload is 3 million bucks, and it's just a very long tail of a whole bunch of different workloads, applications, teams, et cetera.So, what I'm curious about from the Chronosphere perspective—or the product you have, not the ‘you' in this metaphor, which gets confusing—is, it feels easier to instrument a Chronosphere-like company that has a primary workload that is the massive driver of most things and get that instrumented and start getting an observability story around that than it does to try and go to a giant company and, “Okay, 1500 teams need to all implement this thing that are all going in different directions.” How do you see it playing out among your customer base, if that bimodal distribution holds up in your world?Rachel: It does and it doesn't. So, first of all, for a lot of our customers, we often start with metrics. And starting with metrics means Prometheus. And Prometheus has hundreds of exporters. It is basically built into Kubernetes. So, if you're running Kubernetes, getting Prometheus metrics out, actually not a very big lift. So, we find that we start with Prometheus, we start with getting metrics in, and we can get a lot—I mean, customers—we have a lot of customers that use us just for metrics, and they get a massive amount of value.But then once they're ready, they can start instrumenting for OTEL and start getting traces in as well. And yeah, in large organizations, it does tend to be one team, one application, one service, one department that kind of goes at it and gets all that instrumented. But I've even seen very large organizations, when they get their act together and decide, like, “No, we're doing this,” they can get OTel instrumented fairly quickly. So, I guess it's, like, a lining up. It's more of a people issue than a technical issue a lot of the time.Like, getting everyone lined up and making sure that like, yes, we all agree. We're on board. We're going to do this. But it's usually, like, it's a start small, and it doesn't have to be all or nothing. We also just recently added the ability to ingest events, which is actually a really beautiful thing, and it's very, very straightforward.It basically just—we connect to your existing other DevOps tools, so whether it's, like, a Buildkite, or a GitHub, or, like, a LaunchDarkly, and then anytime something happens in one of those tools, that gets registered as an event in Chronosphere. And then we overlay those events over your alerts. So, when an alert fires, then first thing I do is I go look at the alert page, and it says, “Hey, someone did a deploy five minutes ago,” or, “There was a feature flag flipped three minutes ago,” I solved the problem right then. I don't think of this as—there's not an all or nothing nature to any of this stuff. Yes, tracing is a little bit of a—you know, like I said, it's one of those things where you have to make a lot of investment before you get a big reward, but that's not the case in all areas of observability.Corey: Yeah. I would agree. Do you find that there's a significant easy, early win when customers start adopting Chronosphere? Because one of the problems that I've found, especially with things that are holistic, and as you talk about tracing, well, you need to get to a certain point of coverage before you see value. But human psychology being what it is, you kind of want to be able to demonstrate, oh, see, the Meantime To Dopamine needs to come down, to borrow an old phrase. Do you find that some of there's some easy wins that start to help people to see the light? Because otherwise, it just feels like a whole bunch of work for no discernible benefit to them.Rachel: Yeah, at least for the Chronosphere customer base, one of the areas where we're seeing a lot of traction this year is in optimizing the costs, like, coming back to the cost story of their overall observability bill. So, we have this concept of the control plane in our product where all the data that we ingest hits the control plane. At that point, that customer can look at the data, analyze it, and decide this is useful, this is not useful. And actually, not just decide that, but we show them what's useful, what's not useful. What's being used, what's high cardinality, but—and high cost, but maybe no one's touched it.And then we can make decisions around aggregating it, dropping it, combining it, doing all sorts of fancy things, changing the—you know, downsampling it. We can do this, on the trace side, we can do it both head based and tail based. On the metrics side, it's as it hits the control plane and then streams out. And then they only pay for the data that we store. So typically, customers are—they come on board and immediately reduce their observability dataset by 60%. Like, that's just straight up, that's the average.And we've seen some customers get really aggressive, get up to, like, in the 90s, where they realize we're only using 10% of this data. Let's get rid of the rest of it. We're not going to pay for it. So, paying a lot less helps in a lot of ways. It also helps companies get more coverage of their observability. It also helps customers get more coverage of their overall stack. So, I was talking recently with an autonomous vehicle driving company that recently came to us from the Dog, and they had made some really tough choices and were no longer monitoring their pre-prod environments at all because they just couldn't afford to do it anymore. It's like, well, now they can, and we're still saving the money.Corey: I think that there's also the downstream effect of the money saving to that, for example, I don't fix observability bills directly. But, “Huh, why is your CloudWatch bill through the roof?” Or data egress charges in some cases? It's oh because your observability vendor is pounding the crap out of those endpoints and pulling all your log data across the internet, et cetera. And that tends to mean, oh, yeah, it's not just the first-order effect; it's the second and third and fourth-order effects this winds up having. It becomes almost a holistic challenge. I think that trying to put observability in its own bucket, on some level—when you're looking at it from a cost perspective—starts to be a, I guess, a structure that makes less and less sense in the fullness of time.Rachel: Yeah, I would agree with that. I think that just looking at the bill from your vendor is one very small piece of the overall cost you're incurring. I mean, all of the things you mentioned, the egress, the CloudWatch, the other services, it's impacting, what about the people?Corey: Yeah, it sure is great that your team works for free.Rachel: [laugh]. Exactly, right? I know, and it makes me think a little bit about that viral story about that particular company with a certain vendor that had a $65 million per year observability bill. And that impacted not just them, but, like, it showed up in both vendors' financial filings. Like, how did you get there? How did you get to that point? And I think this all comes back to the value in the ROI equation. Yes, we can all sit in our armchairs and be like, “Well, that was dumb,” but I know there are very smart people out there that just got into a bad situation by kicking the can down the road on not thinking about the strategy.Corey: Absolutely. I really want to thank you for taking the time to speak with me about, I guess, the bigger picture questions rather than the nuts and bolts of a product. I like understanding the overall view that drives a lot of these things. I don't feel I get to have enough of those conversations some weeks, so thank you for humoring me. If people want to learn more, where's the best place for them to go?Rachel: So, they should definitely check out the Chronosphere website. Brand new beautiful spankin' new website: chronosphere.io. And you can also find me on LinkedIn. I'm not really on the Twitters so much anymore, but I'd love to chat with you on LinkedIn and hear what you have to say.Corey: And we will, of course, put links to all of that in the [show notes 00:28:26]. Thank you so much for taking the time to speak with me. It's appreciated.Rachel: Thank you, Corey. Always fun.Corey: Rachel Dines, Head of Product and Solutions Marketing at Chronosphere. This has been a featured guest episode brought to us by our friends at Chronosphere, and I'm Corey Quinn. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry and insulting comment that I will one day read once I finished building my highly available rsyslog system to consume it with.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.

Ransomware group reports a victim company to the SEC for failing to promptly disclose a breach. Shadowy hack-for-hire group behind sprawling web of global cyberattacks Electrical arc detection devices that can prevent dangerous home fires caused by faulty wiring. The worst passwords of 2023 The NIS2 Directive: The first piece of EU-wide legislation on cybersecurity Jenna Bilotta of LaunchDarkly joins to discuss transforming DevOps tools with better user experiences. Hosts: Louis Maresca, Brian Chee, and Curtis Franklin Guest: Jenna Bilotta Download or subscribe to this show at https://twit.tv/shows/this-week-in-enterprise-tech. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit

Ransomware group reports a victim company to the SEC for failing to promptly disclose a breach. Shadowy hack-for-hire group behind sprawling web of global cyberattacks Electrical arc detection devices that can prevent dangerous home fires caused by faulty wiring. The worst passwords of 2023 The NIS2 Directive: The first piece of EU-wide legislation on cybersecurity Jenna Bilotta of LaunchDarkly joins to discuss transforming DevOps tools with better user experiences. Hosts: Louis Maresca, Brian Chee, and Curtis Franklin Guest: Jenna Bilotta Download or subscribe to this show at https://twit.tv/shows/this-week-in-enterprise-tech. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit

Ransomware group reports a victim company to the SEC for failing to promptly disclose a breach. Shadowy hack-for-hire group behind sprawling web of global cyberattacks Electrical arc detection devices that can prevent dangerous home fires caused by faulty wiring. The worst passwords of 2023 The NIS2 Directive: The first piece of EU-wide legislation on cybersecurity Jenna Bilotta of LaunchDarkly joins to discuss transforming DevOps tools with better user experiences. Hosts: Louis Maresca, Brian Chee, and Curtis Franklin Guest: Jenna Bilotta Download or subscribe to this show at https://twit.tv/shows/this-week-in-enterprise-tech. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit

Ransomware group reports a victim company to the SEC for failing to promptly disclose a breach. Shadowy hack-for-hire group behind sprawling web of global cyberattacks Electrical arc detection devices that can prevent dangerous home fires caused by faulty wiring. The worst passwords of 2023 The NIS2 Directive: The first piece of EU-wide legislation on cybersecurity Jenna Bilotta of LaunchDarkly joins to discuss transforming DevOps tools with better user experiences. Hosts: Louis Maresca, Brian Chee, and Curtis Franklin Guest: Jenna Bilotta Download or subscribe to this show at https://twit.tv/shows/this-week-in-enterprise-tech. Get episodes ad-free with Club TWiT at https://twit.tv/clubtwit

Episode 506: Shaan Puri (https://twitter.com/ShaanVP) is coming at you with 10 AI-specific business ideas that he would invest in tomorrow if they existed.  Want to see more MFM? Subscribe to our YouTube channel here. Want MFM Merch? Check out our store here. Want to see the best clips from MFM? Subscribe to our clips channel here. — Check Out Sam's Stuff: • Hampton - https://www.joinhampton.com/ • Ideation Bootcamp - https://www.ideationbootcamp.co/ • Copy That - https://copythat.com/ Check Out Shaan's Stuff: • Try Shepherd Out - https://www.supportshepherd.com/ • Shaan's Personal Assistant System - http://shaanpuri.com/remoteassistant • Power Writing Course - https://maven.com/generalist/writing • Small Boy Newsletter - https://smallboy.co/ • Daily Newsletter - https://www.shaanpuri.com/ — Show Notes: (0:00) Intro (5:00) 10 - AI Sales Agent (10:00) 9 - Therapy for everyone, everywhere (13:00) 8 - Robots that automate warehousing  (15:00) 7 - McKinsey for AI (19:00) 6 - Licensable deepfakes (22:00) 5 - Celebrity deepfake monitoring  (24:00) 4 - AI Tutor (26:00) 3 - Call center accent customization (28:00) 2 - AI Porn  (31:00) 1 - Self-doing to-do list — Links: • Episode 94 - Is GPT-3 the Next Big Thing - https://tinyurl.com/37wfyphx • Sameday - https://www.gosameday.com/ • Hims - https://www.hims.com/ • Amazon Robotics - https://tinyurl.com/5fu22r8x • LaunchDarkly - https://launchdarkly.com/ • Invideo AI - https://invideo.io/ • OpenAI - https://openai.com/ Past guests on My First Million include Rob Dyrdek, Hasan Minhaj, Balaji Srinivasan, Jake Paul, Dr. Andrew Huberman, Gary Vee, Lance Armstrong, Sophia Amoruso, Ariel Helwani, Ramit Sethi, Stanley Druckenmiller, Peter Diamandis, Dharmesh Shah, Brian Halligan, Marc Lore, Jason Calacanis, Andrew Wilkinson, Julian Shapiro, Kat Cole, Codie Sanchez, Nader Al-Naji, Steph Smith, Trung Phan, Nick Huber, Anthony Pompliano, Ben Askren, Ramon Van Meer, Brianne Kimmel, Andrew Gazdecki, Scott Belsky, Moiz Ali, Dan Held, Elaine Zelby, Michael Saylor, Ryan Begelman, Jack Butcher, Reed Duchscher, Tai Lopez, Harley Finkelstein, Alexa von Tobel, Noah Kagan, Nick Bare, Greg Isenberg, James Altucher, Randy Hetrick and more. — Other episodes you might enjoy: • #224 Rob Dyrdek - How Tracking Every Second of His Life Took Rob Drydek from 0 to $405M in Exits • #209 Gary Vaynerchuk - Why NFTS Are the Future • #178 Balaji Srinivasan - Balaji on How to Fix the Media, Cloud Cities & Crypto • #169 - How One Man Started 5, Billion Dollar Companies, Dan Gilbert's Empire, & Talking With Warren Buffett • ​​​​#218 - Why You Should Take a Think Week Like Bill Gates • Dave Portnoy vs The World, Extreme Body Monitoring, The Future of Apparel Retail, "How Much is Anthony Pompliano Worth?", and More • How Mr Beast Got 100M Views in Less Than 4 Days, The $25M Chrome Extension, and More

David York, a founder and managing director of Top Tier Capital Partners, provides invaluable insights into the intricacies of fund of funds (FOF). Delving into the dynamic nature of FOFs within the venture capital ecosystem, he sheds light on three distinct methods of investing in venture capital. Furthermore, David offers a comprehensive overview of his meticulous evaluation process for VC firms, highlighting the formidable challenges that investors encounter when selecting the most promising ventures.In this episode, you'll learn:[6:47] 3 ways of how to become ‘the money behind the money'.[11:05] Why is it difficult to evaluate VC firms?[20:35] What goes into starting a VC firm? What are the benefits of using FOFs in your VC journey?[26:00] Missing opportunities, how to handle NOs as a VC, and the importance of relationships in venture capital.[28:44] Future of venture capital: will venture capital become a more attractive asset class?The non-profit organization that David is passionate about: NESsTAbout David YorkDavid York is a founder & Managing director at Top Tier Capital Partners. He leads the Corporate Development team and is responsible for the management, development & growth of the firm's offerings, and is a member of the Investment and Management Committees at the firm. David has 30+ years of industry knowledge and networks, which uniquely equip him to be a liaison and international ambassador not only for Top Tier's brand, but also the broader venture community. Previously, he led the fund of funds business at Paul Capital Partners, before spinning it out and founding Top Tier. Prior to Paul Capital, he spent seventeen years on Wall Street running various trading desks.David is also a board member in various for-profit and nonprofit organizations. He's on the Board of Directors of NESsT, a 23-year-old Social Development Enterprise and Impact Investing non-profit investment firm focused on the development of social entrepreneurs in Central European and Latin American countries.About Top Tier Capital PartnersTop Tier Capital Partners is a venture capital specialist managing niche-focused funds of funds, secondaries, and co-investment strategies. The firm makes primary and secondary investments in venture capital funds and co-invests in select portfolio companies.Top Tier's history is marked with investments in renowned VC firms such as Kleiner Perkins, Andreessen Horowitz, Atlas Ventures, Abingworth, Initialized, Accel, and A.Capital Ventures, and its current portfolio companies include Paro, Prime Roots, Plus One Robotics, Komprise, Career Karma, Talkdesk, LaunchDarkly, among many others.Subscribe to our podcast and stay tuned for our next episode. Follow Us:  Twitter | Linkedin | Instagram | Facebook

Edith Harbaugh, Co founder and Executive Chair at LaunchDarkly, joins the show to talk aboutThe process LaunchDarkly went through to validate PM fit and create the category for feature management.LaunchDarkly's target customer profile when finding PM fit and how their target customer profile has evolved as their category and company has scaled.At what stage in a company's growth should a founder invest in Dev Ops.The evolution of DevOps landscape over the next 3-5 years.

In this edition of Fragmented, we're thrilled to host Ishan Khanna, a software engineer at Tinder who possesses great enthusiasm for feature flags and A/B testing. Donn discusses why he invited Ishan on the show, highlighting Ishan's passion for feature flagging and A/B testing. The conversation kicks off with an insightful story from Ishan about feature flagging at Booking.com, leading to a discussion on the difference between A/B Testing and Feature Flags, when and why to introduce feature flagging, and how to measure its effectiveness. The show also focuses on the benefits and risks of feature flagging, along with ways to manage potential complexities in the codebase.We then delve deeper into the topic of feature flagging, covering how to get started, what to look for in a tool, and the role of testing. Discussion points include the best practices for rollout percentages, considerations for multi-platform implementation, and the specifics of targeting in feature flagging. The conversation wraps up with an exploration of available tools for those looking to introduce feature flagging or A/B testing frameworks into their operations, examining when it might be necessary to build a bespoke solution.The episode offers a wealth of resources for listeners, including links to an array of feature flagging and A/B testing tools, such as Firebase Remote Config, Optimizely, and LaunchDarkly. For more insight into the topics discussed, Ishan recommends his Droidcon Berlin talk on 'Customer Driven Development' and Stuart Frisby's talk on A/B Testing. To reach out to Ishan, listeners can contact him via Twitter, LinkedIn, or his website.LinksHere are the links mentioned in the document, in markdown format:Firebase Remote ConfigOptimizelyLaunchDarklyAWS AppConfig for Feature FlagsVWOUnleash - Open Source Feature FlagsPosthog Feature Flags and A/B TestingIshan's Droidcon Berlin TalkStuart Frisby's Talk on A/B TestingErindoesthingsContact IshanIshan on Twitter - @droidchefIshan on LinkedInIshan's WebsiteDonn's Git CourseNeed to learn Git? Donn has the course for you. In this FREE course you'll learn everything you need to know in order to start working with Git everyday. Watch it here.AndroidJobs.IOJob postings are FREE on AndroidJobs.IO

Learn directly from Edith Harbaugh, Co-founder and Executive Chair of LaunchDarkly, about the top 10 mistakes to avoid when scaling your SaaS company. Edith is an experienced startup executive and has firsthand insights into how to grow any SaaS business quickly and successfully. Don't miss this opportunity to get valuable guidance for scaling to 100 million in ARR! We'll cover how: *Everything is up & to the right if you zoom out Big changes every 6-18 months Revenue is it's own funding Hiring changes over time Value your time and get leverage A good Exec Recruiter is worth it Pricing - no right answer Creating category takes constant effort Refresh Values No playbook, just play pages   Watch the video, including Q&A: https://youtu.be/5ccWUwinkJg   ****** Shipping projects doesn't have to be a mess. Notion combines project management with your docs, knowledge base, and AI. So you can stop jumping between tools, and stop paying too much for them too. Get Notion Projects for free at Notion.com/SAASTR.   Vention provides technology leaders with the top engineering talent they need to accelerate their roadmap, innovate faster and more efficiently, and ultimately catapult their operation to new heights. Vention developers sync with clients' in-house teams, helping them get to market 30 percent faster and saving them more than $600,000 on average. Looking for the edge to outpace your competition? Vention is your partner. Learn more at ventionteams.com.   *****   Want to join the SaaStr community? We're the

This week, Beth and Dianne dive into the complex world of tech with Federal CTO Sara Mazer. They discuss her new company, LaunchDarkly, the first scalable feature management platform. They discuss the company, Dev Opps, Cyber Security and much more!Join the C-Sweet Community! CSweet.org

This podcast interview focuses on product innovation that helps product & growth teams build product-led experiences, experiment, and validate results, fast. And my guest is Jonathan Anderson, Co-founder and CEO of Candu. Jonathan Anderson is a tech entrepreneur on a mission. He loves tech but can't write a line of code. He's passionate about product-led selling and has launched services, strategy, operations, and analytics teams at venture-backed SaaS startups, including InsightSquared and LaunchDarkly.  Prior to startups, Jonathan worked at Bain & Company and he has a B.S. and M.S.Eng from Stanford University.  In September 2018, he co-founded Candu - a no-code tool that allows teams to collaboratively build the UI components needed to encourage the adoption of features, onboard users, and announce product news on a day-to-day basis. It's not just for the pure-play product-led companies, like Atlassian, Notion, and Loom — it's for the 'strivers' who are trying to figure out how to adjust their go-to-market motion for this new world order.  And this inspired me, and hence I invited Jonathan to my podcast. We explore what's holding a lot of software vendors back from shipping products to market and achieving high adoption rates. Jonathan shares his vision of how he aims to change that for good. He elaborates on the challenges he had to overcome to build traction and what that took from a product investment perspective in terms of first principles, focus, and grid. Lastly, he shares a do and a don't for B2B SaaS CEOs based on his most powerful own learnings. Here's one of his quotes We're changing the way that a business thinks about building its product. A single person, a single growth PM, can actually define an experiment in their head, grab a template, customize it, inject it into an application, preview it, and QA it themselves. So it really collapses what is basically a growth team into a single person. That makes it radically less expensive and also much, much, much faster. During this interview, you will learn four things: His approach to convincing a user/ buyer Candu is exactly what they need  How to approach getting users to start using your product and become addicted Their approach to turn their user base into their best sales force What Candu did differently by giving their ideal customers a 'name' that makes them instantly recognize if it's for them or not  For more information about the guest from this week: Jonathan Anderson Website Candu Subscribe to the Daily SaaS Reflection Get my free, 1 min daily reflection on shaping a B2B SaaS business no one can ignore. Subscribe here Yes, it's actually daily. And yes, people actually stay subscribed (Just see what peer B2B SaaS CEOs say) My promise: It's short. To the point. Inspiring. And valuable. Learn more about your ad choices. Visit megaphone.fm/adchoices

The tools B2B marketers rely on may be ever-evolving — whether that's the channels they use, the data they collect or the technology they rely on — but the key to success in B2B is actually one overlooked element: Emotion.In this episode of Best Story Wins, we speak with master storyteller Keith Messick, CMO at LaunchDarkly, about how he combines his knack for storytelling with all the tools, tactics, and strategies in modern marketing to tailor the perfect message for his ICP. We discuss:What B2B marketers can learn from B2CWhen to use emotion and logic in your B2B marketingHow to stand out in your market

Brian Rinaldi, Developer Experience Engineer at LaunchDarkly and long time friend of the show, recently wrote a blog post that was picked up in the TL;DR newsletter. His post, titled The State of Developer Conferences, shares a theory as to why both online and IRL (In Real Life) conferences are struggling to reach pre-pandemic attendance. Brian, who's been running conferences for 15-years, has a keen understanding of who attends events; and, why the demographics of attendees might be shifting. Conference organizers around the world are reading Brian's post and are nodding in strong agreement.Follow the show and be sure to join the discussion on Discord! Our website is workingcode.dev and we're @WorkingCodePod on Twitter and Instagram. New episodes drop weekly on Wednesday.And, if you're feeling the love, support us on Patreon.With audio editing and engineering by ZCross Media.

LaunchDarkly is a pioneer in the feature management space. Founded in 2014, while the agile and cloud movements were still relatively nascent, LaunchDarkly was ahead of its time. They have now scaled to a $3 billion company, serving over 4,000 customers. In this episode, LaunchDarkly Co-Founder and CEO Edith Harbaugh takes us back to her initial insight as an engineering manager and product leader at TripIt, deeply versed in the value of systematic feature flagging, and keenly aware of how underutilized it was by many other dev teams. She shares the conviction required to build a product that most buyers in Silicon Valley weren't yet looking for, and how she engaged her network to gain initial design partners for the product that would come to define the feature management space. Join us as we discuss: Honing a founder insight and being early vs late to an emerging sector Hypothesis testing and building with design partners Community-building and marketing a movement Fundraising when VCs are skeptical of a new sector About Unusual Ventures — Unusual Ventures is a seed-stage venture capital firm designed from the ground up to give a distinct advantage to founders building infrastructure software and application-level companies. Unusual was founded in 2018 with the mission to reinvent the venture capital engagement model by serving entrepreneurs with an unprecedented level of hands-on services. Described as a partner versus a top-down stakeholder by its portfolio companies, Unusual is laser-focused on serving exceptional founders and teams building innovative products. With offices in Menlo Park, San Francisco, and Boston, Unusual has invested in category-defining companies like Arctic Wolf Networks, Carta, Robinhood, Harness, and Vivun. About Sandhya Hegde — Sandhya is a General Partner at Unusual Ventures, leading investments in enterprise SaaS companies. Previously an early employee and executive at Amplitude, Sandhya is a product-led growth (PLG) coach and mentor. She can be reached at sandhya@unusual.vc and on Twitter (https://twitter.com/sandhya) and LinkedIn (https://www.linkedin.com/in/sandhyahegde/). Further reading: Identifying initial customers — https://www.field-guide.unusual.vc/field-guide-enterprise/ideal-customer-profile-and-personas Early-stage pricing — https://www.field-guide.unusual.vc/field-guide-enterprise/pricing-your-product TOOL: Founder prioritization heatmap — https://www.field-guide.unusual.vc/field-guide-enterprise/ceo-founder-prioritization Building a self-serve motion  — https://www.field-guide.unusual.vc/field-guide-enterprise/self-serve-user-buyer-journey

Better meetings are not a myth, but it starts with deconstructing how you got to where you are today. A hectic calendar and meetings showing up like popcorn.What can you do to improve this? Managers and individual contributors can start by focusing on what the goal of the meeting is. If the goal of the meeting is to solve a problem, that's a yellow flag.

Competency is not the only way you can grow your career.If that was the case, then every engineering manager would be technically more proficient than their reports, and I can guarantee (from many experiences) this is not only not the case - it's not even the norm.

Sometimes a small question can change the course of your career. It doesn't have to be complicated, and it doesn't have to be detailed. A well placed question might unearth information you didn't realize was in you.

Notifications North Star, sponsored by Courier!Guest: Vatasha White is a Senior Software Engineer at Courier. Previously, she built software at Lacework, LaunchDarkly and GE Digital. She is a graduate of Smith College in 2015.Questions:Having been a prior customer of Courier, what excited you about the solution?What is your favorite use case for the tool?So now that you work at Courier... what impact do they have that really motivates you?What are you working on now, that really excites you about the product?Linkshttps://www.courier.com/Support this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy

When you find something that is counterintuitive, it's possible that it will create immense value to whatever problem you are trying to solve. Seek to interrogate your beliefs to build better explanations for what is true, and find those who disagree with you at an intuitive level.

Productivity is about working towards your goals, and optimization is about sharpening those efforts more directly.We talk about two forks in the road when you choose the types of optimization you'll deploy in your career and personal life.

If you feel like everything is spinning around you and it's difficult to remain productive, you aren't alone. In this episode we talk about core tools and activities, and why it's so important to spend the majority of your time working in your core.