EVERY SPOKEN WORD
35 min read · 6,938 words- 0:00 – 0:05
Intro
- HTHarj Taggar
[upbeat music]
- 0:05 – 0:57
Momentic overview and why they raised a $50M Series A now
- HTHarj Taggar
Hey, everyone. Uh, I'm excited to be joined here today by Weiwei 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 round. Weiwei and Jeff, why don't you tell us what Momentic does?
- WWWeiwei Wu
Yeah. You know, Momentic is the verification layer for software. You know, we, we power awesome companies like Notion, Built, Quora, Xero, and you know, we're processing over a million test runs a day.
- HTHarj Taggar
And you just raised $50 million in your Series A from Standard Capital. Uh, te- maybe tell us a bit about why did you raise the round now?
- WWWeiwei Wu
Yeah, yeah. So, so for us, we were at a place where we had a s- 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, s- uh, get more customers.
- 0:57 – 1:32
Choosing Standard Capital and a peer-group board model
- HTHarj Taggar
Uh, and then why Standard Capital? Why'd you choose them as your lead?
- WWWeiwei Wu
Yeah, yeah. For, for us, like, the decision came down w- 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 s- you know, uh, 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, t- helping each other.
- 1:32 – 2:24
Testing 101: why software teams test and why it gets hard at scale
- HTHarj Taggar
For people who aren't technical maybe, who aren't developers, um, explain sort of wha- what testing even is, and then what does Momentic actually do for developers?
- WWWeiwei Wu
Mm-hmm. 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? H- And... But the, the end goal is always, like, how do I make sure my product is working as I expect?
- 2:24 – 3:26
Why engineers avoid tests: incentives, visibility, and maintenance pain
- HTHarj Taggar
One thing that developers are known for traditionally is not wanting to write tests-
- WWWeiwei Wu
[laughs]
- HTHarj Taggar
... not enjoying testing. Like, is that true for both of you in your careers as engineers? And sort of, if so, like, why? Why has there always been this reluctance to write tests?
- JAJeff An
Yeah, I think so. Um, when I was at Robinhood, I, I saw the team grow from 300 engineers to over 1,000, and 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 maintain a 90% pass rate. And it was basically impossible to do that. Basically, 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.
- 3:26 – 4:15
Code-gen era: exploding code output creates a verification bottleneck
- HTHarj Taggar
Now, as we're entering this era of code gen, there's, like... It, it's so fast-moving. Like, one, one day it's Cursor, the next day it's Claude Code, um, maybe the next day it's Codex. [laughs] 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?
- WWWeiwei Wu
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 linters, you have code review, but then how do you actually make sure this works when this is deployed to production?
- 4:15 – 5:32
Linters and code review vs. real functional correctness in production
- HTHarj Taggar
E- explain, explain for people who aren't, like, um, engineers themselves kind of what, conceptually, what are linters-
- WWWeiwei Wu
Mm-hmm
- HTHarj Taggar
... and, and what's code review, and how do the- how does that fit in under the umbrella of, of testing and, and shipping code?
- WWWeiwei Wu
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 linters 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 gonna go in as a human and log in and manually click around and do, like, a bug bash be- 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.
- 5:32 – 6:54
Where Momentic fits: functional testing that impersonates a user
- HTHarj Taggar
And so then where exactly does Momentic fit into that flow? Like, you know, you have engineers writing the code, you have linters 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?
- WWWeiwei Wu
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, uh, 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 gonna impact production in some way. We just make sure that-
- JAJeff An
Everything that they care about doesn't break, um, you know, from a end user's perspective.
- HTHarj Taggar
How should engineers think about where you fit into the dev stack? Like I've, 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 Claude 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 is an engineer who currently doesn't have Momentic in their, like, in that dev stack, where should they think about inserting you?
- 6:54 – 8:05
Using Momentic inside the developer loop via MCP (Cursor/Claude Code)
- JAJeff An
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 a cursor or Claude Code, uh, write and run Momentic 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.
- HTHarj Taggar
So like a tool... It's basically a tool call for one of the agents to like-
- JAJeff An
Right. Yeah
- HTHarj Taggar
... and, and so and why is that better than the agent just sort of writing its own tests from scratch?
- JAJeff An
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, they 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 are just, uh, relatively difficult to verify, um, but we've specialized our agents to deal with that.
- 8:05 – 9:24
Speed and debuggability: why specialized testing agents outperform generic browser agents
- HTHarj Taggar
It's also really slow. Like, I've used this for just, like, side projects where you, you have the, like, Claude Code browser extension, and you can tell Claude Code to, like, use the browser extension to, like-
- JAJeff An
Right
- HTHarj Taggar
... figure out what's going on with this bug, but it's just, like, so slow. Um-
- JAJeff An
Yeah
- HTHarj Taggar
... I presume your agents are more, like, optimized for, for speed and-
- JAJeff An
Mm-hmm
- HTHarj Taggar
... and, and actually being able to test a complex app.
- JAJeff An
Yeah, so the average step for us runs in under 300 mil- milliseconds. Uh, and, uh, to your point, we've also optimized the debug ability 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.
- HTHarj Taggar
Yeah.
- JAJeff An
Like, they automatically diagnose these issues for you.
- HTHarj Taggar
Yeah, because I find the existing agents a bit... It's a, it works okay-ish 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.
- JAJeff An
Yeah, e- 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 Claude Code when you're building it, just give it to Momentic and, you know, we'll validate it.
- 9:24 – 13:15
The future dev stack: code review fades, specs become primary, verification becomes central
- HTHarj Taggar
And then, so then Garry, you mentioned code review, and you certainly went, like, code review, like Cursor's BugBot, Reptile, um, these things are, like, very popular. Again, like the YC engineering pipeline, we have these, um, integrated in. I know, like... So what does a future dev stack look like? Are people using you and code review tools? Um, are you sort of competing for developer mindshare? Like where, like is or are they sort of, like, totally orthogonal to each other? Like what, what's... How should we think about that?
- JAJeff An
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, three 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 gonna build it, verify it, make sure it all works according to the, you know, the success criterias, all the different edge cases I've specced out. I see, you know, code as a implementation detail. It's a, it's a commodity. You know, some co- model, frontier model out there is or, you know, frontier, uh, AI coding tool is going to be incredibly good at generating code at 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 gonna be true in, you know, the next, you know, three to six to, to nine months.
- HTHarj Taggar
What, what do you... Like, let's assume the models are gonna keep getting better and better and just, like, the quality of the code, the output is gonna get better and better.
- JAJeff An
Mm-hmm.
- HTHarj Taggar
Again, like how, how does that impact your outlook for Momentic over the next X months?
- JAJeff An
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 truth 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 1,000 feature requests from, you know, various, like, customers, which ones are actually the ones that I'm supposed to build, right?
- HTHarj Taggar
Yeah.
- JAJeff An
Uh, and so they kind of become that, like, almost like, uh, you know, uh, the inputs, uh, to the, you know, code generator black box, and then we're the s- sort of step that actually validates that whatever the black box, uh, generates, uh, is functional.
- HTHarj Taggar
That sort of certainly lines up with my own experience as a developer, because I feel like that you can cle- the model, like the quality of the model's 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 Claude MD file.
- WWWeiwei Wu
[laughs]
- HTHarj Taggar
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 I feel. Like you have to sort of like in- like, like before you like go off and like assume that like this hypothesis for debugging is correct, like run it by me first.
- WWWeiwei Wu
Right.
- HTHarj Taggar
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 like, "Okay, no, actually like this is... Of these three hypotheses, this is kind of where I should go."
- WWWeiwei Wu
Yeah.
- HTHarj Taggar
Is that like the, the way that you imagine Momentic interacts with the coding agents?
- WWWeiwei Wu
Yeah, yeah. I think h- 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 are the different features, how it's supposed to work. And that spec is also, you know, the guardrails of like how do you verify these requirements are met, and that's completely going to be done through Momentic. So i- in a sense, it's like we're closing the loop for, you know, for feedback for the coding agents. Yeah.
- 13:15 – 15:40
Why verification must be an external source of truth (and stay maintainable over time)
- HTHarj Taggar
A- and why... What's the reason that that's always gonna be a better product, sort of as a, a standalone product outside of like the coding agent itself?
- WWWeiwei Wu
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 third party 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, the op- always the o- the open question at the end of the day is like how do I make sure, you know, Cursor or Claude 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 Claude Code or Cursor to tell me themselves. You know, I need a th- third, uh, 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 inc- 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 know, we've vibe coded this with Claude Code, you know, you know, our SLA got breached because of that. You know, sorry about that. We're gonna revert his, their port request." You know, I think that it doesn't really work on, like that because, you know, the responsibility ultimately, uh, is on the product owner, uh, on, on, on the human who is like, you know, delegating to these different AI agents.
- JAJeff An
I think the other interesting part about this is that, uh, Cursor or just 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 just use Cursor to generate Playwright code, right? And the answer is, well, you, you can, right? Now you have 100,000 lines of Playwright 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 Cursor credits in one session. [laughs]
- 15:40 – 17:49
Customer story: Notion adoption from a tweet to PR-gating at massive scale
- HTHarj Taggar
Cool. Um, so let's... Okay, so then, um, uh, let's talk about one of your, um, one of your biggest customers, uh, Notion. Like may, um, I would love to learn a little bit about, um, kind... 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?
- WWWeiwei Wu
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:00 PM I DM'd Simon, uh, 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, it turns out, you know, it was a good enough experience where we, you know, we decided to do like a more official like POC process with the broader, uh, Notion team. Um, but you know, they were coming from a mix of like manual testing, a really big s- 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 Xpath or selectors, you know, which is how you target elements on the page. Uh, you know, it w- it would frequently break, you know, especially since Notion is such a, you know, a very... It's a... Notion's a very flexible product, you know. The 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.
- 17:49 – 20:53
Measuring ROI and the philosophy of truth-driven (spec-driven) development
- HTHarj Taggar
How does Notion sort of quantify the value, uh, um, they've gotten from working with Momentic?
- WWWeiwei Wu
We can think about ROI in a, a few different lenses. Like one could be, you know-Developer hours saved with Momentic compared to Selenium. You know, that's like I think the easiest, especially if you're coming from like a legacy tool like Selenium or, or Cypress or, or Playwright. Um, and but I think the, the north star is, you know, how many, uh, regressions or SEV's are we... You know, are Momentic tests preventing from reaching your end customers? 'Cause, you know, that is kind of the, the end goal. You know, tests are just, you know, a, 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.
- HTHarj Taggar
I've heard you sort of well mention this idea of like truth driven, driven... truth-driven development. Um, what does that mean? Um, and kind of where does Momentic fit into that?
- WWWeiwei Wu
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's in prod is what you've specified it to be. You know, that's a direct reflection of your code base. 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 truth? 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, speccing 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 may make mistakes. We're all contributing to this code base. It doesn't really make sense for that code base, 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 with Cloud Code, I'm chatting with ChatGPT. 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 s- detailing edge cases, success criteria. You know, that's for, you know, these AI agent- agents to, you know, to build. I don't really code if they're using... Uh, 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 specced out in the future, and that's like my source of truth.
- 20:53 – 33:53
Engineering role shifts, product taste still matters, plus roadmap and company-building
- HTHarj Taggar
Do you think the role of being an engineer then moves away from sort of starting with the code, looking at the code, really deeply understanding the code, and eventually like engineering's just gonna mean like reviewing the specs? Like, will you need any appreciation of, like, the code and, and, uh, thinking about that as a, as a source of anything?
- JAJeff An
Uh, I mean, I think so insomuch 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 ChatGPT, uh, you know, like generating like you... Uh, you know, like, uh, like a Figma lookalike and, and actual Figma, right? Uh, like I think the, the devil is 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 in the sense of like what the vision for their, uh, product should be, and I think that's gonna be more and more true, um, as the sort of like truth-driven development idea becomes more prevalent.
- HTHarj Taggar
What's sort of on the roadmap for you guys, maybe especially this year and then m- maybe even further afield?
- WWWeiwei Wu
You know, some of the things that, you know, we've been s- uh, working hard on, uh, 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 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, 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, a platform.
- HTHarj Taggar
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, AI world?
- JAJeff An
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 Codex like only makes you like a 10X engineer i- 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's 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 the... You know, there's this, a new like level of tooling that you can adopt that, you know, dramatically 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, and are given a lot of ownership and re- and responsibility.
- HTHarj Taggar
Have you thought about just the company culture? Like, anything... W- how would you describe your culture as being sort of u- unique to you guys and Momentic?
- WWWeiwei Wu
Yeah. I think, you know, we're still a pretty small team. We're a team of 13, and I'll say our, 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, candor. You know, it's, like, direct, you know, clear, direct feedback. You know, don't be a dick. Don't be an asshole to your coworkers 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 wanna hear everyone's voice. Everyone has a say in our product roadmap. You know, we wanna 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.
- HTHarj Taggar
How did you both get into engineering and, and tech and startups? I'd love to hear, like, the, the, the quick overview of that.
- WWWeiwei Wu
When I, uh, graduated high school, I was actually planning to be a pharmacist. Uh, I was gonna go to, um, like, a, a PharmD program, and then, uh, 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.
- HTHarj Taggar
[laughs]
- WWWeiwei Wu
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 Mo- Minnesota. They had, like, a, a... In pharmacy, what I call, it's like two years undergrad, four-year PharmD program. I was like, "I'm gonna change my major to computer science. Can I get into, like, you know, the science and engineering college?" And they, like, let me. Uh, so I... And, you know, that's how I got into [laughs] computer science and, um, you know, software engineering.
- JAJeff An
So I was gonna 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 in- interesting, and I think the problem solver of 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, 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.
- HTHarj Taggar
Cool. And then how did the two of you... Or why... How and why did you team up and work on this specific idea?
- WWWeiwei Wu
Uh, so we actually got introduced, um, like, end of 2023 through, like, a mutual friend, uh, Dan Robinson, the old CTO of Heap.
- HTHarj Taggar
Mm.
- WWWeiwei Wu
And, like, I was actually beta, beta testing, like, Dan's startup at the time, which was, like, called, like, QQ Bot, I think. It was, like, using AI to... It was like Cursor for unit tests 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.
- HTHarj Taggar
A- and what prompted you to apply to YC, and what was that process like?
- JAJeff An
I think it was your idea, actually. Uh, I was incredibly unconvinced we would get in, actually.
- HTHarj Taggar
[laughs]
- JAJeff An
Um, and, um, you know, at that time, we had little more than a prototype. Uh, AI agents were really bad at that point. Um, models still had, like, 16K and, 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 that there's no way they would take us. Uh, but I think Weiwei convinced me. He was like, "You know, we've been jamming on this. I see the potential, um, and we might as well throw in an application." Um, so we, we did that, and, and here we are.
- WWWeiwei Wu
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-
- HTHarj Taggar
[laughs]
- WWWeiwei Wu
... and interactions. Yeah. [laughs]
- JAJeff An
Yeah.
- HTHarj Taggar
That helps.
- WWWeiwei Wu
[laughs]
- HTHarj Taggar
Um, as founders now in 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?
- JAJeff An
For me, I would say building the company early on, uh, in terms of head count, was really challenging. Um, especially at the seed stage. You know, there's a ton of seed stage startups right now building a lot of cool stuff. Um, and when people say, you know, see, like, AI seed stage 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 our, in, in our, in our interview process, um, where we would talk to people multiple times, uh, before they, you know, ev- ev- ever did a single interview. Um, we would be really intentional about the onsite. We end- ended up building a sort of rather unique kind of one-day work trial process. Um, and, you know, we doubled down on c- the sort of culture when they joined as well. So, uh, we do, uh, you know, really in-depth team re- re- retros and discussions, uh, retreats as well.
- WWWeiwei Wu
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, 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 s- sell as an engineer. Uh, you know, how do I... What's a POC? 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, a new seller, but I think I've, I've gotten, gotten a decent amount better at, you know, selling and pitching and, you know, solving customer pain. [laughs]
Episode duration: 33:54
Install uListen for AI-powered chat & search across the full episode — Get Full Transcript
Transcript of episode UpWNdSVWA7M
