- I expect there will be many more competitors to come, as there already are. I also think achieving these performance improvements is non-trivial and depends on a lot of internal tooling we've built over the last two years (see next answer). As with any software, there will obviously be new competitors that match our historical performance eventually, but we will also be continuing to evolve our product. As you can see from the recall numbers in the benchmark, there is still a lot of room for improvement.
- Mo is really our second product. Over the last two years we've been building the Momentic e2e test framework and tooling around it, which allows engineering teams to own quality by authoring tests in plain-english and maintaining them with little to no effort. Mo builds on top of that nicely because we've already spent a lot of time tuning the underlying tools so that agents can use them efficiently to get better results.
- Real device support is already in the works! It should go live in the next couple of weeks. Would love to connect once it's ready.
Also wow I have been building something similar to that 2 year endeavor. But I didn’t think to store the tests in the actual codebase because the idea was to never look at the codebase for the vibecoders and such. But reading all of this I’m rethinking my technique there, why have the artificial constraint?
How does this differ from Cubumber/Gherkin which basically promised the same? We all know how that ended up, why would you implementation of the same idea be different this time?
- I would always pick an open source tool I can strap to my custom harness over using a service like this. Do you somehow expect that no such competitor will arrive that performs as well?
- If you are YC 2024 what have you been doing for 2 years?
- The real edge here would be supporting mobile development builds on real devices, is this on your roadmap and if so what's your plan to support it? In that case I would pay for this if you handled the real device on your end.