CHAPTERS
- 0:05 – 0:57
Momentic overview and why they raised a $50M Series A now
Harj introduces Weiwei Wu and Jeff An, co-founders of Momentic, and frames the company’s rapid growth. They explain Momentic as a software verification layer and discuss why the timing was right to raise a large Series A to scale engineering and go-to-market.
- •Momentic positions itself as the verification layer for software
- •Claims of scale: over a million test runs per day and notable customers
- •Series A rationale: repeatable sales motion and readiness to scale teams
- •Fundraising as a catalyst to build more product and acquire more customers
- 0:57 – 1:32
Choosing Standard Capital and a peer-group board model
Weiwei explains why Standard Capital was selected as the lead investor. A key differentiator was a fast, application-like process and an alternative to a traditional board seat: a peer-group board format with similar-stage companies.
- •Standard Capital’s process was quick and lightweight
- •Applied online, similar in spirit to YC’s application
- •No traditional board member; instead, a peer group for board meetings
- •Peer model emphasizes shared learning and mutual support
- 1:32 – 2:24
Testing 101: why software teams test and why it gets hard at scale
The conversation shifts to a non-technical explanation of testing. Weiwei describes testing as ensuring an app isn’t broken as code, teams, and product surface area expand, and contrasts manual testing with automation attempts.
- •Testing ensures the product works as expected after code changes
- •Complexity grows with more teams, features, and product lines
- •Manual testing is common but costly in time and effort
- •Automation aims to speed verification while saving engineering time
- 2:24 – 3:26
Why engineers avoid tests: incentives, visibility, and maintenance pain
Jeff recounts his experience at Robinhood trying to drive test coverage across a rapidly scaling engineering org. He argues tests feel non-productive because customers don’t see them and they rarely map to performance incentives, creating quality risk.
- •Real-world example: scaling from 300 to 1,000+ engineers made test discipline hard
- •Coverage and pass-rate goals were difficult to sustain
- •Tests feel like invisible work: no demos, low recognition, weak incentives
- •Neglecting tests increases reliability and incident risk
- 3:26 – 4:15
Code-gen era: exploding code output creates a verification bottleneck
Harj and Weiwei discuss how AI coding tools increase the volume and speed of code changes. Weiwei argues the limiting factor becomes verification—ensuring changes actually work in production beyond static checks.
- •AI tools accelerate code creation and increase daily code volume
- •Verification becomes the new bottleneck
- •Static checks exist, but production correctness still needs validation
- •Business tailwind: higher velocity increases demand for scalable testing
- 4:15 – 5:32
Linters and code review vs. real functional correctness in production
Weiwei explains linters and code review for non-engineers, including the rise of AI code reviewers. He argues these checks don’t guarantee user-facing behavior works, and manual pre-release bug bashes don’t scale.
- •Linters enforce patterns and best practices automatically
- •Code review can be human or AI-assisted
- •Neither guarantees the feature works when deployed
- •Manual clicking/bug bashes are slow, expensive, and unscalable
- 5:32 – 6:54
Where Momentic fits: functional testing that impersonates a user
Momentic’s core value is positioned as functional testing—running real user flows through the product to confirm behavior. It slots into the workflow as a guardrail after code changes to ensure end-user-critical paths don’t break.
- •Momentic runs functional tests by interacting with the app like a user
- •Focus on validating key user flows end-to-end
- •Triggered by code changes to catch breakage before production
- •Goal: ensure what engineers care about doesn’t break from the user perspective
- 6:54 – 8:05
Using Momentic inside the developer loop via MCP (Cursor/Claude Code)
Jeff describes how customers integrate Momentic into day-to-day development using MCP integrations, enabling coding agents to write and run Momentic tests during feature development. The discussion contrasts this with agents generating ad-hoc tests and highlights challenges with complex UIs.
- •Momentic can be called by agents as a tool during development
- •Agents often skip verification or assume correctness without checks
- •Browser-based testing is hard for generic agents, especially with complex UIs
- •Momentic specializes in interacting with rich editors, drag-and-drop, canvases
- 8:05 – 9:24
Speed and debuggability: why specialized testing agents outperform generic browser agents
Harj and Jeff discuss the practical drawbacks of generic browser agents: slowness and poor debugging visibility. Jeff highlights Momentic’s performance (fast step execution) and platform UX designed to diagnose failures and explain what went wrong.
- •Generic browser-agent workflows can be too slow for iterative development
- •Momentic’s steps average under ~300ms (claimed)
- •Debuggability is core: visibility into interacted elements and page state
- •Automated diagnosis helps identify why a test failed
- 9:24 – 13:15
The future dev stack: code review fades, specs become primary, verification becomes central
Jeff argues engineers will soon stop spending time reviewing implementation-level code and instead provide specs in plain English. In this world, Momentic becomes the independent validator that checks whether generated software satisfies requirements and edge cases.
- •Prediction: code becomes a commodity and an implementation detail
- •Code review matters less as model quality improves
- •Engineers shift toward requirements gathering and “truth finding”
- •Momentic’s role: validate that AI-built output is functionally correct
- 13:15 – 15:40
Why verification must be an external source of truth (and stay maintainable over time)
Weiwei and Jeff explain why coding agents can’t reliably self-verify and why ownership and accountability demand independent validation. Jeff adds that generated test code (e.g., Playwright) becomes unmaintainable at scale, whereas Momentic aims to maintain and evolve the “source of truth” automatically.
- •You can’t trust the same agent that wrote code to declare it correct
- •Accountability sits with the human/product owner, not the tool
- •Naively generating test code creates huge maintenance burdens
- •Momentic aims to auto-maintain tests and suggest source-of-truth updates
- 15:40 – 17:49
Customer story: Notion adoption from a tweet to PR-gating at massive scale
Weiwei shares how Notion discovered Momentic via a Twitter thread and was onboarded the same night. Notion moved from manual testing and flaky Selenium suites to plain-English functional tests, ultimately gating merges on Momentic and running hundreds of thousands of tests daily.
- •Origin: Notion employee tweet; community recommended Momentic
- •Weiwei DM’d, sent a Loom, and onboarded immediately
- •Notion’s prior approach: manual testing + large Selenium suite with flakiness
- •Outcome: ~500k test runs/day and Momentic tests required before merging PRs
- 17:49 – 20:53
Measuring ROI and the philosophy of truth-driven (spec-driven) development
Weiwei outlines ROI metrics: developer time saved and, more importantly, regressions/SEVs prevented. He contrasts “code as truth” with spec/truth-driven development where detailed user flows and acceptance criteria become the primary source of truth, with code as implementation.
- •ROI lens 1: engineer hours saved versus legacy tools (Selenium/Cypress/Playwright)
- •ROI north star: regressions and incidents prevented from reaching customers
- •Critique: production/code contains bugs, so it’s a flawed source of truth
- •Spec-driven approach: user journeys, edge cases, and success criteria define truth
- 20:53 – 33:54
Engineering role shifts, product taste still matters, plus roadmap and company-building
Jeff argues engineers will still need technical judgment beyond code—systems thinking, scalability, and product taste—while becoming more product/spec oriented. Weiwei shares roadmap focus (mobile/desktop support, deeper integrations, lower friction), and they discuss hiring, culture, founder stories, YC, early challenges, and motivation.
- •Engineers still add value in systems integration, scalability, and UX taste
- •Roadmap: Android/iOS/desktop support, tighter workflow integrations, better DevX
- •Hiring: adaptability, ambiguity tolerance, curiosity, and product intuition remain key
- •Culture: radical candor and feedback; early-stage team building challenges
- •Founder origin stories, teaming up, YC application, learning to sell, and ambition
