monkeysee
We build machine learning models that understand web apps, so you can build stable products that better help your users.
why we're here
The web is where modern work gets done. And it's people - you, me, my neighbor Sue - who are asked to do that work. It's no surprise then that since the 90s, web software evolved from brutalist forms and server processing to responsive designs, animations, and background syncing.
That's great for people - and bad for machines. It's especially bad for the machines that are trying to make our lives better: testing software for bugs, screen-reading, or automating workflows. Just take a look at a normal webpage lately. It's a soup of randomly named class tags, styling, and conditional logic.
We've gained better UX but we've lost the capability for computers to interact with the web as we see it. Your options are using an API or doing it manually.
After our research at Stanford, and working at startups to realize automation's potential, we've found there's a better way. We can teach systems to understand the web as we do - to browse it, to interpret it, and to help us do what it takes a person to begrudgingly do today. After a year of training models, we're now starting to do just that.
That begins with more stable frontend testing. Today it's high effort, temperamental, and often seen as a necessary evil. Our vision is to let machines do what machines do best: repetition and reliability. Testing is squarely in that camp. Let's keep the fun stuff for the people - and the automation for the computers.
Pierce Freeman, Founderwho we are
At machine learning companies, there's a constant juggling act between being in the lab versus shipping products. At MonkeySee, we think of what we do as applied research. Research yes, but with the aim of products instead of publications.
But what we call it doesn't matter as much as what we mean. We've built up a few core principles, after seeing the successes and failures at past R&D and engineering groups:
1. A product isn't real until it ships. We talk to customers, hack together prototypes, optimize loss curves, and then build. We'd rather spend a day building to ship than optimizing the last 1%.
2. We're optimists, yet skeptical of shiny new objects that promise the moon. We default to simplicity, to battle tested solutions, and to beautiful code. We measure inefficiencies and fix them as we go.
3. We hire engineers and designers who prefer to spend their time in Vim and Figma than Zoom. We do as much as we can async, we obsessively document, and we're willing to make a risky bet. Bureaucracy too often kills creativity; we have as little of it as possible.
4. We want to keep our team small - now and forever. Everyone's a member of the same technical staff. We want people to feel like they're spending their days with the smartest people they've worked with and building their best work while doing it. Building stuff should be fun, let's keep it that way.
If something we said struck a chord, or you just want to send us a diatribe against byte-pair encodings, we'd love to chat.
Built in California, New Zealand, and around the 🌎