I used this product a while back to do some scraping of a very annoying (and slow!) to navigate website and it was a life-saver. Still using the google sheets it helped me generate. I saw the value of this tool straight away and the UI was pretty reasonable, just a few quirks.

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.

Wow, that's awesome!

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...

Sounds like you’re on the right track. I personally think codeless tools like these are all about confidence-building. I’m just technical enough to know what Puppeteer is and know how long it would take me to learn it. If I see that I can learn your tool right on your site/play around with it without having to sign up, my conviction goes way up.

The cloud feature sounds like a nice product, but I think ordinaryradial was suggesting something else (or if he wasn't, I am): a toy app on your own pages that also has the automation scripts "pre-injected". It would be limited to just running on that sample app but would let people try it out immediately in their own browser without needing to install an extension or use a full-blown virtual browser.

Ah yes, I get the gist - I didn't explain the rationale well!

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.

That’s certainly fair - you’ve got to build out the cloud offering anyway. Makes sense, even if the toy idea is in some ways simpler from a technology point of view; dev resources aren’t free.

>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 - let us know if it would be useful.

As someone who has recently started working with puppeteer, I definitely think a library to alleviate that pain would be immensely valuable.

Interesting!

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.

Check out Headless Recorder. It records browser interactions and generates Puppeteer and Playwright scripts.

https://github.com/checkly/headless-recorder

So what I'm suggesting is slightly different.

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.

As a developer about to go down the e2e testing pipeline for our new products and chosen puppeteer, I would also be very interested in this.

I always hated writing e2e tests (tools like Cypress just didn't cut it for me), so I put this together a while back (it's open source, MIT licensed): https://github.com/testfront-io/testfront-devtools

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

for anyone else about to go down the e2e testing road - I recommend checking out cypress.io

Funnily enough, the first axiom prototype we sold customers was on cypress.io - I liked it!

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.

We’re building this at Superadmin, specifically for e2e tests. We’re a little bit early but would love to collect feedback. Can we get you in as an early user?

Does axiom.ai respect robots.txt restrictions or something similar (i.e. something specific to axiom.ai)?

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.

We aren't looking at robots.txt - but that's a great suggestion. It leads to a bigger point about bad actors.

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.

Why couldn't this guy, or girl just program that directly in JavaScript instead of using this product. I don't see making browser automation easier as something which would enable bad people

Certainly - we don't enable something to be done that couldn't be done before.

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.

Browser automation tends to be fairly easy anyway, I can't imagine anyone who wants to build bad bots only does so due to an no code solution.

I think you're right, we just have a responsibility to kick those people off our platform.

Who are your top competitors and how do you differentiate yourselves? Esp re recent HN submission https://news.ycombinator.com/item?id=26239975

Here's a list of competitors and how I think we compare with each -

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.

Seems like Microsoft Power Automate (Flow) is your biggest competitor? It's free for all Office 365 users (most people).

Yes, we've been monitoring Power Automate too!

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.

They have cloud work flows as well. I wish you guys all the best though!

Thanks for the synopsis. There definitely seems to new wave of automation tools coming out these days.

I don’t know if you can consider them a competitor but Kofax RPA, formerly known as Kapow Software / Kapow Katalyst is a powerful one I used many many years ago. I think the original product dates back to the 90s. You build a flow-diagram like process, with the possibility for a full suite of tools for a complete automation setup.

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.

Ah yes, Kapow! This is like 'OG RPA' (...the technical definition)

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.

Add to that https://ui.vision/ (formerly Kantu). I used Kantu in 2019 to build data extractors and it worked very well.

Add to that:

- simplescraper.io

- browserless.io

- include.ai

- apify

- browseai

In a way I suppose the high number of players in the market is validation.

Indeed, there's demand/a market! Every player has a slightly different angle and market focus:

-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 remember your first post, and planned to tinker with it for a product idea. I was thinking of using Axiom to build sort of an "admin dashboard" from scraped data - kind of between library usage to white-labeling - where users can build their owns scrapers, as well as use built in ones I build.

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?

We probably couldn't help with white labelling, no.

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.

Have used axiom was very impressed with how easy it was to use and was capable of. I use as my own sort of zapier moving between some custom built stuff we have in work

Thanks!

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.

Neat! I feel like I have a reasonably good idea of what this does, but I'd love to see an example to make it really come to life.

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).

You've hit the nail on the head for our biggest problem - many people don't realise axiom can solve their problem!

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.

I explored this idea last year and suspect this will be your main problem (people are bad at discovering automation use cases), unless you want to spend all your time fixing Craigslist scrapers. One possible solution is to keep writing these "templates", but publish them as Zaps, and ensure you rank when people google for solutions. I suspect the user-facing tool you have now could actually just be internal, used for writing as many zap automations as possible, to fill the gaps in Zapier's catalog. Use Zapier for distribution and find some verticals you can productize. Best of luck!

Ha, you're pretty well versed in the pain-points!

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.

Does Axiom support the ability to use network request data as a condition? I often test analytics integrations, and it's pretty repetitive to look at the query parameters or browser extensions for each one. It'd be helpful to automate tests based on whether a pageview generates a request to domain.com with param x=0, etc.

We actually do look at network requests, but we only do this to assess page-load. Assessing this is a surprisingly hard-problem.

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'll start by saying unlike a majority of HN readers I am non-technical. I am an axiom customer and have had interactions with Yaseer, Alex, and Simon and must say they are very communicative and helpful! I use the product for some order fulfillment automation with one of my suppliers and it works great. If you have a project it might help with I say give it a shot especially since they now have a free tier!

Thanks for the kind words!

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.

We really enjoy working with our customers :) thank you.

I normally hate this kind of animations on websites, but in this case they look really good. (Only on the first page though, when I click on later pages, for instance "Bot Service", waiting for content to show is annoying.)

Thanks, noted! The crane is kind of our mascot at this point, he's been there since the very beginning (even when the product idea was quite different).

Awesome glad you like the animations. I have made a note of your feedback; I will strip the page animations out of the nested pages. I still want to add a little something with animation and our branding to give the pages a unique feel, but something small and subtle.

The site uses words like Spreadsheet, Desktop, and GUI and appears to be supported by SAP.

Does this support direct integration with Win32, Java, SAP (GUI), Citrix, or anything else that is not driven by the browser?

We're entirely browser focused.

The SAP support is through startup investment, like YC, we were part of SAP.io Berlin: https://sap.io/portfolio/

Perfect timing, was just looking for something similar to this

Awesome, let us know if you have any feedback, or if you need any help getting set up!

Yes, selenium, and selenium IDE was definitely our original inspiration.

(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.

Regarding testing, that sounds like a great use case but I had trouble locating information on your website about it.

This is a good point - we haven't put it in our marketing yet, the use-case is new. Here's a non-public landing page though!

https://axiom.ai/automate-testing

We also have this public recipe:

https://web.axiom.ai/recipe/test-user-interactions

> We built Axiom on a pretty popular framework, Puppeteer, which requires desktop binaries to run. This means you need an Electron app, too.

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.

Yep, you're right!

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.

Thanks, that makes sense

Is there any capability to run bots headless on our own infrastructure as opposed to locally?

Yes there is! We do have an on-prem solution.

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.

Follow-up question, can I screenshot webpages that it visits?

Not currently in the no-code interface! I've seen this requested before.

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.

I set up a meeting for tomorrow through your website (look for a meeting with Brendan), we've got a large use case for this and it could really help us out.

awesome, we'll drop you an email too to understand more!

Curious about this use-case "booking on a travel website" - are companies using Axiom during a live request to book flight / hotels? What's the need for using Axiom vs using the booking sites API directly?

There are two main ways this can happen:

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.

Secondly, I obfuscated the example a little for the startup's privacy.

They weren't booking something, they were cancelling something, and yes there wasn't an API.

Hi, how do you compare your solution with UIPath? Thanks!

Great question!

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 :)

Just curious: why do you ask? (I work for UIP)

Hi! Is there a plan for a Firefox version?

Right now our desktop app is chrome only, but we'll expand to other browsers post YC.

Our 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

Been applying to YC with this idea since 2015 and been knocked back 12 times now. Congrats on getting in and getting customers, is very inspiring to see more success in this market. I truly believe that unlocking the latent value in the structure of web apps is such a huge thing that's going to be a real game changer for the future.

What are you using for virtual browser? I open sourced my virtual browser component here: https://github.com/i5ik/ViewFinderJS

This is really neat! I'll have to look at this in more depth, you've got some traction on that github.

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

Hey congrats Yaseer and team! Exciting to watch your progress.

Thanks Matt!

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!