The Rise

Here is how we created a successful startup.

Doors were about to be opened

We had a dummy app, an idea, and determination. That was everything we needed to put our idea on paper and move forward. First, we needed to know how to connect mobile phones to doors, which seemed hard for us at the time. Some research led me to a weird thing called Arduino, an open-source electronics platform that allows us to interact with the physical world, read inputs like light sensors, and provide an output, like blinking a LED or send a message through the internet. We could prototype hardware with a sensor and send commands using our mobile phones using Arduino. We could use Bluetooth for that. For some reason, we didn’t like Bluetooth, we just thought that BT wasn’t going to work, so we decided to use NFC. NFC was trending, it was a new technology, and we saw many opportunities. Contactless payments like it’s common today were not common at the time, not everyone used or even knew about them.

Our focus was on NFC. We should have an app installed on our compatible devices to open our door using NFC. I was still working as a trainee then, and I had some money saved. I bought everything we needed for a prototype:

• Arduino
• NFC sensor
• Some LEDs with different colors
• A relay to open and close the door

After reading some documentation and tutorials, I built a simple prototype that worked with a mobile phone and contactless RFID cards. We had a master code on the mobile phone or on the RFID card, which would allow us to add or remove mobile phones and RFID cards. After tapping the master card onto the sensor, the Arduino program would wait for another card or phone to send a code. If the code existed, it was removed from the Arduino and would not be allowed to trigger the relay. If the code did not exist, it was added to the whitelist and would be able to trigger the relay to open the door. Well, everyone, we got ourselves a door controlled by mobile phones!

The prototype was really simple, we knew it wasn’t near production-ready and commercialization. But we wanted to go further, of course. We needed good people on the team, an investor, and luck. Opening doors using mobile phones was new, but it wasn’t game-changing. What if my phone dies? Do I need to break out of my own house? My phone does not have NFC, what do I do? What if my electricity fails or I do not pay the bill because I forgot? It wasn’t the safest solution. We realized we were dealing with people’s safety. And it comes in the first place, I wouldn’t sell a product that harms my client just because I can make money from that. I wonder if anyone is capable of such cruelty…

We started studying access control systems to understand how the industry deals with safety. What were the good practices for that? To be honest, this study didn’t last long since we were constantly trying to improve our software and hardware. We paid for a professional to build a mini-door for our showcase. It was almost a meter in height, with a door handle and everything. We installed a magnetic door lock on this mini-door and connected it to the relay on the Arduino. When we wanted to show our prototype working, there would not be only LEDs blinking and a buzzing sound, we would see a little door opening and closing. Sweet!

The Trade Fair

The college offers a class for people who want to start a business. It’s divided into two classes. You can take the first beginner class and in the next semester, you can take the advanced one. Students had some deliverables during the semester to get a final grade at the end, but they also had a Trade Fair, where they exposed their products, and professors would grade them. Other people could participate in this fair, even not taking the classes. We needed to fill out a form and provide some documentation to be able to expose our idea.

We followed the protocols to get into this fair and expose our little door that opened using a mobile app (we called OmniKey, great name, huh? Catchy…). And the fair was better than expected. Our stand was really good and everybody came by to see our mobile phones opening the little door, even the professors who were supposed to grade the students spent some time chatting with us, giving their thoughts. But there was one special guest at the fair… There was this well-suited man who came by and was really impressed with our modest solution. He said his company was one of the sponsors of the fair. Nonetheless, his company offered access control solutions for his clients. Well, he bought access control solutions, and then he offered them to his clients, he didn’t have his own solution. And having your own solution can reduce costs. And increase profit. He gave us his card and asked us to reach out to his secretary to schedule a meeting.

That was it. The first demo of our product (not even an MVP) already had a possible investor and partner. In our first fair. What were the odds?

The odds

The meeting with this possible investor was scheduled. We spent money printing some business cards for each of us so we could give them like real businessmen. Each of us suited well for the meeting, and of course, we brought the mini-door. The guy was the CEO of this company and was a big one in my city. They had important clients with important business to hold. We made a live demo of our product to the guy and some partners he had in the company. They liked us and liked our product. They asked some questions and we confidently answered them. We went out with a handshake and an investor.

After some days, we officially opened a new company for the still called OmniKey with our investor as part of it. He provided us with a 100-meter squared office in the Technology Development Center of the University of Brasilia (where my business partners and I studied as well). It was great, we would study in the same place where we would work, in 5min we could be in a class, and 5min after class we would be at work. We studied business, went to business fairs, lectures, and talks, and read articles, blogs, and everything we could to learn how to run a business. We also needed to study technology and improve our product. We needed a beautiful design for our app, site, company, and so on. Did I miss something? Oh, right, we needed to study for college classes and exams. We needed to lure clients. Also, we need to…

So much work to do. That was probably when we started to drink a bit more coffee :coffee. We were applying a custom Pomodoro technique. Each 25min working, we would spend 5min drinking coffee. Things were intense, but it was working. Some weeks later and a lot of caffeine, we had a prototype of our MVP. It was an AngularJS frontend application so that the user could see real-time access. The user could see reports, schedule permissions, and create, read, update and delete some entities like people, cards, groups, and so on.

The web app was good. The mobile app was good. The hardware opened the door for allowed users. And the backend stored data. What else did we need? No, not unit tests, neither e2e nor coverage tests. We did not need continuous integration and delivery. We needed clients. The software was great, look:

• I can access the web app and create a new user
• I can create a new access device for this new user
• I can choose if the device will be a mobile phone or an RFID card (how cool is that?)
• The user can open the door after tapping his new access device
• I can see in realtime the time and direction the user went in the web app

I mean, it works… Right? My customers will be able to open their doors and see their access reports. We’re good to go then.

The feedback

Our investor was happy with the results, but his company was supposed to sell solutions to companies. We ended up focusing on a more generic solution, which was fine, it was an MVP. But we didn’t focus on a niche. The investor provided a mentor, a really good mentor. He was a true storyteller and a seller (storytelling is a prerequisite to being a seller, isn’t it?). He taught us many things, and we saw that our MVP needed a bit of work to be an MVP dedicated to companies. The actual state of our product would not fulfill a company’s needs thus we wouldn’t have possible clients. We had an idea of what Scrum was and what Agile development was. We wanted to adopt better practices in our process. We tried to act like a real company for real customers. And for that, our investor gave us feedback asking us to focus on companies needs and to learn and follow the mentor’s advices.

One of the things we did was a rebrand. We imagined that our products would interact with the environment to produce data. We were hyped with the Internet of Things and wanted to take advantage of our access control to control more things. Cameras. Lights. We wanted an ecosystem of corporative automation. We chose the Monkey concept for our products (before NFTs made it cool). Each of our products would be a different monkey. The first product, the access control, would be the father. After all, it started everything. So it would be MonKey and not OmniKey (you see how Key is essential in modern access control systems, right?)

We refactored our MonKey system. Entirely. It was beautifully architected. We had low-level, mid-level, and high-level levels (other important keyword right here. Got it?) And each level would have someone responsible for that because it was their expertise. For myself, it was low-level. I was the hardware guy who writes C code to read an array of bytes, apply some verifications, turn digital ports on and off, blink LEDs, and open doors. Oh, and connect the hardware to the internet so we can send HTTP requests. The other guys are the mid-level guyand thehigh-level guy`. They were good developers. I believe they still are.

We implemented some sweet features, like DB syncing between low and mid, sockets sending events to the frontend, asynchronous operations, and a multithreading server (so cool, it gives me chills). We had git repositories for them, with branches and merges and all those cool git stuff. We did not have tests, of course. No one needs them anyway. Why would I implement code to test my code? LOL. But we had a fancy building process in low and mid codebases. Not automated, of course!! I am the one who wants to run my build command and wait 10min for that, so I can deploy it to my hardware and manually test my code. The mid guy also liked that, so… It was unanimous. No automated tests, build or deploy. We don’t need them.

By the time we were improving our code, the manager guy was learning business (he was the one in charge of that), learning how to sell, and getting great advices from the mentor. He subscribed a new project concept to an auction. The project was different from the doors project, it was more ambitious. And it was another monkey. The project was Mandrill, a web app video monitoring system with fancy features. We won that auction and got some money to execute the project. We got R$200,000.00. It’s a lot of money. Just for us. To build the project.

We used the money to hire some people. After hiring everyone we needed, we were not 5 anymore. We were about 26 to 30 people. Designers, managers, developers. We had big whiteboards to write on. We had white wallpapers to write on. We had poufs to relax. We had coffee :coffee:. People were divided into teams, each team responsible for one specific thing (we started having a better company culture). We had the hardware team, we had the frontend team, we had the backend team, we had the design team, and we had the management team. Things were pretty different. We got very productive (still no tests). We built software fast and things were really working.

First MonKey door

Actually, there were 2 first doors. The first was a prototype of the prototype. The same thing we showcased in the Trade Fair was installed in the Academic Center of Computer Engineering at the University of Brasilia. The last time I was there (a couple of years before the pandemic… there’s some time) it was still being used to control access to the management room in the Center. The first MonKey, actually, was installed in the Technology Center, where we worked. We had a custom ticket gate with our hardware, which controlled the directional twist of the arms, and of course, LEDs blinking and buzzers buzzing. We installed our custom server in the IT team server’s room. It worked with a Raspberry Pi. And we deployed our C++ code into this server. The server was installed in the same local network dedicated to the access control, to which we connected our hardware (some doors and the ticket gate).

Our team installed everything, and we worked hard to deliver the best experience possible to the users. We were excited to have our product shown to the world. It would be the first case that could be presented to people, and we could grow. That’s what we thought. And actually, that’s something we were really capable of. But I’ll leave this for later.

The other monkey

We had a team dedicated to delivering the MonKey, it was already done and in production on a client. The other developers and designers were focused on the other monkey, the Mandrill. This was an ambitious project, and everyone was excited. The success was in front of use. We had recently installed our first MonKey that would bring us more money and visibility, we could hire more people to focus on the Monkey and move forward with other monkeys. I didn’t directly work on this project. There was nothing much for me to do since there was no hardware involved. The cameras were connected via ethernet, and we could stream its video using libraries and stuff like that, nothing to control physically. And we needed someone in charge of the MonKey next steps.

This new project consisted of two different products. One would be a video monitoring system for companies because our investor sells to companies, so it was obvious for us. The other would be a VMS to the city, called Mandrill Waves. It involves getting images from cameras around the city, analyzing its images, and providing feedback. Car accident on the road? Notify! Robbery? Notify? Assault of any kind? Notify!!! The government was the focus of this project. Citizens would be able to see just specific cameras, with tons of filtering on them, to avoid them from seeing sensitive stuff. But if you want to see the traffic to your partner’s house, it would show almost realtime to you. Maybe you can wait and go later, I don’t know, keep streaming, and you’ll see. The idea was exciting and ambitious. Did I say it before? We just needed access to a bunch of cameras and streamed them almost real-time in a web app hosted in the cloud.

Of course, the Waves project was never initiated. I don’t even know if this is viable or if there’s a similar solution available in the market. Or if governments already have those services and big techs provide them. Who knows? Our focus was on the regular VMS, it was easy to sell, and we could integrate with access control systems, but just one system. Ours. Cool.

When too many monkeys are on a weak branch

If you have a strong branch, you can put some monkeys there, and it’ll hold. But if you put on a weak branch, it may break, and the monkeys will fall to the ground. Poor monkeys. You need to be confident enough to know if your branch is strong enough to put the monkeys, it is not responsible for putting them there if you know it’s not safe. After months of working on the Mandrill VMS, it turns out to be a beautiful software. It was the most beautiful VMS frontend that we have ever seen. And we saw many while studying VMSs and our competitors. It was so beautiful that the video we streamed from the cameras stopped to contemplate our design. And after some seconds the next frame comes and also stops to contemplate such beauty. I’m not kidding, our VMS product was not even near almost realtime. It just did not work. But the interface was great, I really loved the designers’ work, they were amazing. We had a huge failure here. The developers were great, they had those modules well designed (not tested), and performative algorithms. What was the problem?

It turns out that we did not go forward to investigate. The Mandrill team was not the team anymore. The mid and front guys plus another guy continued to work on the slow monkey. The others started to work on other stuff. Building websites for local customers. Yeah, that was our new thing. Websites. It’s not a problem to sell websites, and it just was not in our plans. We were supposed to build IoT projects. We started making software on-demand as well. Also, not a problem. It was just not in our plans.

The Mandrill was optimized by the 3 guys that were working on it. But it was not even close to being released to a customer. If something happens to someone on the camera, the security would have a delay of seconds to start taking action. And those seconds could be crucial for someone’s life. No, this was a deal-breaker, no more Mandrill. Both VMS and Waves.

When the weak branch breaks

The MonKey installation in the Technology Center was a fiasco. In a couple of weeks, we were requested to remove everything because it simply did not work. The ticket gate sometimes froze, and the web app was slow as hell. The security even left the access door open so people could avoid using the ticket gate. Looks like our awesome Raspberry Pi server, written in C++, and our well-designed AngularJS framework was slow. For some dozens of people. In a small building. Tragic.

Mandrill was stopped, and MonKey did not work. If we at least had a way to know if our code was working as expected, if there were a way to test it and prevent bugs, that would be awesome. Did I mention that our investor had won an auction to install our access control system (yes, the MonKey) on a big governmental venue? And that we built our own hardware using Arduino’s ATMega controller with everything we needed on a single board? And we also ordered a lot of cases and boxes for our product to be manufactured? Yeah, we spent a lot of money on a dead product. All garbage.

Our investor was not satisfied. We were not happy. Our employees were not happy (did I mention they were all my friends?). My associates and I were not satisfied and we were blaming each other for the company’s failures. It was horrible, and the morale was low. Big time.

Some people were fired, and others asked us to leave. From almost 30 people we ended up with 8 I think (5 associates plus 3 developers). We did not have money, but we still had hope. Our investor proposes the last shot, we could provide software service. His company could pay us to work as developers and consultants. He could participate in auctions to create software for companies, and we could focus on delivering the software. We could make good money, hire new people, start taking on more projects, and only focus on software. After getting more experience and practice, more money, and more employees, we could focus on our projects. We could invest money in research, everything in order to create products, as we wanted in the past.

The morale started to get higher. This was a new approach we could get, and in the meantime, we could study and become better engineers and product makers. And… Look that! The investor had the perfect opportunity for us! He won an auction to modernize the access control system of one of the biggest banks in Brazil. We had a deal, every R$ we made for this project, our company would receive some % over it. And guess what? We were familiar with access control and learned what to do and what not to do (did we?).