Show HN: Axiom – No-code Browser Automation
axiom.ai
axiom.ai
We built a way for non-technical people to automate work in their browser. It’s in beta, and we’ve just made it public: https://axiom.ai/.
After running a consultancy, we noticed lots of small tasks that never got automated. The cost was too high with existing consultancy-focused solutions. So lots of small repetitive tasks built up.
Recently though, RPA has become a popular technology for automating big, repetitive processes.
RPA (Robotic Process Automation) is a way to automate using the user interface of applications, rather than APIs. If you’ve ever used an Excel or Emacs macro, it’s the same principle. Companies like UiPath and Automation anywhere have had great success deploying RPA for enterprise use-cases (e.g. processing 1000s of invoices for a multinational)
But we believe RPA also has potential as a no-code paradigm for smaller use-cases (e.g a customer support person doing data-entry).
That's because most people intuitively understand UIs, but not APIs.
So we thought, what would happen if you took RPA technology and packaged it up in a no-code Zapier-like SaaS? This way, all the small tasks too small for developer time can get automated.
Our current users are mostly non-technical and in roles like sales or e-commerce administration. They have repetitive extract, transform, load (ETL) tasks, like:
-Gathering data for sales enrichment, then inputting into their CRM
-Connecting and exporting data from e-commerce systems like Amazon and Shopify, where APIs are limited.
UI-based automation is not just a way to fill gaps in APIs. We've found it is a more intuitive and faster way for many non-technical people to automate.
Along the way, we’ve also discovered many new niches (like sports betting funds) that we didn’t know existed.
Axiom is not built for large-scale data-scraping or automated testing, though. These require specific features we do not yet support (e.g. IP switching, or assertion logic).
We don’t touch your data. All data-processing and execution occurs client-side, on your machine. We only store the code for execution. For data storage, we use your Google drive account.
Our beta only supports Google Chrome (this is just an MVP. We want to expand support to FireFox and other browsers with time and resources).
I’m sure the HN audience has seen how challenging browser automation can be, particularly with the complexity of modern JS-heavy web-apps. We’d love your feedback, experience and thoughts!
For example:
Some users have said the permissions being requested by our app are off-putting. We’re listening and adapting. We’re removing permissions + improving communication. To reiterate, we do not store any data processed by bots on your machine: https://axiom.ai/privacy-policy
No one offers an easy way to let employees build and share “personal” bots. Part of this has to do with non-programmers having a much harder time understanding things like loops than we imagined they would. Another problem is maintaining business process logic and knowledge as employees come and go. And lastly there is the security thing. In an enterprise setting you probably won’t want to run this in someone else’s cloud, you want to run it through your IT operations in your own onsite/cloud/whatever to both utilise your local accessing rights but also to make sure data never leaves you.
Maybe we’re not who you are targeting, but we’ve yet to find a product that actually lets us let employees build small bots in a way that fits into our IT operations, and this is quite a big market in my country.
Of course you’ll be late to the table, and not be what the big consultant agencies like EY are partnered with. But what they are currently selling isn’t actually what we need.
So good luck, I’ll certainly add you to our “keep a look out” list.
Mainly for paying already approved bills and benefits through different systems. Which aren’t only web based.
But we had/have an intention of letting people use personal automation tools like this project when/if the right setup becomes available.
In large companies asking IT to do things is a death sentence for a project. They are viewed as a cost center and therefore typically under resourced and often times lacking in skill. Bringing in a consultant is even worse. They'll be gone as the tech rots and nobody will know how to fix it.
Democratizing these kinds of things to the users is highly successful and enhances business productivity. The old school only the pros know what they're doing mindset is awful.
The success of companies such as tableau and alteryx are examples of the huge value add that companies can get when they just let their business analysts do things that used to require coders.
I guess my main curiosity is, given a) automations that are more useful / valuable / powerful require more sophisticated techniques and concepts (loops, sessions, states, etc.) and given b) that non-expert users typically don't have them, then how can we solve this problem?
I see the following options: 1) either (pro)users limit themselves to more trivial / simple automations that are useful enough, with the skills they have, but they can't do more and that's that 2) or there has to be some level of expert involvement (IT, freelancer, consultant, or an FTE hired by the department to do this kind of automation work) - so there needs to be some level of budget 3) there's some tool that makes it possible to deliver more complex scenarios without the (pro) user needing to understand those aforementioned concepts
I'd say the RPAs of the world fall into category 2) - requiring a lot of budget, thereby being limited to the very few highest RoI kind of use cases that can afford this budget.
I'd say many tools out there (including UIPath, Axiom, and many others) try to be 3) but end up being 1) or 2).
The problem seems to be not with the tool, but with the fundamental challenge of trying to do something more complex without the skill.
For the record, I'm not saying it is an unworthy endeavour, I just haven't seen any great examples that manage to crack this.
One exception: very domain specific topics. You mention Tableau - basically 'all' the user is doing with it is to slice and view and filter data (that has been connected by experts) in different ways. So the users aren't 'creating', the way they are when they are creating automations.
What is your view?
We didn’t use one of the big consultant houses like EY. We didn’t because we have plenty of business process people, project managers and so on ourselves. And that’s typically what the big consultants mainly offer, they offer it along with tech consultants that are often from some partner. We started by gathering info on what was available, as well as what we thought we needed and we drew on experiences from other cities. Many places had gone with the big consultant agencies and gotten this big package on the business end, and one or two processes build with the tech consultant, and then their project stranded because the business part doesn’t actually build RPA processes.
We decided to go with a small local startup, where we bought hours and “open” consulting. We did brainstorms with them, but then we build things ourselves and had them review it, and we put a much larger focus on learning the technical parts - and well - we are now the leading city on this area if you compare the 96 cities that aren’t our two largest cities. So from my anecdotal view, that is far better than using the big consultant agencies.
I named EY, and that may give them bad publicity here, but EY was actually the best of the big package offers that we didn’t decide to go with. Which is why their name stuck with me, so it’s a little unfair if this makes them look bad.
On the flipside, you yourself mentioned a) the skill level (loops) and b) maintenance and - dare I add - say governance / standards.
I guess it comes down to the tradeoff of [not having tasks automated because it's not worth it for 'the experts'] vs [having a prolific ungoverned set of automations deployed by users with insufficient skill level perform them (kind of like excel macros)].
So given the skill issue, and given that users struggle with things like loops etc. - does that mean that they'll basically just be able to implement 'trivial automations that don't involve complex paradigms'? Or how can non-technical people, fundamentally, crack it and develop more elaborate (and therefore more powerful) automations?
This is what I'm grappling with - I see so many no code tools out there, but at the end of the day, you can only do very limited, not so valuable, automations with them. Curious to learn your thoughts there.
A friend and I recently started building something that might be useful with exactly those kinds of tasks, and we're looking to chat with people who'd be willing to share their real-life use cases for us to build towards.
If you're interested, I'd love to hear more about your needs and the challenges you've come across so far. And no worries if not. My email is in my profile. Cheers!
would a docker deployment to be hosted on your public sector cloud vendor OK ?
Only downside I can think of: pricing is a bit opaque, outside the “desktop” license.
Yeah, so pricing is opaque because in all honestly, we're still figuring things out.
We're unlikely to lift pricing and annoy users. If anything, we're extending the free trial for most users, and may introduce a cheaper tier too.
There does seem to be a strong argument to introduce a cheaper tier for consumer use-cases.
The problem now is that the obvious metric ('bot runs') is too crude for a DIY bot-builder, and may stop users during development.
It's very likely our pricing system will evolve to resemble zapier's multiple tiers - they have the closest business model to ours. We're basically "The Zapier of RPA".
"All your bots live on you computer and process data in your web browser. We store the steps of your bot and data"
It seems the scripts are stored on your servers? Why? Does this mean that you can see my code or is it encrypted?
How does this compare to the more established web macro recorder tools (browser extensions) like the open-source kantu? https://github.com/A9T9/Kantu
This currently runs only on your local machine. We do have a cloud version coming soon, but running your bots this way will be optional.
Yes, the code only is stored, not the data it processes. We could encrypt them so we can't read, but it would prevent us updating your scripts in future for new versions of axiom.
It does mean we could run your code, but this is not something we do, unless you want us to run your script in our cloud.
UI.Vision and long-established macro-recorders like iMacros target developers; this is a complete no-code approach.
Our tool is primarily built for non-technical people. We also have and are building up a bot sharing system (i.e. templated bot app store). It will be subject to manual vetting for quite a while.
Also, we tried to leverage: https://www.diffbot.com/ but the lack-of-accuracy/lack-of-complete-data + cost never justified it's usage.
It's a deceptively hard problem. Essentially, what we do is fingerprint the element. If the page changes, it boils down to how effective our fingerprinting and search algorithms are, to find the element if it has moved or changed.
The algorithms behind that are good enough for most use-cases now, but it's something we're continuously iterating on.
Many non-technical people think in terms of spreadsheets and tables. If you give people the spreadsheet/table as the data structure primitive through which you're iterating, they get the concept of a loop straight away.
Couple that concept with teaching them a variable, and they can achieve a lot.
Many of our users are expecting to pay $50 p/m, but will get a present surprise of a cheaper tier this month, rather than the other way around.
However, I'm concerned about the privacy and security implications of storing users' automation scripts in the cloud. What if I want to automate processes on sites or applications which contain sensitive data?
In other responses I think you've confirmed that scraped data itself is never sent to your servers, but even the script and its metadata (e.g. names of fields, search terms, IDs of elements on the page etc.) can contain sensitive information.
In several of my clients' environments the use of this tool simply wouldn't be allowed because no third party data is allowed to leave the internal network.
Is there a way to use the product without sending any data whatsoever to your servers?
Also, does this work with browsers other than Chrome?
RE: Data leaving the network.
This is a very good point.
If you have a strong business-case you'd like us to look at, but find privacy is the main issue, e-mail me at yaseer AT axiom dot ai; we may be able to investigate what on-prem would look like.
Great and it gets to the point for the end users. But..
> Step 2 of 2 - Install the desktop application.
> 168 MB for the DMG, 427 MB for the app.
I get that this is your first release but is it possible that the Chrome extension can be used on its own? If not is it possible to reduce the size of this app? I say this because my impression after opening this app is that it will be running in the background which will take up more of my Macbook's RAM given that it is Electron.
On top of that, I already have 11 other Electron apps installed and this one is twice as big as three other electron apps I already have and my disk is already complaining about freeing up space.
The first route for this is running your bots in the cloud, although that will mean we have to process your data (something we don't currently do).
We do want to release a stripped down version that can run with the extension alone, however, this won't support many of the most common use-cases for axiom, like bulk downloading and uploading files.
https://chrome.google.com/webstore/detail/pawclaws/figeaallb...
https://github.com/TobiasKundig/PawClaws
https://github.com/PawClaws/chromePawExt
I wonder though: How do you deal with asynchronous sites which may take a variable amount of time for elements to load? Do you synchronize with Angular or try to detect elements or is it just the old stopwatch-and-pray technique?
We fingerprint elements, check if the page is changing along the critical path and wait if it is, and look at network traffic.
We can't say with certainty, but we can form a good guess - the accuracy of that guess is always improving.
This is something I think would benefit from open-source collaboration, if we went down that route.
See, edit, create, and delete ALL of your Google Drive files
See, edit, create, and delete ALL your spreadsheets in Google Drive
We are not reading all your files - we are only reading/writing to the google sheets input as a link to our bot.
We're looking now at turning off access for anything outside Google sheets, so this message and permissions system is less alarming.
I've read through your privacy policy but i'd like some more clarification.
specifically, can you talk about exactly what data is sent to your servers? For example, if i use Axiom to login to a vendor site, those log on credentials should be stored only locally correct? Does your team have the ability to access any of the data that would be retrieved from the vendor application? I have a few really solid use cases but I need to cover the data privacy concerns first.
That's right; Right now, we don't store credentials.
The cookie from your local machine when logged in is passed to axiom locally, and never sent to us.
We store the code for your script on our servers. This is necessary to update scripts for future versions of axiom. We do not store the data this code processes.
We do have a cloud version upcoming that will process data on our servers, but this will be optional, and not enforced.
Cloud version could be cool for some people but i think it might kill any shot at the industry I serve.
Just not the data itself. It's basically what would be stored in a web-scraping or automated testing script.
I'm also curious if there are some use-cases for tracking releases of new content on various sites, similar to how CouchPotato combines TV show releases and tracking them on torrent sites.
The cloud version should enable it though.
One of the most common things people want to do is create a series of bots than consolidates data and generates reports; it has general applicability for use-cases outside COVID.
We would not want this to be done at scale, in a cloud, like a nefarious bot-farm. However, at the scale of a bot tied to a single individual's browser, doing repetitive work in growth-marketing and sales, we'd allow this usage.
Creating user accounts with bots, and crawling certainly is, but I can't see anything about automating likes (correct me if I'm wrong).
There are many chrome extensions which do specifically automate likes on the Chrome store. Ours is just a chrome extension for general browser automation, where this is just one use-case.
...
"You must not create or submit unwanted email, comments, likes or other forms of commercial or harassing communications (a/k/a "spam") to any Instagram users."
This seemed to be something legitimate people/users were doing a lot, so we gave them a building block to make it easier. Maybe we should have thought about it more.
We'll take a step back from that path if our bots become a nuisance on social media. In all honesty, we built axiom with other things in mind (e.g. Repetitive data entry and admin).
It was honestly just some user requests we integrated without enough thought, not something nefarious. This isn't our market by any means.
The point I thought was 'grey' was whether automated likes harass people (Liking to build a following is now part of the standard Instagram marketing playbook).
That is not worth debating though - we agree that TOS are violated. We were wrong and you are correct.
Our users have voiced their concerns about many things (primarily data privacy), but to date, none have told us they felt deceived by the domain.
.ai is a country-code, not an officially designated domain for artificial intelligence.
How you see it doesn't matter. Marketing is not about doing whatever you think is good and then telling your audience they're wrong when they interpret it differently. If someone sees .ai in your business name (and you're not based in Anguilla) then they're going to make some assumptions. In your case that assumption is that the "ai" part is just "marketing bullshit", and that will probably affect whether or not people give your product a fair try.
Formally, .ai is a country domain. However, it's broader meaning is cultural - again, not set by us.
By popular usage .ai has become like .io, used informally as a startup domain. We're really just following that pattern.
Our users don't tell us they felt deceived by the pattern, they never even mention it as a concern. Instead, much concerned feedback is around data-privacy.
Our domain doesn't really conjure many preconceptions for users to feel that deceived. The conceptions are really vague, more like subtle connotations than denotation.
If you arrive at the site thinking "there was a vague connotation of an ai startup. Instead this is a browser automation startup. I have been deceived!"...you would not be our intended user in the first place. Maybe you got us confused with another ai startup somewhere.
Our intended user would arrive expecting, and getting, no-code browser automation.
Further Edit:
I think this comes across more argumentative than I intended.
I just wanted to add that you make a point I understand and agree with; there's been a lot of hype about AI startups that aren't really AI. We aren't one of those, but maybe our domain makes us look like one!
> The Internet country code top-level domain (ccTLD) .io is assigned to the British Indian Ocean Territory.
I mean I might think when I went to their site, huh, doesn't seem to be any AI, but they don't name AI, hah hah bet they couldn't get the domain name they wanted.
"©Axiom AI limited 2020"
If it was purely for convenience of domain name availability? I don't think I've ever seen a company register their name in the format ot
"COMPANY_NAME [TLD_EXTENSION]"
Secondly, our idea on incorporation involved a far more complex product. One in which we could process mine (via ML) browser data to generate business process models (BPMN) and browser automations... Turns out people only wanted the browser automation part of that.
We're left with a .ai domain name and company name, but do not reference any aspect of AI in marketing our browser automation product.
That happened to me, you already lost credibility with me by naming it .ai because, in my mind, you either 1. Have no idea what AI means, or 2. You know very well but you are lying.
I'm not saying either of those are true, but that's what was going through my mind when I first opened the website.
Looks like a useful tool that I'll definitely have a play with.
It's probably unrelated but there's quite a few Artificial Intelligence companies there as well.
You're not, it's fine, move on, focus on your customers and generating more revenue/success for yourself.
Nice looking product! Hope you get continued success with it.
If there is no AI/ML involved, they could simply answer, "it was the only domain name available." and everyone, absolutely everyone, on HN would laugh and move on.
The HN community is not known for "laughing and moving on" - but that's what makes the community great. It's filled with pedantic, over-intellectualised debate, and I wouldn't have it any other way.
Absolutely zero paying customers of his will be bothered or even think about "ai means machine learning blablahblah".
I am being harsh with you and others because there are many many introverted engineers who read HN who let their inner voices second guess every single decision they make. Comments like yours and jonnys do absolutely nothing but add FUD to their process.
If you have legitimate feedback about the product, by all means give it. But picking a silly thing to nitpick about (the TLD of the site!) is nonsense.
In all honesty though, it's this kind of overly intellectualised, pedantic debate that makes HN what it is, and why we all love it.
I would be disappointed if a Show HN didn't have at least one!
> .ai is the Internet country code top-level domain (ccTLD) for Anguilla. It is administered by the government of Anguilla.
Once you are scrapping or interacting with external services there always is the "staying up-to-date" problem.
Ideally you want your selection rules and rules for your actions to be invariant to little change in the user interfaces. This includes various anomaly monitoring like network error, captcha, UI-changes, anti-scrapping measures. An AI can help for that.
The goal is to become fire and forget. You can also extend the technology to become collaborative and do some analytics to leverage AI tools.
However, we have gone with the simplest iteration for MVP
All bots run on your local machine, we only store the code for execution, not the data it processes.
We've taken steps to be classified as a GDPR-compliant data-processor.
We use your browsers local storage for many operations that other applications store on their server.
"All data is stored locally on your machine and not on our server".
When we launch in the coming weeks, I'll be sure to post on HN, but in a nutshell, it's entirely cloud-based (as opposed to having to downloading something), open-source, and at a price point closer to ~$5/m.
Of course, Axios is a far superior product with many more features, but we're targeting individuals who want to automate small parts of their workflows rather than businesses who'd pay $50/m.
I'm glad to see your launch and I'm sure there's plenty of room to play. :)
[1] Very under construction landing page (all hash links) for the extra-curious: https://puppet.js.org
Chrome has privacy problems and I prefer my browsing data stays out of Google's hands.
We received funding/mentorship from SAP via Techstars, but don't integrate with their RPA (right now at least...).
SAP's RPA is more focused on larger enterprise use-cases within their ecosystem, whereas we're looking at SME and even consumer use-cases.
Right now we have a custom code-block with a gloriously undocumented API.
I recommend playing around, seeing if you think axiom is useful for you, then dropping our support an e-mail on ai AT axiom.ai and we can talk you through the rest of your use-case. We're pretty responsive.
I will come back and add more explanation about what this means, and how it works, because the intention is to open this facility more up to the community.
Edit: here are the details. I helped edit the text with which they were appealing to HN. Then, when the post was ready, I put it in the second-chance pool (https://news.ycombinator.com/item?id=11662380), so it got a random placement on HN's front page. We're happy to do that for posts that we think will interest the community. If they don't interest the community, they fall off the front page soon enough.
The support I gave these guys was exactly the same as what we do for YC startups who want to launch on HN—with the exception of the front-page placement mechanism, which is different (see links above).
I've wanted to open this Launch HN process up to non-YC startups for quite some time, and have begun to do it experimentally. The goal is to produce threads that the community finds interesting, and also to help startups. The downside with this is that I'm the only person doing it, there is only one of me, and it doesn't have much spare time. If you want to be considered for this experiment, you're welcome to email hn@ycombinator.com, but please have mercy if I don't reply right away or don't feel that it's a good fit. There's simply no possibility of supporting everybody, even though I would love to.
As someone who's put multiple projects on HackerNews and seen zero comments/upvotes, I'd love to learn what "HN Optimization" looks like. Since there's (presumably) no way to use black-hat techniques to get attention, in theory a better post is good for both the community and the OP.
We learned from that and did not do this on HN (Engineering team were then only ones to have the post shared, as they're real HN community).
I think the algorithms to detect voting rings from dud accounts are not hard.
This paved the way for running axiom in the cloud. Once we can do that, you won't need the desktop app.
I hope with time we can have a slimmed down extension-only version too, but this will be more limited in capability.
Open-source is something we'd definitely consider - there are many hard technical problems with browser automation that would benefit from open-source collaboration.
This thread has given us some serious thoughts about a fully on-premise version though!