Continuous Quality for AI Coding: Checksum

Checksum brings continuous quality to the AI coding era by automatically generating, running, and maintaining tests against real APIs, real data, and real-world edge cases before code ever reaches production. Powered by its Code World Model and intelligent testing agents, Checksum helps engineering teams ship 10x faster with scalable, always-on testing that learns from every commit and production bug.

In this episode, we speak with Gal Vered, Co-Founder and CEO of Checksum. We discuss the evolving role of AI in software development, particularly focusing on AI-generated code and its verification. We highlight the rapid advancements in AI’s ability to write code and the emerging challenges in ensuring that AI-generated code is reliable in real-world environments. Gal explains how their company addresses these challenges by providing a continuous quality layer that uses AI to generate and maintain end-to-end tests. This helps bridge the gap between code that appears correct and code that functions correctly in practice.

The conversation delves into the complexities of software engineering, emphasizing the importance of verification as AI tools become more prevalent. Gal discusses the concept of “continuous quality” and how Checksum autonomously generates tests to ensure code reliability. We also explore the balance between automation and human judgment, noting that while AI can handle repetitive tasks, critical thinking and decision-making remain essential human roles. The discussion touches on the future of AI in software engineering, predicting that verification will become a significant part of the process. Gal envisions a future where AI-powered testing tools are integrated into coding platforms, enhancing the overall development workflow.

Follow SourceForge:

SourceForge.net - https://sourceforge.net
SourceForge LinkedIn
SourceForge X (Twitter)
SourceForge Facebook

Interested in appearing on the SourceForge Podcast? Contact us here.

The SourceForge Podcast is the world's largest B2B software podcast.

Transcript

SPEAKER_01 0:05

Hello everyone and welcome to the SourceForge podcast. I'm your host, Bo Hamilton. Now, over the last couple of years, the conversation around AI and software has moved extremely fast. At first, the headline was that AI could help developers write code faster. Then it became that AI could write entire chunks of code on its own. And now we're actually seeing AI tools write the majority share of new code inside organizations. And the conversation is starting to shift yet again, this time from what AI code can generate to what AI code can be trusted. Because writing code is one thing, but knowing whether that code actually works in the real world is something else entirely. And that's where things get a little bit complicated. Software doesn't live in a vacuum, it runs inside browsers, APIs, user interfaces, authentication flows, third-party services. I mean, the list goes on and on, all kinds of unpredictable real world conditions. A piece of AI-genated code can look perfectly fine in isolation. It can pass a series of checklists and checks and still fail once it runs inside the actual environment it was written for. So the bottleneck really starts to move. It's no longer just about producing code quickly in some, it's about verifying behavior with enough confidence that teams can actually ship what these systems generate. And that's a useful setup for today's conversation with Gal Verid, co-founder and CEO of Checksum. Checksum's broader thesis is that software engineering is heading toward a world where generation is increasingly automated, but verification is still the hard part. The company describes itself as building a continuous quality layer for that next phase using AI to actually generate and maintain end-to-end tests that help close the gap between code that looks right and code that proves itself in practice. So, to talk more about the world of AI-generated code, let me bring in Gal Verid. Gal, welcome to the podcast. Glad you could join us.

SPEAKER_00 1:54

Yeah, and thank you for hosting. And hello, everyone who's listening. And I'm excited.

SPEAKER_01 1:59

Awesome. Yeah. Well, glad to have you here. And I want to get right into it. So I know Checksum is really concerned with what happens after AI code gets written and whether teams can actually trust it in production. For listeners hearing about Checksum for the first time, can you just help us unpack that further and describe what it is you guys offer?

SPEAKER_00 2:17

Yeah, sure. So I think in a sentence, we help you go from poem to production. What it means in reality is that you said it exactly right at the beginning. AI helps you write code significantly faster. If I'm going to take cloud code or cursor, point it to the entire of checksum backlog, at the end of the day, I will have 100 PRs ready. But do they work? Like what do I do with them? How do I ship them? Do I understand what HPR is actually doing? That is the real bottleneck. The reality is, and we see it with our engineers, with our customers, engineers, 90% of the time just goes over reviewing PRs, getting finding the edge cases in production, firefighting. Engineers used to ship one or two features every month. Now they're shipping 10 features every week. That's a lot of balls in the air, and you just need to constantly context switch. So I always I jokingly say that AI made engineers 10x more efficient, but also 10x more busy. And so with that, we're saying, okay, like our goal at Checksam is to help you fully test every PR, every change you'll make, fully test your app through millions of test cases, hundreds of test cases, depending on the on the on the type of tests, based on real sessions. So you can actually ship code in confidence. So if you get 100 PRs from cloud code, you also know those 100 PRs are working. You can ship them confidence to product confidence to production, and you can just move faster. So we help you realize the gains of AI. If AI makes code 10x faster to write, we want to help you ship 10x faster. So move all of those efficiencies into actually shipping.

SPEAKER_01 3:54

Got it. Okay, that's a really good overview. And I think really the the core, it sounds like um, the core idea is just instilling this higher sense of confidence in the code that you're generating. Again, like producing code more quickly is one thing, but it's it's about knowing whether you actually ship something that is working effectively. That's really the real value. Um so on that note, um, if I'm coming uh at this from the engineering side or the QA side, and I'm hearing about checksum for the first time, how would you alter that description to me to help explain it to me?

SPEAKER_00 4:29

At the end of the day, engineers already know that they ship features significantly faster. The app is keep changing. And now they have a choice and they they're facing this choice. I don't even need to explain to them. They can either slow down and make sure their app is entirely covered, write tests, write end-to-end tests, test their app manually, deploy carefully, monitor everything, um, or they can move fast and firefight and let quality slip. So, what Checksam does is something very, very simple. We continuously and autonomously generate a set of testing suites, end-to-end test, API test, integration tests, based on real usage. So those are actually testing your app the same way your users are using them in order to make sure everything is working 100% of the time. So the engineer can be the hero that not only able to write 10 or 15 features, but actually get those features to production nicely with zero bugs and sheep fast. So that's kind of like the empowerment we want to give to our customers. And we think it's a vast comprehensive testing suite in every layer is the way to do that.

SPEAKER_01 5:37

Now, I know a lot of uh teams are aware of this issue, this trust trust issue, but what they they do to bolster that trust, I think varies quite considerably from maybe user to user or organization to organization. They know that they should have this end-to-end coverage. Um, and I think many of them build it themselves. Uh for the engineering teams out there that do go down this route, this DIY route, where do those approaches start to break down and run into issues?

SPEAKER_00 6:07

Yeah, it breaks down, it breaks down in two main points. The first point that it breaks down with is simply coverage. Like again, you're shipping features on a daily basis, new PRs, or changing existing features and how they work. The reality today is that you're on a customer call on Monday, they give you feedback. One hour later, you already have a PR to fix this feedback, right? All you need to do is paste some description into cloud code, it writes it. But your app is changing so much, it's very hard to get coverage. Unless you're willing to slow down. Again, you can always slow down and say, hey, you don't merge this PR until you updated all of the tests and you have a full testing suite. Now, even if you slow down and you're able to keep up, maintenance becomes the problem. Let's say, again, today small teams are able to ship significantly complex apps, and definitely it's true for enterprise. Let's say you have 500 N20 tests in your testing suite, 1000 N20 tests in your testing suite. Every week, 100, 200, 300 of those tests are going to break because you're shipping so fast. And when they break, essentially someone needs to stop their walk and firefight. Because when they break, the pipeline either your pipeline is broken and you can't ship, or you need to ship blind because 30% of your app, you don't know if it's working or not. So when they break, someone needs to firefight. Um and with checksam, it's always on. When they break, we do the triage, we reduce the noise, we reduce the false positives. So you can just move faster. Again, it's it's all about moving fast.

SPEAKER_01 7:38

It's all about moving fast and making sure you have um all your kind of ducks in a row. Um, you have everything set up. Because I know it's almost like a trap I feel like teams might fall into where they they know they need to have this end-to-end coverage, they they invest in it, but over time it, like you were saying, it turns into this sort of maintenance project. Um and then you know the value starts slipping because things start breaking and running, you start running into problems. Um now the I think that leads me to my next question, which obviously that this this problem has started to really appear with with the rise of these AI um uh generation tools and the the speed of which people operate and everyone happening to move faster and faster. Um uh and so there's there's a lot more competition out there. The market has changed quite a bit. I'm curious what makes checksum different from other automated testing tools out there, and then where does it fit into a team's existing workflow?

SPEAKER_00 8:33

Yeah, I think there are three main things. One, we call it continuous quality. Typical testing tools, or even cloud code and cursor, are passive. Someone needs to go, open a web interface, open cloud code, open cursor, type something in there, add the test, fix the test. Checksam is proactive. You still have full control. So you can still generate tests you want, you can delete, you can remove. But at the end of the day, Checksam continuously and autonomously wakes up in a workflow and add new tests to cover the new features. Update existing tests based on the changes you made. When you run your testing suite and the test fails, we automatically triage using AI the failure. Essentially, one of the big problems with test suites in general is the noise, right? It's like every time something fails. So we automatically triage it within minutes, and you always get zero noise report. If the test needs to be healed, we heal it automatically. You don't need to do anything about it. And if if there's a bug, we ought to we report the bug, we create a very nice report that's very clear, so we can just move forward. So I think quality is a lot about discipline, and we keep a very high bar of discipline automatically, and then on top of it, you have full control to you know shape your quality and fully own your quality. So that's the first thing. The second thing is we deliver tests as code. So at the end of the day, a lot of the platforms are kind of black boxes, the tests are on their side, you don't know really how it works. It's some magical AI thing with some proprietary algorithms. We provide tests as playwright, you fully own the tests, nothing is proprietary to check some in the tests themselves. Um and it's also very nice because you can use coding agents with those tests to run those tests, and they, you know, the playwright is we provide test as playwright, for example, for end-to-end tests or pie test with uh API testing, etc. It's in the LLM training data. So you don't need to explain it what it is, how it works. Like it's it just already knows the language because it's no, it knows the coding. And the third one is accuracy. Like we have benchmarks. Uh 75% of the tests that are failing are fully healed with checks and within the first few minutes. We then have a deeper workflow uh infused by four deployed engineers on our side that can get the healing to 100%. So we can deliver results, and that's the most important thing. And if we need to, we have four deployed engineers that are able to tune the models, make sure it works for very complex use cases for enterprises. So we deliver results and solve your problem versus a passive tool that you need to use every day and spend hours, and then it's all in the platform, so you can't really use the things you build if you decide to do something else.

SPEAKER_01 11:14

Yeah, well, one thing I want to note too is what is automated and then what still needs a person in the loop with a lot of these automated um, you know, features and tools you offer? I know checksum, obviously, you guys talk a lot about the autonomous generation and the the abilities to execute on these capabilities, but um you guys also make a point to you know bring in the QA teams and still offer lots of relevance and and and uh meaning for for these these individuals. Um how much of the testing lifecycle can Shecksum automate today? And then where does the the human element, the human judgment part still still play a role?

SPEAKER_00 11:54

That's a perfect question because I think that and that's true generally to work with LLMs. LLMs can make you move faster and they can you know save you a lot of time and do all of the grant work, but the thinking and the taste and the decisions, that's that's a a human's job. Um so look, your automation engineers or engineers in general, they know their app the best. They know their customers, they know all of the edge cases. They have like years of deploying this software to production, they know all of the quirks. So they're able to decide what's more important, what's the best ROI, and how best, like how what's the best way to test the app that gives you 100% confidence. Jackson can still do those things autonomously and provide good results, and especially as our agent learns from your decisions, because our agent is also continuously learning, it's able to get the decisions closer to you. But at the end of the day, you own quality. And if there's a certain way that you feel like a feature needs to be tested, you have full control on that. In addition, what we've learned is that each engineering team has a different tolerance for bugs, right? If you serve an app to developers, maybe CSS bugs are not such a big deal. And if two divs aren't fully aligned, not a big deal. And you're very in the MVP stage, so some bugs are acceptable. The most important thing is to ship it. While if you're an enterprise company that sells a product to a non-technical person, everything needs to be perfect. So everything is considered a bug. That level of tolerance and organization knowledge, and which is crucial to understand how do you make the organization faster and how do you ship faster, is still owned by the engineers. And because our model at the end of the day needs to learn from their decisions.

SPEAKER_01 13:39

Okay, so so in sum, it's it's humans obviously aren't being uh you know removed entirely. They're just sort of being being moved away from a lot of the repetitive like maintenance work and into areas where there's more judgment and uh you know context and where priorities really matter, I would say. Um, do you feel like there's uh maybe a learning curve like when you pivot away to this more kind of uh judgment-based um working approach as opposed to like the technical hands-on um experience and like with coding? Um, or is it a pretty natural sort of pivot?

SPEAKER_00 14:12

Yeah, I did this is a fantastic question because it's it's a full topic of how do you use AI. I think it's natural in the sense that we provide test as code and we don't force you to change any of your workflows, and Checksum is just another team member who deploys and auto or constantly cares about testing and uploads it. And you know, everyone would love to have this team member that just writes your tests automatically and always maintain them, and you know they got it covered. Um, so it's natural in this case. It's not natural, but that's not specifically to Checksam, in the way that the role of software engineering and Q automation engineers in general change, right? So today, when you write a feature, it it used to be 90% of the, and it's always easy to expand with writing code because people have experience there. It used to be that 90% of the role of a software engineer would be to write code. Today, you know, we I think, if not 100%, probably 90% of the code is written by an LLM. An engineering job becomes more in defining what's more crucial, defining the architecture, you know, reviewing the code, making sure we don't accumulate too much tech debt. So the role is changing. And the role of people in general is changing when working with AI, because you have this huge force multiplier. So it's very for people who understand that and already made this change and who are AI adopters, I think it's a very natural way to use checksum. And I think for people who still feel like, you know, they want to do the work, it's not a natural change. But I think every month we see less of less of those people because again, regardless of checksum, the world is moving there, and regardless of checksum, people are making this transition. So it's not unique to checksum, is what I'm trying to say.

SPEAKER_01 15:51

No, that's that's interesting to think about. And I just think of to the um, you know, when you rely on a lot of these AI tools um and uh uh to generate the code for you, let's say, um, it makes me think of the kind of critical thinking skills that are uh, you know, really super important. And um, you know, speaking of headlines like in the introduction, it's like a lot of the headlines are talking about and the findings from relying a lot on AI tools and chatbots is like a lot of the thinking, critical thinking skills kind of goes uh is starting to be depleted. Um, teams and individuals aren't able to, you know, maybe uh kind of use a lot of their own judgment because they're outsourcing it to AI. So I'm curious, like it just makes me think of with these this pivot. Do you worry that um there could be an issue with with the critical thinking um part of the equation that's required for this pivot for some of the QA and engineering teams that that are switching to a more judgment-focused role?

SPEAKER_00 16:47

In general, I would assume that as you outsource the thinking to an LLM, LLM is gonna be is regressing to the average, right? Regardless. Because because in a world where everyone uses LLMs, then everyone LLM becomes the average. Even if it's today very, very good, it will still be the average. So I think when you fully lean into LLMs, you're kind of guaranteeing average results. So in order to create great results, and the definition changes, right? Great results, like two years ago, great results was X, today great results is 10x, because with LLMs you can but if you want to achieve great results, if you want to break out from the mean, you must have very, very clear opinions, very, very clear directions. I think with uh testing and quality and engineering in general, the alpha comes from understanding the customer or the task and the and focusing on the impact. It's a balance, I would say.

SPEAKER_01 17:41

Now, Gal, I'm I'm curious about some of the real world examples you might have accumulated. Can you share an example where Checksum caught maybe a critical bug or regression that a team's existing tests completely missed?

SPEAKER_00 17:54

Yes. Um, and I think Checksum catches like hundreds, if not thousands of bugs every week for our customers. So that's, you know, people ship with AI. There's a lot of outages, um, there's a lot of problems, there's a lot of issues. Sometimes those are minor bugs, sometimes those are major bugs. I think the the coolest bugs we catch because we kind of use real real information is when the bug is related to data. So it's a specific customer or a specific data query you only have in production in real mass, and no one will catch it but checksum because you know we based our tests on that, suddenly is able to actually catch a bug that none of the engineers thought about, none of the QA managers thought about. But I think what's more important that I want to highlight here is that at the age of AI testing and quality in general, it's not just about catching bugs, it's also about knowing that there aren't any bugs in your application, and that's extremely important. Because if you go back to the analogy of I point cloud code to our backlog and I have 100 PRs ready. Again, in a world where humans wrote all of those PRs, my goal is just to find the bugs because I have high confidence that it works and ship it. In the world where AI wrote those PRs, knowing that there are zero bugs in any of those PRs allow me to ship it to production today versus needing to test every PR extremely thoroughly and probably be able to ship it only 10, 15, 20 days from now. So that's it's a different way to think about quality because knowing that they're again, knowing that this thing is shippable is the value. And it's not always about finding bugs, it's about very comprehensive tests and ability to communicate those tests so the customer can see them and say, yeah, I get it. I I trust it, let's ship it.

SPEAKER_01 19:39

Yeah, it makes me think of um Anthropics recently, you know, uh released preview of their mythos um agent that's going out and kind of causing a stir in the cybersecurity world with the ability to find all these bugs in zero days. Um but it if you think of it in the future where this sort of uh uh agent, this this model is built into the code generation tools themselves, I mean it's you're you're gonna be able to ship much more secure code in the first place, like you were saying. Right. Um now you've been pretty explicit that as AI makes writing code easier, the the bottleneck shifts to verification. Um, looking ahead, how do you see the relationship between AI code generation and AI powered testing evolve over the next few years, let's say, if we can think, you know, plan that far in the future, where do you think this is all headed?

SPEAKER_00 20:29

Yeah, I think 50% of uh engineering becomes verification. So if you think about an autonomous AI engineer, which I assume at the southern part of this is where the world is headed. Um you have an agent that writes code. And this agent is um extremely good. And for the most part, we're already there, right? Cloud code is it writes pretty decent code, even if you don't have any improvement, I think we're already there. But knowing that the code works and actually shipping the code is a completely different uh job. Um I don't think it's a it's a job for LLMs. LLMs are a very small context window, relatively even if the context window 10x, 100x, it's still very small when you talk about complex systems, complex production systems. Um, and being able to fully verify the code is uh probably requires a different approach, or maybe an approach that's infused uh with LLMs, which is what we're doing at Checksam. Um so we see verification as 50% of an autonomous AI engineering system that allows you to ship code to production autonomously.

SPEAKER_01 21:33

Now I can see you know some serious value for some of the uh established AI coding platforms um to integrate like your your tool set, your product directly. Is this like a partnership or or scenario you've you sort of envision um in the future? Or do you kind of uh set uh think of your company as like a separate offering?

SPEAKER_00 21:54

Yeah, no, I I can see it happening. To be honest, we see such a strong demand from the market that we're just going after. You know, the demand we're seeing. So we don't have any we we're partners with JCP, and this was very useful for us, but we don't have any partnerships specifically with coding agents for now. I think it's also an evolving space. And but that's definitely something we're kind of looking at.

SPEAKER_01 22:17

That makes sense. Yeah. It's it's yeah, I mean definitely an evolving space. And yeah, I just um just based off what you've you've shared with us, I could just see the value there. Um so I want to circle back uh around to one of the more interesting ideas in your your framework for all of this. Um, you talk about something called the context void. Um, and it's this gap between what a coding agent can see and what actually determines whether software works in production. Can you explain what that means some more? What is this context void? Um, and then why does closing that gap matter more than just writing better tests?

SPEAKER_00 22:50

Yeah, that's a fantastic question. So when you think about complex systems, think about a product like Twitter, right? I think that's a that's an example I like to use a lot. On the surface, it's a very, very simple product. You can probably vibe code it in one day. It's tweets and likes and users and comments. And that's basically it. Then you have a clone of Twitter. Again, I'm pretty sure that if I'll tell Cloud Code or Cursor to do it right now, in 30 minutes I'll get a clone of Twitter that actually works and I can deploy. But Twitter is complex, and the reason it's complex is that it's used by hundreds of millions of users every day, and it's deployed into production, and the deployment in production is extremely complex. An array of machines all working together to give you a response extremely quickly that is uniform across everyone, so everyone sees the right and updated data. That's a very complex system. The code might not be super complex, but the system itself is extremely complex. And going through all of the edge cases, third-party integration, services, and there's a lot of data there. And the value becomes comes from being able to infuse all of this data and all of this information in your coding and in your testing and verification. Um, this is not a job that LLMs are suited for. And we're not talking about, okay, just build an MCP that connects LLMs to production and being able to query the data. I'm not talking about that because in order to verify significant changes and in order to push code to production regularly, it's about running millions of scenarios like Checksum is doing, and not just reading your app and saying it works. It's actually running your app for millions of scenarios. And that's the context for it. It's basically LLMs are very similar to a senior engineer that joined your company today. Like it has no idea about your customers, no idea what's happening in production. You can give them access to those tools and it can start learning, but there's so many contexts that they need to learn into their into their knowledge base. And the way humans work, they just, you know, after six months, one year, suddenly the senior engineer becomes super effective because they have all of this knowledge. And Lens, I just don't think, you know, unless um are just not well suited for you. Unless you can actually ingrain this data into training, which will never happen because it's a very specific and sensitive data. So Checksum provides the other layer, basically, all of the information from production into the coding uh workflow.

SPEAKER_01 25:22

That's really interesting. Yeah, it it's good, that's great context, and it makes me it sort of gives you uh some reassurance for that existential sort of threat of AI can just kind of clone websites or um the threat it has for some um open source software, for example. Um there's so much more complexity behind the scenes of I just think of like working with APIs and databases and configurations and all these um other permissions and user behavior. And then not to mention the community aspect where I mean Twitter's a good example where if it gets when it got bought out, it's like there's a community there. And when you don't have the community um or they feel alienated, they leave. And then when you have a platform with no community, it just becomes kind of sad, the value is lost, right? So there's a lot of a lot of play more than just the surface level of cloning that uh some of these AI tools can can accomplish. But that that kind of leads me also to this bigger idea behind all this, which is um something you call the the code world model, right? Your argument as as I understand it is that autonomous software engineering won't really happen just because coding agents get smarter, it requires this simulation of of the digital environment that the software actually interacts with. So an agent can test and adapt against something much closer to reality before the code actually reaches the end user. Um, when did this this concept of the code world model, like where when did it come into play? Where did you come up with it in the first place? And and why do you think simulation is the missing piece for autonomous software engineering?

SPEAKER_00 26:58

The code world model is essentially the solution for the context void. So what we're saying is, okay, there's a context world, it's not just about MCPs and skills, like LMFs can just cannot just reason on such amount of data. And a good like example of it is autonomous cars, right? So autonomous cars, the first thing you do when you want to develop an autonomous driver is you need a world model for cars. So you need to be able to simulate pedestrians, snow, rain, traffic cones, traffic jams, everything. And in order to have way more cars roam the streets of San Francisco without a driver, it's not enough to just simulate five simulations or maybe some examples. You need to be able to run every new model you have through millions of simulations, 20 different sensors, 30 different sensors to make sure it actually works, right? Like it's not going to be enough to just say, ah, yeah, here's a kid jumping into the road, the car stopped, ship it, right? You need to actually test it across the board. For us, it's very clear that that's exactly the same thing you need for coding agents. The ability to simulate millions of scenarios in real production environment and running your app, really running your app, not just reading the code and saying if there's a bug or not, which is what LLMs do, through those scenarios, in order to give you a very strong signal of whether your app is working or not. And we also think it's not a nice to have, it's not going to make you 20% faster. It's a requirement. In the same way where I couldn't imagine autonomous cars being shipped without a very robust simulation of millions of scenarios. We think the same is true for code, at least on the enterprise level. And I think as coding agents becomes better, smaller teams, deployments, and software will look more like enterprise because smaller teams can just achieve more. So the complexity will increase because basically you can create higher complexity without hiring a lot of engineers.

SPEAKER_01 28:54

It's really interesting. Do you have a do you have a substack or a place where you you write about this on a regular basis? Just out of curiosity.

SPEAKER_00 29:01

Yeah, we actually we use mostly the company blog. So on Checksam, uh on our blog, Checksam AI, publish all of our thoughts pretty regularly about the code world model, the context void, et cetera.

SPEAKER_01 29:12

Perfect. Okay, well, that's where I'm headed after this. Um and I hope listeners uh visit as well. We'll have links in the description and the article um associated with this episode. But Gall, thank you so much for for all the insights you share with us, all these really interesting ideas. Um, and I think you guys are doing some impressive work. And I'd love to um chat with you again in the future and and talk about updates.

SPEAKER_00 29:34

Perfect. I appreciate you having me and I enjoyed the conversation and hope your listeners enjoyed it as well.

SPEAKER_01 29:40

Awesome. All right. Well, thank you, Gall, and thank you all for listening to the SourceForge podcast. I am your host, Bo Hamilton. Make sure to subscribe to stay up to date with all of our upcoming B2B software related podcasts. I will talk to you in the next one.