Launch HN: Axiom (YC W21) – No-code browser automation a.k.a. RPA for everyone
Axiom lets you automate by recording actions in the UI, like an Excel macro or Emacs, only it’s for the whole web. It can plug in to your APIs, too, to reach places tools like Zapier can’t. Gartner et. al. call this ‘RPA’ (Robotic Process Automation), but we don’t use this acronym with customers.
I’ve been a long-time HN lurker and occasional commenter. I decided to do a Show HN 9 months ago with v1.0, and people seemed to find it interesting: https://news.ycombinator.com/item?id=23089243. That post was pretty transformative for us. We got our first users outside our local network in London. We got shared on international sites that syndicate HN content. We suddenly had users in Japan, Korea, Denmark... eventually 111 countries in 9 months.
The HN audience were both usefully kind and critical. With our social automations, you pointed out many violate TOS, and “your team needs to do better” (ouch!). That didn't feel good at the time. But later, we learned this is no way to build a business - battling platform providers like LinkedIn does not scale.
We learned our value prop has to also benefit the platform we're automating. LinkedIn automations - though widespread - don't do this. I think we’ve achieved this with our use cases in e-commerce, like helping Amazon sellers do repetitive data entry or report-generation on their store. When we spoke to Amazon about automating repetitive work for sellers, they offered to introduce us to more. Google’s algorithms eventually boosted us to 3rd on the Chrome store for ‘browser automation’, and Microsoft... added special code in Bing to block us. This would have made us sad except, 2000 users later, we have not yet found someone using Bing.
Axiom has also evolved significantly. The problems we’re trying to solve with the DOM, Ajax and messy web-apps are hard ones. Not deep-tech hard, but if you’ve ever written a Selenium or Puppeteer script and tried to write an algorithm to detect the end of page-load... it’s not simple. Since our Show HN, we’ve extended the library of algorithms for more weird stuff you see in web apps: iframes, infinite scrolls, drag-and-drop - there's a lot more to do. Web UIs are complex; if Axiom doesn't work on a website, please let us know, we improve our algorithms with every edge-case.
Until recently, most of our users were no-code enthusiasts (i.e. users of Zapier or Airtable). They used Axiom in agencies to manage YouTube and Amazon accounts. The dominant use-case was “generate reports by logging into A, B, C and getting data”. Since YC though, we’ve discovered a bunch of developer and startup use cases. A very lightweight automated testing tool is a new one - using Axiom is 10X faster than writing it in selenium/puppeteer + we handle all the annoying logic you need. We're investigating a Node library for this - please let us know if it would be useful. Secondly, startups whose business is ‘we provide an API to do X’ use Axiom to perform whatever the 'X' is behind the API - e.g. booking on a travel website.
Although Axiom is primarily a Chrome extension, our cloud product needs neither Chrome, nor an extension! It has a virtual browser, with a full GUI, like you see in browser testing services. You can run it 24/7, or trigger it from Zapier or your API. If you build a bot on the desktop version, we'll guide you through setting it up in the cloud. If you don't use chrome, and would like cloud access, register here: https://axiom.ai/bot-building-service. Being Chrome-only makes us worryingly dependent on Google - we defini...
79 comments
[ 3.5 ms ] story [ 161 ms ] threadOur cloud supports any browser, we let you build a bot using a virtual one, like browserstack.com. As this costs us hosting bills to run, we do ask people to fill in this form, and we can set you up with cloud access: https://axiom.ai/bot-building-service
I thought it was Playwright that depends on patched browser binaries and that Puppeteer works with stock Chrome and does not need Electron. Can you clarify, just trying to learn here.
It doesn't need electron specifically, just several node modules that don't run in a browser-only environment.
We use electron to package up the node modules, and use it for auto-updates + other 'nice' things electron can provide.
I do hate how bloated electron apps become, and ours is also chunky. We'd like to slim this down with time, or perhaps move to a better framework.
I see on the website you have a gif where you're setting up an automation.
I'd love a similar gif (or set of gifs) where you have a before (ugh I have to do this manually), the middle (your current gif), and an after (axiom doing it automatically).
We realised, the best way to do this is start producing templates with solutions to common problems. Here's one:
https://web.axiom.ai/recipe/loop-through-pages
As you say, visual guides work well. I think we have a lot to do here.
We're gradually building up a library on the link above. One day, we'd like people to share their solutions openly (like airtable). We'd need to do security checks on our side though.
Yes, that's the playbook we want to follow - long-tail SEO. That worked amazingly well for Zapier, and if we had a cheesy tagline, it's 'plug gaps in your zaps' like you've suggested!
One interesting side-effect we noticed - people take inspiration from templates for other use-cases and this has driven up usage.
When we show a YouTube studio use case to one customer, they'll try do the same thing in Mixpanel.
Starting a fire here may boil down to how many generalisable templates we can churn out, and how well we can train people on integrating them.
The reason I ask is that Joe Arbitrage could sign up for one paid premium account with a SaaS provider, then use that account and axiom.ai bots to provide the SaaS's services to a bunch of Joe Arbitrage customers at a higher price, i.e. customers who don't know about the original SaaS.
Some SaaS providers wouldn't mind and offer APIs to do the same, but others _would_ mind, so it would be nice if there's a way for them to say "Go away" to axiom.ai bots.
Unfortunately, people can build bots to do all kinds of bad things - this is something we have seen, considered and taken some steps to mitigate.
Right now, we have a low level query, with follow-up manual inspection, to prevent bad actors. (Shout-out to our YC batchmates who alert us https://beta.useavenue.com/).
For example, we detected bots being used for harassment on social media and stamped it out.
It's possible for us to scale this up for similar 'bad use-cases' like the one you've identified.
We just make bot-building accessible to more people. Ideally, that means more helpful bots, but it could result in a more bad bots too, if we're not mindful.
We built axiom after running a software consultancy trying to integrate UiPath for customers.
We realised, those solutions are great for $1 million consulting projects with a big development team. But most bots people need are small, and they need to be updated regularly. Paying for developers to do this is expensive.
So, axiom is self-serve - it's designed to be built and maintained by non-coders on the ground (we provide support). Also, it's designed for the 0-$100 p/m small use-cases. There's lots of these in business.
Some customers think we're expensive, but we're really not compared to most RPA, like UiPath :)
I don't think our UI Testing tools monitor network traffic though. I can see how that might recur - if you email a test scenario to (my HN name) AT axiom.ai, we may be able to whip up some JS, that could be turned into a no-code block, for you and others to use.
I would definitely use Axiom again if I ran into a similar need. Best of luck to your team.
My one suggestion: Let people touch the UI and get a handle for building in a sandbox page on your site--a web app that simulates the app over your own site's dom, for example? I was hesitant to start my trial because 1) risk of hostile chrome extensions 2) wasn't confident I could learn the tool quickly enough. I think if you had a sandbox demonstrator on your site that let people experience the tool, you could learn a lot about where early users stall out and also build confidence toward sign-ups.
What you've described is literally our cloud product - we give people a sandbox with a virtual browser to use and get started (like browserstack). We're working out a way to scale it cheaply, so anyone can get started. Right now, it's a paid feature.
I'm very glad the feature we have planned is something customers would appreciate though, at least we won't have built something nobody wants. We made that mistake in the past...
Creating that toy environment on a single page would result in us engineering something totally new, just for demo purposes.
It's easier to just virtualise everything like browserstack. That way, we don't make anything new, we just virtualise what we've already built, and you can try it, instantly.
It's the same result, but in one case, we spend on engineering, but in the other, we spend on hosting.
UiPath - Designed for heavyweight Enterprise. We're really not competing for the same market, but their tech is a similar approach. They go for fortunate 500, we go for everyone else.
Zapier - Axiom competes with zapier in some ways. We're different because we automate the Ui, not just APIs, and we integrate with Zapier.
Automatio.co - They seem to emphasise cloud running, and their tool looks a bit more complicated. Most of our bots are actually used locally, where the user processes their own data. We support running in the cloud too. It looks like they're charging for distribution, where we're freemium.
Phantombuster - They focus on templates, rather than 'build your own bot'. Also, nearly all social automations like LinkedIn.
There will be more.
Ultimately, I think browser automation will be similar to API automation, where Zapier, Tray.io et al, all compete with different approaches for different segments of the market.
It's a different approach, coupled to automating the desktop office ecosystem, whereas we're coupled to web-apps, and web APIs alone.
Secondly, it is more complicated, a bit more like Leapwork, whereas we're targeting Zapier-level complexity.
Axiom is already too complex for many people (it's why we mainly target these no-code Zapier types). We've seen every marginal % increase in complexity reduces the number of people who can build bots significantly.
Essentially, each RPA product has chosen a power vs ease-of-use trade-off for different segments. We're fixated on the Zapier / Airtable people, not the traditional desktop RPA people, whom I think Microsoft are targetting.
- simplescraper.io
- browserless.io
- include.ai
- apify
- browseai
In a way I suppose the high number of players in the market is validation.
-Simplescraper as the name suggests is very scraping focused, not process automation focused.
-Browserless is more like 'heroku for browser bots' (i.e. a cloud runtime).
-include.ai (having pivoted) are a tool for internal browser extensions.
-browseai focus on the monitoring use-case.
-apify are very cloud runtime focused (they price on the memory of their servers and are much higher than us - getting back into traditional RPA territory).
...speaking of which, I haven't even started on traditional, developer-centric RPA yet. For that there's obviously automation anywhere, blue prism, leapwork, electroneek...
I think this might be more catered towards enterprises. But from what I remember they had tools for everything, and making a bot for a website would only take a few minutes from start to finish.
Many people forget that RPA is over 20 years old. UiPath basically took very old technology, modernised it, and re-applied it to new markets to become a $35 billion company (as of 2021).
The OG Browser RPA solution is iMacros, incidentally, which is now 20 years old! We aim to also modernise what they tried to do and take it to new markets. I guess time will tell whether we succeed at that re-application, like UiPath did on the desktop.
(Aside, we built axiom on puppeteer though).
I think Selenium IDE is primarily a developer tool.
We see axiom as a no-code tool, following the same playbook as zapier and airtable - a 'no-code builder' whose ultimate goal is to create re-usable templates.
What usually happens is someone builds a bot locally, and once it does the task they need, they talk to us about cloud and on-prem.
Puppeteer (the library which runs our bots) does support this easily, so we may be able to whip something up if you have a sizeable use-case.
As someone who has recently started working with puppeteer, I definitely think a library to alleviate that pain would be immensely valuable.
If any puppeteer developers would also find it useful, let us know - it's always good to know something is wanted before you make it.
https://github.com/checkly/headless-recorder
This outputs a series of clicks and keyboard events. It doesn't handle the logic necessary for most JS-heavy web-apps.
Scraping an infinite scroll is a good example. A naive algorithm is - scroll, wait, scrape, scroll, wait, scrape...
We have a slightly more sophisticated algorithm to deal with this. Also, what happens when you encounter a page with multiple iframes?
I'm essentially talking about a library which works with higher-level abstractions than just click and type, perhaps 'ScrapeInfiniteScroll' - and similar operations.
We switched it out for puppeteer as it was more suited as a library for our-case. Cypress is a great batteries-included E2E solution though.
See also https://www.testfront.io/ for an actual description of how it works, but don't bother signing up. I'm really bad at marketing/getting the word out, and google took forever to approve the extension so I lost interest/ran out of money. Maybe if others show interest, I'll be motivated to resume the plans I had for it.
Here's a 4 minute video of it in action, covering every user join/login/update possibility: https://www.youtube.com/watch?v=ifkaptIYeL8
https://axiom.ai/automate-testing
We also have this public recipe:
https://web.axiom.ai/recipe/test-user-interactions
I'd love to reconnect after YC, the last few months have been fairly hectic, so apologies for dropping off the radar.
I've been following your newsletter on https://taskablehq.com/, looking awesome!
1) There isn't an API, it's incomplete, or it's otherwise unsuitable. This is more true for smaller vendors, and less true for the bigger ones.
2) The company doesn't have engineering resource to fully implement an API solution, if it does exist. In this case there's somebody doing the manual process, and they are usually the one who actually implements the automation. This is the advantage of being no code! We've seen this a few times - people have been given the job of manually fulfilling requests and they decide they want to try automating it instead.
They weren't booking something, they were cancelling something, and yes there wasn't an API.
no-coders familiar with Zapier like yourself, tend to find it easy.
Lots of people don't though, and we're working hard on that.
Is that doable with your current product?
Also, this can actually be useful for my side-project, which uses scrapers on pages that often change their html ids and classes, which make the scrapers break quite often. Can axiom help there?
But 'admin dashboards' are certainly very similar to our reporting use case. Basically, people scrape data from various websites into Google sheets. Either locally, or on a schedule in the cloud. That data is then used to generate dynamic reports- or perhaps a dashboard in your case.
Also, we should handle a lot of logic for shifting IDs.
Some of your requirements (like the white labelling), seem complex. Perhaps try making a small proof of concept and talk to support- we'll see if it's possible to scale up.
Does this support direct integration with Win32, Java, SAP (GUI), Citrix, or anything else that is not driven by the browser?
The SAP support is through startup investment, like YC, we were part of SAP.io Berlin: https://sap.io/portfolio/
What are you using for virtual browser? I open sourced my virtual browser component here: https://github.com/i5ik/ViewFinderJS
We've gone brute force, and actually just built a chrome RDP to a containerised browser in your local geography. It's working pretty well.
axiom evolved from an 'automation chatbot' idea originally - we applied to YC with that idea and didn't get in. I don't blame them, nobody wanted it!
We tried to sell it to customers and found the only part they wanted was the browser RPA we connected up to the chatbot. That eventually became axiom.
There's quite a few people who've tried this idea - we've studied the ones that failed pretty intently. The problem is never on making a tool that gets people interested, the problem is building a business out of that interest.
If you ever want to chat about your experiences in the same space, hit me up on (my HN name) AT axiom.ai
I do not think YC is about making something people want, even tho that's the dogma they spout. I reckon YC will knock you back even if can make, or do make, something people want. So it's not about that.
I've always applied on the premise that "I have this very basic prototype, I know this is a big market, my tool will be better, here's why, you should let me in". I wanted them to show faith and fund me from this idea stage, not wait for the rolling customer traction. The kind of faith they show with many other teams who don't have anything to tractioning at first, but have impressive credentials along some axes. They invest in people not ideas. And so I guess, I personally am just "not good enough" according to them. And you are. And that's OK, everybody likes different things. So that's a good vote of confidence for you, and I'm happy you've got that. I think it will help you definitely.
So..so much for my "white, male privilege" I even came from money and had a good education! I guess that just explodes that fake narrative. I'm a nobody, an outsider, not a Standard CS degree person, nor a protected minority. So from YC's point of view there's zero risk in them rejecting me, and from their perspective, there's no meat for them to invest in me. And GitHub stars don't mean anything at all to YC or investors or customers. I see GitHub just as a way to reach people and market. I guess it didn't help that I'm also sincerely pro-China, was a devout Trump believer, say what I think, non-conformist, and a solo founder, and... critical of YC, hahaha. Onetime I applied to YC and the pushed me to the China batch, but a lot of good that did, China didn't want me either, hahaha. Nice try, fellas. Whatever :p :) xx
I can also share some of my business thinking about this market. I agree the failure case is business-ability. I've also studied the failed ones. I think one main fail is people get sucked into becoming a bespoke consulting shop, lured by the hardness of a general solution, tech debt blocking them from making one, a couple big enterprise customers, and they get locked up doing that and can't scale. I've been aware of that since day 1 watching the failure of a couple others in this place, and I always had a different idea.
Still, YC doesn't care. I don't care that they think I'm not good enough for them, I'm happy for them they do what makes them happy. I know if they accepted me, they wouldn't feel happy nor comfortable with that, and I don't want them to do anything they wouldn't feel happy or comfortable with. I wouldn't want to be a spanner in their works, or their delicately oiled machine. From my view, I just figure it's their loss, because I exist outside the scope of what they are able to consider, I'm in the unassessable background, an unknown unknown to them. So that's my advantage, and their disadvantage. I see myself clearly as an outsider, so it doesn't matter at all to me that they do too, in fact it's nice to have something to agree on.
So much for "inclusivity". I guess tolerance for diversity doesn't extend to opinions and experiences. Guess those fake narratives are exploded, too. OH well.
Plus, I think it's better for me this way. It probably wouldn't do me any good to be part of YC anyway. But I keep applying, almost as ...
We think our value prop is better suited to automating a business process, like order fulfilment (and other processes in e-commerce).
There are definitely better scrapers out there than axiom, particularly LinkedIn scrapers. We find axiom is better suited to e-commerce cases like yours though.