The Q/A Layer for the AI Coding Era

Key Takeaways

[music] Hey everyone. Uh, I'm excited to be joined here today by Weiwayi and Jeff. They're the co-founders of Momentic. Uh, Momentic went through YC in winter 2024 and just raised their $50 million series A roundway and Jeff, why don't you tell us what Momentic does? >> Yeah, you know, Momentic is the verification layer for software. You know, we power awesome companies like Notion, Built, Kora, Zero, and you know, we're processing over a million test runs a day. >> And you just raised $50 million in your series A from Standard Capital. Uh maybe tell us a bit about why did you raise the round now? >> Yeah. Yeah. So, so for us we were at a place where we had a you know repeatable sales motion and you know we wanted to raise to scale you know both our engineering and go to market team so we could build more and you know you know uh get more customers >> uh and then why standard capital why did you choose them as your lead? Yeah, for for us like the decision came down was pretty simple. You know, standard was a very quick process. you know, uh, we were, you know, we applied through online, you know, very, you know, not not too unlike, you know, the application for YC and I think the one of the big standouts for us is like, you know, instead of having a, you know, board member on our board, we have a peer group of other similar stage, you know, series A companies to, you know, do our board meetings with, you know, we're, you know, it's a peer group where we're learning and, you know, helping each other. for people who aren't technical, maybe who aren't developers, um, explain sort of what testing even is and then what does Mantic actually do for developers? >> Yeah. Yeah, for sure. So, the, you know, the the quick 101 on testing is that, you know, if I'm shipping code, how do I make sure my app isn't broken? And you know especially as my app is getting larger and larger you know there's multiple people multiple teams working on it there's different product lines and um how do I make sure it's not broken and testing is you know the solution to that you know you you have teams manually testing which is incredibly efficient and you know you have teams also you know dipping their toes into automations like how do we make this process faster more efficient without taking as much you know valuable engineering time and but the the end goal is always like how do I make sure my product is working as I expect. >> One thing that developers are known for traditionally is not wanting to write tests, not enjoying testing. Like is that true for both of you in your careers as engineers? And so if so, like why? Why has there always been this reluctance to write tests? >> Yeah, I think so. Um when I was at Robin Hood, I saw the team grow from 300 engineers to over 1,000. And then my entire job was basically uh managing eight people and trying to get those eight people to convince the other thousand people to write and maintain tests. Uh and our goal was to cover 80% of the code that we wrote uh and maintained a 90% pass rate. And it was basically impossible to do that. Basically like like no one cared about this. And I think it just boils down to the fact that it doesn't feel like productive work. Like it's not work that your customer sees. It's not work that you get to show someone in like a flashy demo. uh it's not work that like shows up on your performance evaluation, right? Uh and so because of that, it always feels like a drag, like a secondary afterthought. Um and that's when you know there's really a risk to quality and reliability. >> Now, as we're entering this era of codegen, there's like it's so fast moving like one one day it's cursor, the next day it's called code. Um maybe the next day it's codeex. Um, one thing that's clearly staying constant is just like the amount of code like lines of code being written per day is growing exponentially. Um, how is that going to impact the need for momentic and testing? Like where do you where have you seen that affect your business? >> Yeah, for sure. I think um as the amount of code output is increasing we see massive bottlenecks you know where there may may not be before in terms of just like how do I actually verify the work you know there's you know you have llinters you have code review but then how do you actually make sure this works when this is deployed to production >> again explain for people who aren't like um engineers themselves kind of what conceptually what are llinters and what's code review and how do that how does that fit in under the umbrella of of testing and and shipping. >> Yeah. Yeah. So, um I think you know when you're shipping a high volume of code, there's certain tools you can use to you know verify that you know the code follows good patterns like you can have llinters that you know scans through your code make sure you're using the you know following the right patterns you know following the right best practices. You can also have a code review where you know it's it can be human another engineer review your code that you're about to merge or you know recently there's been a lot of AI code reviewers where you know help helping to take some of that burden off of humans and I think an important part that momentic solves is beyond all these different checks that you already have today how do you actually make sure it's actually working live and you know the the status quo you know for a lot of teams is, you know, I'm going to go in as a human and log in and manually click around and do like a bug bash every time before a release. And that's just not scalable when you, you know, your product is growing. You have a lot of engineers and it's also, you know, it's just very slow and very expensive. >> And so then where exactly does momentic fit into that flow? Like you know, you have engineers writing the code, you have llinters looking for like, you know, does it conform to the right patterns or not? You have humans reviewing code. Where does Momentic fit in there? >> Yeah. So, uh the the type of testing that Momentic does is uh what we call a functional testing. It's acting impersonating one of your users actually going through your app and you know clicking through and you know uh making sure all of the user flows uh that I can achieve is actually working. And how we fit in is, you know, as an engineer makes a code change, you know, their change is going to impact production in some way. We just make sure that everything that they care about doesn't break. Um, you know, from a end user's perspective. >> How should engineers think about where you fit into the dev stack? Like I've certainly noticed this on our own engineering team at YC like as claude code usage has ramped up. Um we've now set up sort of pipeline like it's in the claw MD file actually to just like make sure you like run your own tests and like make sure they all pass before you like submit any um uh PRs or MRS like where should someone where's an engineer who currently doesn't have aic in their like in that devstack where should they think about inserting you? >> Yeah. So I think there's a couple places um one is within your developer loop. We are seeing a lot of customers actually use our MCP integration to have cursor or cloud code uh write and runic tests while they're developing. So actually while they're creating a new feature or editing an existing feature they'll you know make sure that these coding agents also verify that that change uh is functionally correct uh by calling out to momentic starting a real browser verifying that the flow actually works >> like a tool. It's basically a tool called for one of the agents to like and and so and why is that better than the agent just sort of writing its own tests from scratch. >> Yeah. Yeah. So one thing that we've seen is like first of all the agent often thinks that it doesn't have to do that or whatever it's done is just correct uh even though it's not. Uh and secondly these agents aren't optimized uh for browser use especially in a testing capacity. Uh so uh some of our customers have incredibly complex sites um that are actually incredibly hard to interact with right like rich text editors, drag and drop editors, uh things that have like canvases, right? And these types of applications uh are just uh relatively difficult to verify. Um but we've specialized our agents to deal with that. >> It's also really slow. Like I've used this for just like side projects where you you have the like code browser extension. you can tell cloud code to like use the browser extension to like figure out what's going on with this bug, but it's just like so slow. Um, I presume your agents are like optimized for speed and and and actually being able to test a complex app. >> Yeah. So, the average step for us runs in under 300 milliseconds. Uh, and uh to your point, we've also optimized the debugability UX part of it. So, it's really hard to know what went wrong uh if you use a traditional browser agent. uh you know it's hard to debug you know exactly what element was interacted with or what the state of the page was. Uh we've essentially built the whole platform around that type of user experience and we have agents that uh help with that as well like they automatically diagnose these issues for you. Yeah, cuz I find the existing agents but it's a it works okayish if you know like you've got some like file upload button is not working like open web browser and like figure out why a file upload is not working whereas you guys are like I don't have to specify that at all like yeah I just give you the app and you will just like figure out like all the various things to test and what the correct tests are. >> Yeah, exactly. like um like any user flow you can describe whether it's like to a manual tester or to an AI or you know probably to cursor or cloud code when you're building it just give it to momentic and you know we'll validate it >> and then so then go back you mentioned code review and you certainly like code review like cursor bugbot grapile um these things are like very popular again like the YC engineering pipeline we have these um integrated in I like so what does a future devstack look like are people using you and code review tools. Um are you sort of competing for developer mind share like where like is or are they sort of like totally athogal to each other like what what's how >> Yeah. Yeah. I think I think that's a great question and I think like you know taking a step back is like I would be disappointed in you know 3 to six months I'm still reviewing Typescript or React code and I think like the future of software is moving towards a world where you know I as an engineer can you know provide a plain English spec to some AI agent it's going to build it verify make sure it all works according to you know the success criterias all the different edge cases I've speced out I see you know code as a implementation detail. It's a it's a commodity. You know, some model frontier model out there or you know frontier uh AI coding tool is going to be incredibly good at generating code. It's just the implementation detail. And today I think we have code review because uh we're still we still care very much about the code that's being generated. But I don't think that's necessarily going to be true in you know the next you know 3 to six to to nine months. >> What do you like? Let's assume the models are going to keep getting better and better and just like the quality of the code they output is going to get better and better again like how how does that impact your outlook for momentic over the next x months? I think it impacts user behavior more than anything. Like today, engineers are still very much focused on what code is being generated. But I think as these models get better, that will be less and less of the focus. And humans will be more like requirements gatherers or they'll be sort of like truthf finders, right? Like their goal is basically to figure out like what should be written, what should be built in the first place, right? Like what are the requirements from the end user or like you know I have a thousand future requests from, you know, various like customers. which ones are actually the ones that I'm supposed to build, right? uh and so they kind of become that like almost like u you know uh the input uh to the you know code generator black box and then we're this sort of step that actually validates that whatever the black box uh generates uh is functional >> that it certainly lines up with my own experience as a developer because I feel like that you can clear the model like the quality of the model is getting better and better um but like they will still confidently go off in like the wrong direction and then you're sort of doing this patchwork of like adding things to your claw MD D file like um and trying to make sure it like steers and like it it like consults you before it like I mean plan mode's the obvious example but even sometimes plan mode's not enough if you're like you have to sort of like like before you like go off and like assume that like this hypothesis for debugging is correct like run it by me first. But like yeah, the dream would be to just have like a external source of truth that just knows everything about how my users are using my app and it can consult that and figure out kind of okay no I should like this is of these three hypothesis this is kind of where I should go. Is that like the the way that you imagine momentic interacts with the coding agents? >> Yeah. Yeah. I think the the coding agents uh you know is going to be informed by on what to build by the spec and you know the spec would have details about like you know what is the different user flows it needs to build what different features how it's supposed to work and that spec is also you know the guard rails of like how do you verify these requirements are met and that's completely going to be done through momentic. In a sense, it's like we're closing the loop for, you know, for feedback for the coding agents. >> And why what's the reason that that's always going to be a better product sort of as a a standalone product outside of like the coding agent itself? [snorts] >> One of the things that's pretty interesting is um today uh the the coding agents are you know it can you know it's generating code. It can prompt you for feedback. it can, you know, access thirdarty tools, you know, different dependencies through through MCP servers or or CLI. And I think one of the things that's incredibly important is um how do you make sure, you know, the always the the open question at the end of the day is like how do I make sure you know cursor or cloud code actually built what I told it to build in the exactly the way I told it to build it. And for me like I can't really trust cloud code or cursor to tell me themselves you know I need a third external source of truth for verifying that it's like you know this is why I have like unit tests I have integration tests uh and you know at different parts of of the stack and I think that's an in incredibly important part because uh at the end of the day if something breaks uh you know I can't really you know tell our customer that hey you we vibecoded this with cloud code. You know, you know, our SLA got breached because of that. You know, sorry about that. We're going to revert his their pull request. You know, I think that it doesn't really work on like that because the responsibility ultimately uh is on the product owner on on on the human who was like, you know, delegating to these different AI agents. >> I think the other interesting part about this is that uh cursor or these coding agents in general aren't maintaining your source of truth over time, right? Um it's similar to the question of like why don't you use use cursor to generate playright code right and the answer is well you you can right now you have 100 thousand lines of playright code uh and whenever you change your uh feature in a meaningful way now you have 50k lines that you have to find and update right um I think what we've done is like essentially we have encapsulated that whole system and so we've built a mechanism for automatically maintaining that source of truth over time for you um and even going as far as like suggesting changes to like what your source of truth should be like you've added this new um you know UI component. Was that intentional? Uh and if so, you know, I I can automatically actually update the test for you without you having to go through another, you know, 200,000 tokens uh or yeah, your course of credits in one session. >> Cool. Um so let's Okay, so then um uh let's talk about one of your um one of your biggest customers, Notion. like me. Um I would love to learn a little bit about um how were they thinking about testing before Momentic? How did they hear about you then? How do you convince them to use you and what's sort of been the difference in their workflow post Momentic? >> Yeah. Yeah, for sure. So, I think it's a really funny story on how you know we started working with Notion is um uh Simon uh from from Notion actually was posting on Twitter on like you know it'd be great. I I forget exactly what was in his tweet. Um, but he was like, "It would be great if I could just like describe this and, you know, test it for me." Uh, and you know, a lot of people were commenting on the Twitter thread. A lot of people recommended Momentic. I was in San Francisco actually that evening at 10 p.m. I DM'd Simon, Simon Last, and I was like, I I think we have we've built exactly what you want. I I can onboard you tonight. I sent him a loom of like, you know, me testing on like my own personal uh notion workspace. And you know we I onboarded him that night and then you know it turns out you know it was a good enough experience where we know we decided to do like a more official like PC process with the broader uh notion team. Um but you know they were coming from a mix of like manual testing a really big suite of selenium that the team was maintaining and that was just taking a lot of effort because you know selenium is like notoriously uh prone to flakiness you know whether it's like x pass or selectors which is how you target elements on the page uh you know it would it frequently break you especially since notion is such a you know a very it's a notion is a very flexible product you know a rich text editor you know everything's a database but all of those things are also very difficult to test with selenium and you know we were able to handle that with momentic you know quite quite easily you know through just like plain English instructions and you know now today they execute almost like half a million test runs a day um you know uh momentic tests must pass before one of notion's engineers can merge their PR >> how does not sort of quantify the value um they've gotten from working with Mantic. >> We can think about ROI in a few different lenses. Like one could be, you know, developer hours saved with Momentic compared to Selenium. Know that's like I think the easiest, especially if you're coming from like a legacy tool like Selenium or Cypress or or Playright. Um and but I think the the northstar is, you know, how many uh regressions or SES are we, you know, are momentic tests preventing from reaching your end customers? because you know that is kind of the the end goal. you know tests are just you know a way for you to you know prevent these types of regressions and incidents and um you know that that that would be how we would uh track ROI for you know our customers and and notion >> I've heard you well mention this idea of like truth driven driven truth driven development um what does that mean um and where does momentic fit into that >> I would say like the two main schools of thought is that you know one is your code is the source of truth. You know, whatever is in prod is what you've specified it to be. You know, that's a direct reflection of your codebase. And then uh which I think has a a few gaps. It's not necessarily like entirely incorrect, but you know, code has uh bugs and you know, are these bugs also part of your source? Is that how your you know product is supposed to behave? Um and then the other one is like what I would consider like you know truth driven development or like spec driven development. This is where uh someone typically like a human in collaboration with AI you know uh is you know specking out in detail you know different user journeys, user flows, uh success criteria, edge cases within your application. Um and this is the source of truth uh for how your product is supposed to work. Your code is just an implementation of that source of truth. And you know because you know uh you know since engineers are humans you know we make mistakes you know AI make mistakes we're all contributing to this codebase it doesn't really make sense for that codebase you know production to be the source of truth for how my product is supposed to work so I think like one of the things that you know especially as all of these different AI coding tools how we interact with AI is increasingly through uh you know plain English text you know I'm chatting with cursor I'm chatting of cloud code. I'm chatting with chat GBT. Um you know our our bet is that in the future you know in the near future I would imagine um instead of you know writing code and reviewing code I would actually just be writing specs and you know you know in detailing edge cases success criteria you know that's for you know these AI agents to you know to build. I don't really code if they're using I don't really care if they're using you know TypeScript or Rust or anything like that. They're just implementation details to me. All I care about is you know the end user journey, the end success criteria that I've speced out in the future and that's like my source of truth. >> Do you think the role of being an engineer then moves away from sort of starting with the code, looking the code, really deeply understanding the code and eventually like engineering is just going to mean like reviewing the specs like will you need any appreciation of like the code and and thinking about that as as a source of anything? Uh I mean I think so in so much that I think there are still many technical aspects of being a software engineer that are not based in the code right like thinking about how this integrates with other systems or third party dependencies or you know the scalability aspects or even just like thinking about taste right like I think models are not particularly good right now um at producing like tasteful UX for example and that's like the the difference between chat GPT uh you know like generating or like you uh you know like uh like a Figma lookalike and and actual Figma, right? Uh like I think the the devil's very much in the details. Uh so I do think the technical expertise still matters, but at the same time um you know I feel like good engineers were always like sort of their own PMs in a way like they always had a you know strong product in intuition and a sense of like what the vision for their product should be. And I think that's going to be more and more true um as the sort of like truth driven development idea becomes more prevalent. what's sort of on the road map for you guys maybe especially this year and then maybe even further a field >> you know some of the things that you know we've been uh working hard on for example you know is Android uh iOS you know desktop app support um and I think if anything our focus this year has narrowed you know we've seen firsthand like how fast engineers are moving and how and then we're always thinking about how can we accelerate them how can How can we be faster? How can we be, you know, more integrated with their existing tools and workflows? And how do we make the barrier entry, you know, zero or negative? You know, they just fall into this pit of success with Momentic. Um, and like on that side, like we we a big focus this year is definitely on just like developer experience, developer productivity for our our customers. uh you know uh you know beyond just like the core primitives that we support as like a a platform >> and then maybe as a company kind of as you start adding people and you grow the company um how do you think about that like what are the skills and maybe especially for engineering like what skills do you look for and how do you think that's changed from sort of like pre AI world >> I think to be honest a good engineer is still a really good engineer um I think um I actually wrote a LinkedIn post about this But um like codeex like only makes you like a 10x engineer if you weren't a 10x engineer to begin with, you know. Uh and I think that's um that underscores the fact that like if you're adaptable, if you can navigate like ambiguity, if you're like curious and passionate, then that continues to be an asset. Uh and that's still what we're looking for. Uh I think you know now that sort of the industry is moving at this like incredibly fast pace it's even more important to be able to you know adapt to new trends to you know be able to take in that you know there's this a new like level of tooling that you can adopt that you know drummatically does accelerate your code output um and you know uh I think like as always like we need folks with like strong product intuition as as people uh at momentic like I think effectively like own uh like entire domains and are given a lot of ownership a responsibility. >> Have you thought about just the company culture? Like anything? How would you describe your culture as being sort of unique to you guys and Momentic? >> Yeah, I think you know we're still a pretty small team. We're a team of 13 and I'll say our culture is still you know budding early early stages. Uh but I think one of the things that uh we care a lot about is you know radical uh canandoandor you know it's like direct you know clear direct feedback. you know, don't be a dick. Don't be an to your co-workers and people that you're, you know, working with day-to-day, but also being able to, you know, give and receive feedback so everyone can be the best version of themselves. And, you know, we want to hear everyone's voice. Everyone has a say in our product roadmap. You know, we want to hear all of your feedback, all of our customers feedback. And I think that's kind of the the basis driving, you know, how we think about culture. um you know and you know just be a be a pleasure to work with and and learn from. >> How did you both get into engineering and and tech and startups? Love to hear like the the the quick overview of that. >> When I uh graduated high school, I was actually planning to be a pharmacist. Uh, I was gonna go to um like a a farmd program and then the summer uh before college I um went to a pharmacy camp with a friend and it was the most boring experience of my life. Like you know it's like I after that camp I decided to change my major. Uh I I actually got into like University of Minnesota they had like a in pharmacy what it call it's like two years undergrad four-year farmd program. I was like I'm going to change my major to computer science. can't get into like know the science and engineering college and they like let me uh so I you know that's how I got into computer science and um you know software engineering. So, I was going to study uh uh chemistry at Cambridge actually. Um and then uh similar to your experience, uh I did a summer internship and the day-to-day lab work was incredibly grueling. Uh and you know, essentially uh each researcher does their own work uh in a fairly isolated way. And I realized that uh while it was like technically interesting and I think the problem solved are some of the most important problems in the world that type of work didn't sort of challenge all of me as a person. Like there was a part of me um that you know really wanted to build products and work with other people and and you know like rally a team and and I think that interpersonal side of things just like was missing uh from that day-to-day life. Um, and when I think that's like what pushed me towards founding ultimately is like I think it it is like the one rule that really pushes you in like every aspect of your life. >> Cool. And then how did the two of you or why how and why did you team up and work on this specific idea? >> Uh, so we actually got introduced um like end of 2023 through like a mutual friend uh Dan Robinson the old CTO of heap >> and like I was actually beta beta testing like Dan's startup at the time which was like called like QQ bot. Everything was like using AI to it was like cursor for unit test before cursor existed and then um you know I was sharing I was like uh building you know a few prototypes on the side and uh I was sharing with Dan and actually Dan introduced me to to Jeff who was kind of you know who was building his own product in the same uh you know in the same space I was. So like you know we we met we had a quick zoom call. Uh I was in Seattle and Jeff was in San Francisco. Um and you know I actually flew down I stayed on Jeff's couch for like a week or so. um you know before uh you know we decided to like join forces and you know you know build momentic together. >> And what prompted you to apply to YC and what was that process like? >> I think it was your idea actually. Uh I was incredibly unconvinced we would get in actually. Um and um you know at that time we had a little more than a prototype. Uh AI agents were really bad at that point. um models still had like 16k in like token limits which meant that most websites wouldn't actually fit uh within the context window um and you know we barely had any market traction um so you know I thought there's no way they would take us uh but I think way convinced me it was like you know we've been jamming on this I see the potential um and we might as well throw in an application so we we did that and and here we are. >> Yeah. Yeah. I think for what it's worth, we had a like I think like six or seven pilot customers at the time that you know we were hopeful were would convert. So you know we I think we had you know good quality of customer feedback and interactions. Yeah. >> Yeah. Um [laughter] as founders now and your journey what have been some of like the most challenging moments um running and growing the company and um how have you handled them? For me, I would say building the company early on in terms of headcount was really challenging. Um, especially at the seed stage, you know, there's a ton of seedstage startups now building a lot of cool stuff. Um, and when people say, you know, see like AI seedstage startup, I think like there's a lot of thrash right now, like people don't know what what to choose from. Um, and uh, you know, especially given like how popular um, and strong the sort of foundational model companies are, there's like a strong draw kind of like away from the startup kind of market. Uh, so I think we had a really tough time with, you know, just like early talent and and um convincing people that we were, you know, going to win it. Um, I think we had to really double down on uh proving that, you know, our culture was solid. Like we invested a ton in in our interview process. Um, where we would talk to people multiple times uh before they, you know, ever did a single interview. Um, we would be really intentional about the on-site. we ended up building a sort of rather unique kind of one-day work trial process. Um, and you know we double down on the sort of culture when they joined as well. So uh we do uh you know really in-depth team retros and discussions uh retreats as well. I think for me like I think the main thing would be like how how do we you know the landscape within AI is shifting so much. how do we you know uh you know adapt on the fly to different workflows to different trends we're seeing you know of course like new tools new models things like that and then but at the same time also looking ahead is like you know what is the what is the actual problem we're trying to solve rather than you know uh creating a solution trying to fit a problem into it kind of the opposite way around and you know making sure you know the whole team is aligned on the direction that we're going and is like you know is very very excited about it and then I think like secondary is like, you know, learning how to sell as an engineer. Uh, you know, how do I what's a P, what's a pilot, what's the difference? Uh, you know, what are the things I should say on these sales calls? And, you know, I think like over the past two years, I'm still a new seller, but I think I've gotten gotten a decent amount better at, you know, selling and pitching and, you know, solving customer pain. >> What's your best advice to engineers who are sort of where you were a couple of years ago starting out need to learn to sell? Like, what's the what's your best advice? >> Yeah. uh you just have to do it. You know, you're you're you know, you you have to be comfortable with that. You know, I I I I I think I think about it as like you have different cohorts and every cohort you're going to burn and they'll some of them will probably never come back. But this is great learning experience for you and uh you know as you know to learn and evolve in your you know your sales process, how you talk to customers, how you solve how you communicate, how your your product solves their their problems. Um, but I think the end of the day is just, you know, you have to get your reps in. You can't learn just by watching someone else sell. You know, everyone has their own unique way of communicating and and selling and chatting with customers and you just have to get the rep reps in. >> What keeps you both motivated to want to keep working on this problem and build this into a huge company? Um, uh, through the inevitable challenges you have. Uh I think a lot about the impact that we could have if we fully solve the problem of code validation. Like I think a lot of product development, feature development is is blocked on how fast you can verify code right now. Uh and so like I think about like the global kind of productivity improvement uh that we can make uh you know if we change this like very fundamental aspect of how software engineering works. It's like a fairly I guess like utilitarian mindset almost. Um but um as someone who's like always been really passionate about DVX, it feels incredibly sort of force multiplying uh to be able to um you know like make everyone else around you uh you know be able to deliver a higher quality product with a few bucks. For me there is you know momentic is disrupting like a massive industry. You know the QA industry is massive but that's actually not the market we're specifically targeting. targeting all software. Every software that's ever going to be built now and in the future will need to be verified. And how do you do that? It's going to be with Momentic. And then I think like secondary is like I just I I want to win, but not just win. I want to kill all of our competitors. Like we will win and destroy them all. Like it it it is inevitable. We will make that happen. >> Nice. All right. Well, on that note, that's all we have time [laughter] all we have time for today. Um, congrats so much um on the round and I'm really excited to see where you guys uh take things and um looking forward to seeing momentic continue to grow this year and the years beyond. >> Yeah, thanks thanks for having us Har cool. [music]