I spoke with the founders of the startup ElectroNeek: Sergey (CEO), Dmitry (CIO) and Mikhail (CTO). At the end of the interview - a video where the robot is being assembled live.
- Dmitry, please send a photo for the KDPV, where you are all together.
- Believe it or not, we haven’t met so much in two years yet)
ElectroNeek develops an ecosystem of software products that can be used to create robots that repeat any actions of office employees at a computer with any applications that are installed on it. Thus, it is possible to fully or partially robotize the processes in the company. ElectroNeek specializes in working with system integrators and IT teams creating RPA competency centers, in other words, their products are intended for those who develop robots in large numbers, and do not solve several specific local automation problems.
RPA (Robotic Process Automation) is a technology that helps automate daily, repetitive tasks. RPA allows you to literally emulate the actions of a regular user at a computer. You hovered your mouse over the button and clicked, then entered the text with the keyboard and pressed "Enter". This is exactly what RPA is. As demand increased, RPA vendors began to evolve their solutions to provide more flexible automation mechanisms. There are integrations with programming languages, with technologies like OCR, they are seriously thinking about introducing machine learning. Robots can now be launched simultaneously, on a schedule, remotely, etc. Case examples: one , two , three , four, five .
- What is a robot?
Mikhail: Robotization is an emulation of a person. A person can be emulated in different guises. You can physically. The robot walks like a human. The robot clicks on the monitor like a human. Typing like a human. There is never a complete human emulation. But the aspect of human emulation is robotization.
- Mikhail, Yandex hunted you, but you still decided to work at ElectroNeek, what is your motivation to work in a startup, and not in a warm guaranteed job?
Mikhail: When you work in a startup, you yourself are the smith of your own happiness, but in the company you are limited.
- Michael, how were you hunted?
Mikhail: By that time, I had already left Akronis for a year, I stopped seeing my vector of development, I wanted to study different technologies, did pet projects. I wanted to do something of my own and I was looking for a team. In the meantime, Dimitri and Sergei were looking for a CTO and threw a cry at their acquaintances. I was familiar with Dmitry from the university, although we didn’t communicate much, so we got together. I was ready for this proposal.
I needed to understand whether I believe in the project or not. We met with Sergei in a cafe, he very superficially described to me what Electroneek is, and after the meeting I independently studied the RPA topic in more detail, looked at the competitors.
We phoned again, already three of us. Sergey and I were sitting next to each other, and Dmitry was in America at that time. We talked about the product, how they see it, where they plan to develop, for whom it is, how we will stand out and why there is “one more robot constructor” on the market.
I saw that there is demand, at least in Russia. Dmitry spoke about the global market, in particular about the United States. He previously worked at Ernst & Young and ran RPA for Fortune 500 companies there, so he had a good idea of the demand.
Sergey and Dmitry decided to differentiate themselves from competitors with a simple and convenient UX, to make robotization more accessible for companies of any size. I needed to know if my potential co-founders understand what the interface will be, what exactly is its coolness. I heard the honest answer "We don't know." The guys at the moment did not know what exactly should be, but they planned to try and find out.
Such honesty and openness was important to me. I liked that they were honest about the situation. This is important for future relationships. To say everything as it is, and if a person is adequate, he will understand. When you are honest, if a jamb comes out somewhere, you can immediately look at how to solve the problem, regardless of who messed up.
- What did Electroneek look like before you joined the project?
Michael:Before me, there was a working prototype that could be shown. It was a project on GitHub to show what they are about to do.
When I arrived, they showed me a prototype, told about the competitors, about the tasks that needed to be solved and asked to do well . Not on the knee, but for a long time, so that it can be developed. But there was no time to sit for a long time to develop, it was necessary to go into battle faster. It was necessary to run to clients, it was necessary to attract money. Therefore, from the first days I started writing code. I was already familiar with Electron at that time. (Electron is a framework that allows you to write desktop applications using a web technology stack.)
- What makes the development of an RPA product different from the rest?
Sergey:What is the difference between the development of an RPA platform and a product "in itself"? RPA platform, in particular ElectroNeek, is a development tool. A means to create something by interacting with something third. This is not a separate product like CRM, which in itself and only sometimes through the API interacts with something else.
A user based on ElectroNeek creates a software solution (robot) that will interact with other products that are constantly changing: browsers, desktops. You do not control the environment with which the development result will interact. This imposes enormous demands on quality, on UX, and on the development of product solutions.
- Why another RPA product on the market?
Sergey:people often come to us and say: "Why are you developing when you can go to some website, download a ready-made RPA clicker module and make it?" Yes, he can open a notebook, get comfortable with an Internet explorer, open Google. But as soon as you go further (as soon as XPath or selectors appear), different variants of sites, government or SaaS ecosystems, you will face the fact that it is not ready and does not work. And then, if you are developing your own platform, you need to adapt to the changes, and if everything is already hard-wired, then you cannot flexibly adapt to the changes. We had it on the pilot.
- How did you choose the technology stack?
Michael:The project implied that there would be both a desktop and a web-part, a classic front, a classic back and a desktop application. And in the beginning, the project did not involve a large team. I understood that the first few months I would be alone, we did not plan to expand at a grandiose pace.
I needed to provide some kind of multi-station, so that 1-3 people could do everything. That's why we chose Electron. It allows you to write a desktop application, backend and frontend in the same language (we have it TypeScript).
In the future, you can make specialization, but at the start it is very convenient when everyone can do everything.
As a rule, there is a problem of switching the context from the backend to the frontend. For example, backing in python, front in JavaScript, popular combination. And even if one person combines this in himself, it will be costly and difficult for him to switch from one language to another. And when you solve one problem, you switch often, it's not convenient. We got rid of this, nothing changes when switching: one language, one approach, even everything looks the same.
Then I looked for libraries that can immediately close some of my tasks, and did not try to write everything myself.
At the start, you don't need to try to bike something. Take ready-made if it suits your requirements. Perhaps then you really have to pull out this piece and replace it with your own. But at the same time, you will immediately have a working piece.
I took a ready-made library for visualization. Our main product is a development environment, and there is a flowchart visualization. Naturally, I did not write it myself, but took the open source joinjs library. It allows you to work at the svg level. Draw interfaces using vector pictures.
We have been sitting on it for a long time. Sometimes we think we will get rid of her, this can be done at any time, but so far she is performing all the tasks and holding the load.
It is important to write everything modularly so that you can throw out some piece and not get confused in your own web of code. A modular approach allows you to quickly get rid of libraries.
Our program is not just a flowchart editor, it solves a specific problem - it automates the desktop. You use it to manage desktop applications.
An important part of our program is a low-level library for interacting with applications, how to press a button, count a picture, create a screenshot.
I took the standard C # library UIAvtomation, which was also used by our competitors at that time. We have recently replaced it with a more modern one.
This library had a wrapper, a rather narrow API that we used. Then we were able to throw out this library, attach a new one and glue it with an adapter to this API. It quickly and painlessly happens, and it should be done.
- How were the features implemented?
Mikhail: I talked with the co-founders, they had experience in integrating a competitor's solution, they understood what features were needed. They gave me a list of features they used a lot. I began to make them one by one.
Literally a month or two later, we started doing a pilot project for the Russian Post.
We have solved the problem of unloading automation for them. They had a desktop HR application for resume management. There was no interface, and you had to get all the resumes out of there. There was no API, no database, and they couldn't pull them out.
We just clicked this app, scraped the data from there and put it on disk.
The principal solution was not difficult, I wrote the algorithm in a few hours, but the devil is in the details. A lot of nuances: documents of different types, some types of fields may not exist, etc. I spent some more time on finishing.
For each feature, I asked myself what solution I need now so that in the future I can solve problems of this kind. If a feature passed this filter, I added it. At the start, features are added without much discussion. The codebase is small, added, tried, removed, it's easy.
When the application is already large, each feature needs a discussion. What will the feature affect, whether it breaks something, and whether we have another way. At the start, it is easy to saw features, they do not break anything, because there is still nothing to break.
- What was the scale of the work for the Russian Post?
Mikhail: The application contained all the employees of the Russian Post throughout the country. It is impossible to shout it with your hands.
What our robot was doing. He entered a search with empty filters. The result is a list of all employees with scrolling across several screens. You need to click on each element of the list on the sheet, a window opens, there is a part of the data and several buttons that open other windows. All the windows had to be opened, all the data had to be stitched together, the windows had to be closed back and go to the next item in the list. And with such iterations to steal everything. Here's a rough summary of the process.
The pilot was mutually free and we did not bring it up to the state of production. For ourselves, we made a proof of concept: on the platform you can solve such and such problems, you can go with this to raise money, you can sell to customers and finish on the go. This is what we began to do.
- How did you attract investments?
Michael:We needed a working prototype that would impress investors. The interface of the solution for Russian Post was not pretty, it was made by me, and I am not a designer. I made for myself, IDE WebStorm Dark mode.
The early stages of the
ElectroNeek prototype in 2021
Investors know how to use imagination. You can show them a crooked prototype and tell them how it will change and they will understand. The prototype may even be buggy and buggy, but the main thing is to show a grain of meaning so that the investor can grasp the essence. Clients need to show a ready-made and beautiful product. Adequate people understand the difference between an MVP and a final product. And it is better not to work with inadequate ones. You take investors for a long time, it is pleasant to work with adequate people.
- What were the demonstrations to investors like?
Michael:Let's say I wrote a new functionality, and tomorrow morning it needs to be demonstrated to investors. I understand that it cannot be shown in this form. Maybe something is plugging in, maybe there is no good example to show the functionality. I sit there finishing at night, coming up with examples, catching bugs so that it looks good in the morning. In the morning I come without sleeping for the demonstration. I show the product to investors. Almost without sleep, but successfully.
At first, there is no way without it. There is no normal development process when there is a full-fledged dev environment, test environment, standings, production. There is only one environment, it is for you both standing and production. You are the only one and your task is to do it faster. And you work as a surgeon who just got ready for the operation and "opened" the code, and they say to him: "Well, let's sew it up faster and let's go."
I had to do everything and keep up with it. As long as the application is small, it fits well in the head, a good developer is able to do everything himself and not miss anything. When the application grows, it is no longer possible to do without QE.
Sergei: We had limited resources, we received only 150,000 dollars, of which 70,000 came in cash. This was all that was needed to finish the prototype to a normal product and show the first sales in Russia and the USA. Then they raised $ 0.5 million. We showed fast sales. Investors believed in us.
Michael:As soon as the money appeared, they began to expand the team in order to make a good product as soon as possible. What does "good" mean? You don't need a perfect product early on, although it can be made. This is mistake. Many people know how to do it perfectly, but it takes a long time. If fast and good, then too expensive. Everything is impossible at once. Accordingly, it must be done well enough here . Good enough to sell.
You can create a product with bugs, if they are not critical, do not shoot in the leg, and you can add features faster. People buy a product with a bug, they see a bug, a report about it, we fix it right there. People see feedback. There is no problem.
- How do you hire developers?
Michael:I focus more on ability than experience. Experience is important, but development is something where you constantly have to learn something. When you have to drag a new library into the project, the likelihood that you know it will not be very high. Basic knowledge is important. We needed knowledge of TypeScript, it took a long time to retrain into another language. The framework is desirable to know. We are using from Angular.
It is important for us that a person can quickly solve a complex problem without errors, or with errors that are easy to fix, which will come out during the run. A person should be able to think through a lot. If he is able to think through a lot, to understand what kind of corner cases there are in general, then this is cool.
It often happens that people write a program, but they simply did not think about some cases. And who will he think of them? QA may not think about them either. And then they shoot. At the same time, the initial data is enough to predict these corner cases. For me, this is the difference between a promising developer and an unpromising one: how many corner cases at the start he is able to anticipate.
- How many people are there now?
Mikhail: Six people - core development, who make the platform directly. Four people who are onmake the platform reusable solutions. They use the platform, plus additional tools in scripting languages, and make specific projects. I'm just talking about developers now. There is also a QA department, a separate product team.
- How did you move from coding to managerial responsibilities as a CTO?
Mikhail: After receiving the investment, I was actively writing code for several months. Although we hired QA, I was not particularly sure about them. I wrote the code review myself.
Then I saw on the kanban board that I was a narrow neck. And I understand that it's time to let go of the reins, to accept that problems will pass me by in production.
I reviewed the most critical things. Began to rely on QA. It was a gradual process of letting go of control. When you pass everything through yourself, you are sure of the result. You see everything, you can catch all the problems yourself. But this is not a scalable story. She is good at the start, then you need to get rid of her on the sly. So I gradually let go, reviewed only critical places, and then stopped writing and reviewing altogether. Now everyone is doing it without me.
- Now you have come to terms with the drop in quality, what's next?
Mikhail: Look, I no longer have the option to review the code, we have already gone through this. What else can I do? Now you can adjust the process things.
Let's say the developers merge not very high quality features into the main branch. Probably something is wrong with the review. We'll see. You watch what people are reviewing. Aha, to draw the attention of the guys to this. You go to the instructions. Debugging processes. Looking for weak points. You don't try to do work, you create processes.
This is where the developers review, but the features are still not very merged. Let's add a feature test before merging it. Added. What happened? Now QA does not have time to test them. Okay, probably not all features need to be tested in this way, but only the most dangerous ones that affect the entire project. You are balancing
There is no template for different companies, but the general approach is the same - to test your system and procedurally fix bottlenecks. Then it is already a scalable story.
My task is to find the bottleneck where the process problem is, talk to people and implement a working solution.
Ideally, if I step aside, then everything works. It’s impossible at the start. Step aside, everything is broken. And now it should be that I walked away for a month and nothing broke.
- How to understand when to hire a special person?
Mikhail: Is there enough for this narrow neck of a man? If a person is at least 70% busy with this task, then you can hire. If you need a person 5% of the time, then you probably can handle it yourself.
- What are you doing now?
Mikhail: I am still in charge of the processes. And I will deal with them for a long time.
I am discussing features, like Sergey. This is where our product grows. He passes it through his own prism, me through mine.
We are developers writing a developer tool. I am not able to keep track of all the features that we do, but I analyze important, complex, critical or interesting ones and give feedback to the product team, which, taking it into account, will optimize the feature. I am not in the business of describing, but listening to what they are going to do and giving feedback. Sergey is doing the same in terms of features. This is something that we will definitely not let go of. It is important to understand where the product is moving, where we are developing it.
- How do you study?
Michael:First, I state the problem clearly. Life experience already allows you to decide a lot. I already know much more than when I graduated from the university, but still there are problems that I do not understand how to solve.
First, I figure out what the problem is. Let's say I don't have some kind of tool. I google, watch YouTube or some course, find out how professionals in a particular field do.
For example, how do you test large applications when there is a lot of manual testing? We don't have time, what to do?
If you are not a cool QA in the past, then you indirectly understand what's what, but you may not know some nuances. I open YouTube, listen to an hour-long QA lecture with many years of experience, I understand that what I have heard can be applied, I try, I analyze. If it fits, I leave it.
It is impossible to know everything. The task of any manager is to learn everything that is possible, to delegate and in such a way as to retain the control function.
Set the framework in which people work, and control the result within this framework. They make decisions on their own.
If there is a problem on the market, the decision can be made without me. QA says that the task is critical and may decide to roll back. I don't need to wake up for this. The main thing is that people understand the framework.
- Advice to yourself in your youth?
Michael:At the start it seemed to me that at first I had to learn a lot. Something I don't know yet. I can't write a website, I can't write a backend. I wanted to first take a course or finish a university. Not really. Take it and try it. Google is a great tool, everything is there. Solve problems pointwise. You do not know how to do it specifically, and learn to do it specifically . You do not know how to configure nginx, so study this specifically.
You can't learn everything. It's too time consuming to take a multi-week programming course. Better start programming. Those problems that will arise for you, and solve them. It's faster this way. And even more immersed in the problem than reading a book. If you read 600 pages from cover to cover, then the knowledge will be superficial. Knowledge is deeper on experience.
I "discovered Google" in the sense that I can, with my knowledge, do complex things, google, and find point solutions for plugs. This is how I developed in the future.
I read books selectively. When I was solving a problem, I found a fragment that describes the solution. Articles are the same. You can also not watch the lectures in full. Lectures are for 4 hours. Find the time code, just look at the interesting part, it may be enough.
- Tell us about Service Organization Controls (SOC)?
Sergey: If you want to create a SaaS application in the American market, especially something that will work in companies with more than 200-500 people, the question immediately arises about SOC (Security Organization Control). While you do not have him, everyone asks him. This is a story that combs the policies of the organization, the distribution by the level of rights and access, how to design the code, auditors come and check.
Until you have it, all normal clients ask for it and do not sign the contract. As soon as it appears, and you say “here we have it, if you want to send a report”, clients answer that it is not necessary, “we do not want to read the report”.
It takes four months, is put in order, and is being checked. A set of activities that affects the entire technology stack. Michael can tell, he drove this process completely.
Mikhail: We are an organization that provides service to clients. SOC is about what tools we have inside us to ensure the safety, availability and continuity of the service and the safety of data. All those things that interest large clients and little interest for small organizations.
If our client is a large organization, then the lack of SOC may be a problem for them. Their regulations do not allow working with you. Therefore, at a certain moment it surfaced for us.
Either you have this certification, SOC (it is still expensive for a budding startup), or the company sends you a multi-page questionnaire on how you are safe. You read it and you don't understand half of it.
You can fill it up for a long time, because right off the bat it is not always clear what the speech is about. Plus, while you fill in, you understand that we do not have this. And this is not the case. And this is not there either. And there is no point in sending this questionnaire. And it seems not so difficult to make these things happen. But this must be done.
At some point, we realized that such clients come to us, we fill out their questionnaires for a long time, but as a result of the transaction there is no. We decided to deal with this issue.
This certification is a monitoring, ongoing process. Not that you did it once and that's it. You have to put down some kind of "checkboxes" on a regular basis. Your data is always encrypted during transmission. You have data that is always encrypted on the servers, in case it disappears somewhere on the hard drive, no one will pull anything out of there. There are many such examples and more sophisticated ones too.
When you start googling how to do this, you find a 60-sheet A4 sheet, what to do and how to do it. And each point needs to be disassembled, because you do not understand it. It looks like a very long job.
Okay, this is the way we will go for a long time. Or maybe we can find a company that will make our life easier? Our company. At that time, we were already at Y Combinator. We asked this question to the guys from there, we were prompted by YC alumni who will automate this story. The service is not free, but we bought a service from them. This is some kind of admin panel into which you integrate all your services. JetSuit, Bitbucket, Gitlab, Jira, AWS, Azure, who has what. The program itself learns where you have what settings, and says what and where you are missing. You correct it pointwise and all items in this sheet are automatically closed.
After that, an auditor is invited, who confirms that everything is really there and sets a "test". This is how we simplified our life.
For large companies, this is a formality, without which they could not go further and cooperate with us. Well, as a plus, a real increase in customer safety.
- Tell us about Y Combinator through the eyes of a developer?
Mikhail: I didn't really understand what YC was for. It was clear that this was prestige. And the specific goal was hard for me to understand. I read about how it can be there. It was hard for me to imagine what kind of useful experience one could get there. I was quite skeptical about the fact that I would improve as a professional. But I understood that this was a useful milestone for the company as a whole.
If we talk about the result. We got more business benefits. They also helped with technical resources and are still helping. We made a more correct infrastructure in the cloud.
The main takeaway from this story is that if you are ready to use the products that YC provides, ready to delve into their understanding, then this will be a big plus.
We finished YC in March 2020, closed the round with $ 2.5 million. Significant growth of both the development team and tasks began.
- How did you come to the current product team?
Mikhail: Our products are quite complex, you need to be a developer to understand a product for developers. You need to understand from the developer's point of view what features to implement, how our clients use them. On the other hand, it is worth being a good businessman, a market researcher. Combine all these competencies. There is some difficulty with this.
Sergey:Over the last 4-5 months from March to August, we first hired one product manager who had experience in RPA. We worked with him for several months and did not get any results. We didn’t hire a product manager from the series “We will hire you and gold will immediately pour out”, we wanted to come to a clear understanding of what features we are doing, they are needed to capture the future market, to solve specific client problems, for upselling. We took the product for quite measurable metrics and discussed it. Unfortunately, both products were rolling. This is our fault too. We hired people who offered to make the feature, "because it's beautiful." How much money will she bring? Well, it's hard to count ... Who will she help? How can it help you win current trades, or at least not lose them? We didn’t manage to build such a story.
What did we end up with. A super comfortable scheme for us, it drives our company very much.
We have a UX product manager, a technology product manager, we have a Head of Engineering, we have a CTO, and we have a CEO as a business representative. We have formed a grocery office where the product is “cut” into different parts. UX, analysis of new features, engineering. Mikhail and I play the role of facilitators in the case of prioritization. I am also responsible for sales features. Dmitry looks at how product features translate or can translate into marketing opportunities and tools such as our global library of bots created by customers and partners.
We have spontaneous sessions to discuss serious issues. We also have a weekly hour and a half call where we plan the next sprint, which has already been prioritized within the company. New features fly in on three tracks: bugs - we fix something that doesn't work, slows down the sale or interferes with current customers; UX - we fix the current one, because we know that the product can always be improved; we add something new to the product, which will allow us to be more effective in the future. We work in such a framework. We would like to come to one person who is involved in the entire product, but so far it seems to us that it is difficult.
I would like to advise future entrepreneurs, especially techies, not to try to consider only one option (that the CEO must find a product owner), but that there is a distributed interaction format that gives a result.
- Is it possible with the help of your robot to farm in computer games, clicks in YouTube?
Dmitry: At our base, one client made a robot that turns on the kettle.
Sergey: The robot can press any button. We give a development tool. What clients build on it is on the responsibility of people. You can build anything you want.
Sergey:We had one story. The client bought the service, and then wrote: “I specifically chose the most undeveloped girl in the IT direction in our company, Olya. And so "Olya" was able to create a robot with the help of ElectroNeek. If "Olya" can do it, then anyone in my company can. I'm buying a product from you! " This is a high indicator of ease of use. Although mostly junior or middle-level developers use us. They receive a product, in any stack (web, desktop, is there an API or not), create an application (a robot?), This is the freedom that our product gives.
Dmitriy:When a product gets to investors at an early stage, the story with Olya was repeated there, there are Oli among the investors. There were situations when partners of top American funds got into the product (Gary Ten from Initialized, a former YC partner and investor in Coinbase and Instacart). The partner began to assemble the robot with his hands.
Bonus: collecting a robot live
Read more
- Launch HN: ElectroNeek (YC W20) - Automatically find and automate routine work
- How four Russians created a digital employee factory and earned $ 1 million from it
- electroNeek RPA - software robots help people
- About robotization of business with Farida Roslovets and the director of the RPA company electroNeek