So, what's the moat?

Hey there, I'm Jeff (one of the founders). To be honest I don't know if there is or will be any kind of moat in SaaS. But today:

1/ General purpose models are still not good at this task. I would personally love it if I could trust my agent when it says its done after a 24h build. But whether it's because of sycophancy, context degradation over time, or something else coding agents still struggle to verify their own work. Maybe with 1B context windows this will change.

2/ Infra is still annoying to setup. We wanted to provide a unified interface across web, mobile and soon desktop as well. So users don't have to worry about provisioning, concurrency, security, etc.

3/ As with any SaaS, even beyond the initial build, maintenance is a headache. I think most companies would rather not consider agentic QA as one of their core competencies and investments. It takes a ton of eng effort to keep the lights on, continually update the models used, train new ones, groom ground truth, onboard infra providers, etc.

▲

Arkada 41 minutes ago | parent [-]

When people say "just point Opus/Codex at localhost using Playwright MCP," they've obviously never attempted to do exploratory testing by leveraging parallel browser workers against stateful applications. A coding agent running in a loop spends almost all of its context window struggling with DOM selectors and doesn't even detect state persistence problems like the 2.5h->25h decimal inflation upon refreshing the page as demonstrated in the demo. Managing read/write resource leases for parallel sub-agents not to step on each other's test fixtures is already a non-trivial orchestration challenge by itself.

	▲	MGabrielDenton 20 minutes ago \| parent \| next [-]
		Agreed! We've also found that the tooling you use makes a big difference in how efficient and precise the agent is, which is why we included the comparison of Playwright MCP vs agent-browser. When we were first starting Mo we tried using several different browser interfaces but we weren't able to get the recall we wanted. We settled on rewriting some custom tooling based on our mcp for our investigatory/exploratory agents. Tooling about how to interact with the A11y and DOM, breaking out easy CUA subproblems, and browser infra are still all non-trivial problems.
	▲	slopnt 30 minutes ago \| parent \| prev [-]
		just have engineers not sleep at the wheel and implement appropiate solutions when agent struggles?

▲

Aboutplants 2 hours ago | parent | prev | next [-]

The moat is about a week before the frontier models integrate the same capabilities. They aren’t snapping up projects like this for talent acquisitions anymore, they will just build it themselves.

▲

sercand 2 hours ago | parent | prev | next [-]

we also build similar product in-house for our apps.

▲

0xy 2 hours ago | parent | prev [-]

I have something similar I made for my side project. You don't really need a platform for this.

	▲	jeffan 8 minutes ago \| parent \| next [-]
		Hey, Jeff I'm one of the co-founders. Totally agree for a small side project, having a single sub-agent that focuses on vibe testing is enough. But I would say even for medium sized features, it's the same difference between asking your Codex to "review the code make no mistakes" and using a paid AI code review tool. As your product surface area increases, you need fundamentally different agent architecture to maintain context over time and across bug bash sessions. The benchmark apps are probably among the simplest apps we test on, and even those show a massive perf. gain. For large companies with 1000s of important user flows, have to support different viewports, and need to work across mobile/web/desktop, asking Codex to test it all before a big launch is not scalable. Even basic constraints like the # of browsers/devices you can run concurrently, the amount of reliable TPM you need, and how many agents can run on a single box become problematic. You also have to think about ktlo: how do you evaluate new model releases in a data driven way, how does agent become more efficient itself over time, etc.
	▲	Fordec an hour ago \| parent \| prev [-]
		Same, I just built mine in two months. Screenshots, agent spin up, and I'm cheaper than Codex because of how I built my own secret sauce. This strikes me as a company that is late delivering a product for November 2025, when it is November 2026.