UiPath on track to be the best-ever European seed investment
sifted.eu
sifted.eu
At the time of the shootout, I'd never heard of it.
After testing it (and soliciting test user feedback), their genius is simple -- don't suck in a category of products where everything else sucks.
To use an example more might be familiar with, they're the Salesforce, JetBrains, or HashiCorp of RPA.
They don't do anything amazing, but they're executing like a modern software company. And all of their competitors (Automation Anywhere, OpenSpan/Pega, etc.) are still in the upjumped-inhouse-ugly-consultant-software mindset.
AMA if you're curious.
Edit: As to why they're valued at $35B, consider that their customer base is "Every company with IT too screwed up / incompetent to deliver new features in a timely manner."
You’ve got the decimal place wrong. It’s $35 billion
Either seems an astonishing number for "we click things on the screen" software.
Fortunately Thing X actually has a lot of value to a lot of people. I enjoy seeing this story far more than Facebook et al.
What are the most important use-cases that you see UIPath solving? I'm familiar with what they do at a high level, but I'm not sure who they're really most useful to in practice.
Also curious who their typical buyer is - eg functional heads, IT, eng, or someone else...
Typically, applications will be a mix of web (potentially back to IE-11-only type stuff), Windows (including whatever old UI libs might have been used), and mainframe (via emulator).
None of these have modern-style APIs (except for mainframe via the surprisingly foresightful HLLAPI).
So tl;dr, "I want to do new things, but can't change anything." An example would be insurance companies having to quickly alter their processing, in a matter of months, due to the Affordable Care Act.
Using the med insurance example, an average claims processors will have to interact with a claims system (3rd party Windows app), workflow management / audit system (3rd party Windows app), possibly core data systems (mainframe and/or legacy DB), and 1+ ancillary unsynchronized data systems (e.g. med review, communication portals, external processors for various functions). All of this to do a "pay the claim" process. For 100+ claims a day.
So that "stack" is your average automation target, which you typically want 100% automation coverage against, or it isn't viable.
The typical buyer is almost always on the business side. Either a business VP or Director, or someone under the CFO.
CFO-initiated projects usually focus on cost saving by re-onshoring low-value work previously offshored to India et al. Data entry into legacy systems, etc.
Surprisingly, another key reason is usually "increasing ability to own and quickly change processes" (vs simply headcount reduction)! But organizations are waking up to the peril of that's-too-legacy-to-change components.
Then once it’s made the first time, it runs on their machine again. Or it runs on some central server?
Typical workflow for an "unattended" automation (which runs on a headless VM in a data centre somewhere) would be:
- Run "Developer Studio" on a dev machine
- Write "code" (in a visual programming language) to tell the software how to interact with other user interfaces (there are various different methods for this: via browser plugin to interact with the DOM in a web browser, or using screenreader APIs for native Windows applications, or even via OCR-like methods if all else fails)
- Save the automation "source code" (it's a visual programming language, based on VB.NET/C#, and the underlying source code is XAML files), ideally add to version control
- "Publish" the new automation to a central "Orchestrator" server - which is responsible for pushing the new automation code to other headless VMs, and coordinating execution
The key to getting automation reliable is being able to reliably identify target objects (e.g. button, grid cell, etc).
... reliably identify it, regardless of what screwed up, unsupported, what-were-these-devs-thinking underlying code.
I once had to automate a webpage that was dynamically built, at user runtime, from a mainframe screen. Of course without any classes or id tags anywhere.
So if the tool doesn't give you a toolbox big enough to handle pathological cases, it's not really fit for purpose.
For example I had a client who had a manual process where a clerk entered info from physical cancelled checks into a spreadsheet. The spreadsheet was then fed into their accounting system for balancing.
I wrote some Python code that would take a PDF of scanned check images, run the file through Google vision to OCR it, then pull the check info from the scanned data and put it into the spreadsheet. The accuracy is pretty good and any errors are put into a comment column of the spreadsheet where the user can review it.
This code runs in a Windows server and becomes a UIPath bot in the system. So the user who is not very technically inclined merely has to log into the system, upload a scanned PDF and will receive the scanned results after the batch runs.
The idea of RPA-as-glue-for-legacy-systems is something that a friend who's building a company in the RPA space had mentioned once. It made sense to me at the time in theory, but this example really helps to drive home how that plays out in practice.
This is because it's a game of long tail compatibility. That one Java UI library from the mid-90s that one Japanese bank wrote half their systems in? Better support it!
Unfortunately, that's tough to do without amortizing the development cost over a large customer base.
And that's not even the totality of their potential customer base. It just happens to be their primary focus (and pricing model) right now.
There are a huge number of repetitive processes/workflows that simply don't bubble up to the purview of IT. They either don't directly intersect the systems centrally managed by IT, don't warrant the cost/time/effort required for IT to get involved, aren't formally documented or known by IT in the first place, or IT simply doesn't provide any official channels to engage with them for automation-related support.
UIPath's current market positioning and pricing scheme is geared solidly at business cases built off of "ROI of RPA vs. IT modernization efforts". With a focus on automating singular processes occurring at a high frequency. Which alone is enough to support their valuation. But they could also trivially expand their positioning to include "power user" oriented pricing plans and move into that area of the market as well, where singular users (or teams) have a high quantity of low volume workflows.
An adversarial relationship with every company's IT department is a rocky road.
When with minimal product pivoting, they can be the savior of IT. Don't bill yourself as "replace IT," do so as "rapid prototyping."
What's the biggest pain in the ass about internal product development? Getting users to explain what they do and tell you what they want built.
By giving them the ability to self-execute, you invert that. "Mock up what you want in UiPath. Run it for 6 months to a year to tweak it how you want it. Then come to us and have it implemented properly."
Cleaner, more accurate specs (because they come from actual production); business does value discovery on their own; IT doesn't have to deal with hotball "this needs to be built in the next 14 days" demands trashing their strategic timelines.
By the time they get there, they’re 98% not interested in switching from something working and they understand/control into something that won’t work for a while, will likely have some bugs, and won’t be in their control at all if they want changes.
The business also doesn't understand source control, separation of duties, lifecycle promotion, release processes, or technical debt. (Literally, because it was partly my job to teach this again and again)
So eventually the audit firms are going to clue up and start hitting people with notes for over-reliance on prototype RPA systems in prod without change control. As they should.
Your comment hits the nail on the head.
I like to draw comparisons between UiPath's software and Excel:
- Highly underrated by most people in IT
- Super fast initial learning curve to start doing something useful
- Yet also possible to use for years without learning all aspects
- ... and just as easy to make a huge unmaintainable mess in the wrong hands
Given how well Excel has done this con doesn't matter and might even be a pro I guess.
I like to say that it's easy enough to build a Selenium script for something simple like read a dozen PDF's and populate a webform, but when you scale to dozens of PC's running 24/7 (often in a broom closet because the client org hasn't mastered Cloud), then the features RPA tools offer like logging, security (you're using real application credentials to log in), scheduling and load balancing, and workflow management (this one failed, someone manually do it) start becoming useful, and more importantly, accessible to someone who doesn't necessarily have a developer background.
For most enterprises, it provides a unified flow across the variety of technologies their core applications are built in: heavyweight Windows, mainframe, Java, etc.
(Thanks for all your work building awesome things!)
Most RPA vendors are cross-trained from the business side, rather than having a background in tech. So they're generally not very familiar with the broader tech world. (Their dev teams are, but those aren't the folks writing blog posts)
And for Windows automation in general there are many tools like e. g. AHK, Sikuli or UI.Vision that combine Selenium features with RPA features. And they are free, open-source or at least very low cost compared to UIPath.
If your needs are minimal (e.g. test automation, because you don't care if it breaks 10% of the time), that's probably enough.
But they're definitely not the same class of tools.
[0] https://www.autohotkey.com/docs/commands/Control.htm
Of course, these tools are more lightweight and lack the advanced scheduling, monitoring and robot distribution features ("Orchestrator") that UIPath offers. But if one needs only straightforward task and test automation they are a good and reliable alternative.
These are all things I've had break visual matching in prod deployments.
The scheduling, monitoring, and distribution are (IMHO) the least interesting parts of UiPath. They're pretty trivial to build with other tech.
But a matching engine that offers a plethora of high level rule options, coupled with deep inspection capability, and fast runtime matching? That's a pretty big building block.
I just don't understand that term though. There are no robots involved. As a robotics dude working with actual physical robots, that have wheels and arms etc, I got a bunch of recruiters for RPA roles recently. Why the confusing name for RPA?
It kind of makes sense if you look at it from the perspective of it being a "machine that resembles a human". Not that I agree with it.
It's a terrible name and a terrible acronym, superceded only by the absurdity of the "post-RPA" terms that companies are now trying to differentiate themselves via (e.g. "intelligent process automation").
If you are a non-technical user, they will look like magic. But there were still lots of cases (lots of government sites, integrating with custom programs to pass areas of the screen into so I could run a captcha solver against it, React-heavy sites were the edge cases I ran into) where I could not get UiPath to work for me when I tried it a couple years ago. If they've changed a lot since then, then I'll give them another shot. At the time, I gave up, buckled down and scraped the cursed sites using a variety of means.
I really, really wanted to champion them for the solution at the time. It would have drastically increased the value-add of my deliverable, as the subject-to-change web GUI part that we simply could not get around for the client other than scraping could be updated by the client themselves instead of looping me in for another custom coding session simply because some intern decided it would be cool to change the field names at the same time they added the nifty new UI animation/widget du jour.
They're gradually catching up as more sites are written in modern web tech. But it can still be a pain in the ass.
When you don't have the luxury of picking and choosing opportunities, or not automating part of a workflow, compatibility matters.
This is Blue Prism's (new!) IDE UI: https://m.youtube.com/watch?v=KIaPsr0U_sU&t=5m23s
IMHO, Blue Prism feels a lot like a product of IBM. A tool where inefficiency and steep learning curve matter less than guardrails to be able to staff 100 minimally educated "developers" on a project and get something the client will sign off on.
There's a reason UiPath's target customer is "everyone." Blue Prism's target customer is "automation consultancies."
And I can say this for certainty, because when we tried to buy Blue Prism, we had to convince them to think about selling to us. They know their UX is terrible.
Unfortunately, it does this in a hamfisted way that makes the product harder to learn and use than it needs to be. It's fine if that's all you use, but you're not going to be able to quickly crosstrain / ramp someone up on it.
IMHO, that defeats a core value proposition: enable non-developers to develop.
I've demo'd the MS offering (Power Automate), but haven't daily driven it. It's slick.
The question I have is where MS is positioning it. I don't think it's an independent product, so I think they might see it as filling in a gap in the O365 offering? I don't think legacy support is a major point for them, which will probably be good enough for most people.
I think MS is planning to offer it in the O365 stack which means if its half decent it will probably eat UI Path's lunch?
> I don't think legacy support is a major point for them, which will probably be good enough for most people.
Interesting that you say that, I thought that would be one of the primary usecases of RPA? Legacy apps where there's no possibility of an API.
My guess would be they'll develop really tight integration with the Office suite, wrap a thin shim around Active Accessibility [0] / UI Automation (/ whatever they want to call it), and call it a day.
Also, there's a ton of Java stuff out there that gets very esoteric. And that doesn't seem like something MS is interested in expanding into.
[0] https://en.m.wikipedia.org/wiki/Microsoft_Active_Accessibili...
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
the current thread is the only one with any comments:
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
I was just curious about a $35B company, arguably the most successful European tech investment of all time, never having been discussed on HN before. There have been comments though: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Here's how conversations typically go -- Dev: "Why are you using this? Why don't you use X?" Business: "Are you willing to write interface code to {legacy system}?" Dev: {crickets} Business: "Well, RPA it is then."
To dang's point, apologies for the insinuation, which doesn't seem to be borne out by the submitters' post histories anyway.
A more supported hypothesis is as you said: "This isn't something that a lot of HN-type devs care about or see."
In the same way we don't get many posts about Oracle, VMware, or SAP here, relative to their actual deployments.
- If there's some boring business process (that usually involves copy-and-pasting)
- Which you just know could be automated easily if only there was an API, but there isn't
- And everyone who's ever asked about an API has been told it's too difficult/expensive/etc to create an API (e.g., for an ancient legacy system)
... then there's the RPA opportunity.
In my opinion, it's not popular on HN for the same reason that legacy systems aren't popular on HN.
1. swivel chair work is any work that requires someone sitting in front of a computer to do.
2. swivel chair work is when you’re having to swivel your chair from one screen to another. This requires swiveling between applications to complete your work.
3. swiveling the monitor between customer and retail sales associate to collect inputs.
When you’re referring to replacing manual tasks with an automated process, are you referring to 2 above?
To be honest I have close, non-IT friends working in the corporate world who are scared of UIPath and what it could mean for their jobs going forward, but, again, those friends are not HN-ers.
A corrupt country with plenty of laws but which are laxly applied, it offers enough freedom and opportunity to still allow innovation and creation.
While the old, Western Europe is busy making up rules and barriers against much envied high-tech US successes, in Romania the American dream is still alive. While unions and never ending worker rights suffocate private initiative in the West, in the East meritocracy is still a thing (when not subsumed by corruption).
And while the West sees the Internet as a dangerous medium that must be reined and brought under control, at the edge of the Empire it is still seen as a Wild West, a land of opportunity where anybody can stake his ground and make his money. Sometimes that means scams and malware but sometimes something good may come up.
Because you can't have one without the other - you can't have reward without the risk. The more you try to control, the more you try to pacify, the less success and peaks you have. The more rules and regulations you impose, the less innovation and creation you get.
Taxes are so heavy in Germany, it makes more sense to not work under a certain income limit than have a small side-business if you can afford it.
Of course, there are also a lot of disadvantages of living here, but it seems like while we're getting closer to Western Europe's standards of living, we also lose the advantages you speak of.
And about freedom, I also think you're right. I've travelled a lot and I'm pretty sure we have much more freedoms in Romania compared to the western part of Europe and most of the other developed countries outside Europe. This also comes with its ups and down though.
What you'd normally glue together using code, in no-code environment you just emulate a human clicking at things.
I guess the more no-code startups we see out there, the more stuff for gluing by RPA in the future.
If I had to choose between Tetris and UiPath...
I then tried to view the article again and then the pop-up appears again with different wording, letting you know it is actually a paywall, so creating an account isn't enough.