Sramana: Did the company go public?
Paulo Rosado: We were on the path right as the bubble burst. We were supposed to float on the NASDAQ, but we missed the window by about two months. We had to delay the IPO and it never actually happened. I left the company in 2001 with the idea of creating OutSystems, which we started in March of that year.
Sramana: What was the concept behind OutSystems?
Paulo Rosado: It was based on my previous Internet infrastructure company. In the first company we started working on a web application that was supposed to be deployed to thousands of users. Unfortunately, I was not able to finish the project on time and on budget. That irritated me to no end. We kept going back to try and figure out why those projects were so flimsy and so shaky. We tried to improve our requirements analysis until we could make it work.
Right after I sold the company I was thinking about the company and I had an epiphany that the approach to the problem was wrong. We assume that systems like web-based or mobile systems that have interfaces for large numbers of users can be defined correctly up front. These systems are then built in .NET or Java and they are ultimately systems that are extremely difficult to change. You have to make very strong commitments to architecture and coding. It is difficult to go back and make substantial changes to the program without creating a maintenance monster.
Our problem was that we believed the technology that we were using to create very large applications suffered from the fact that the systems were built using tools that forced them to be inflexible. They did not allow mistakes. That is why the projects tended to slide out. We built the prototypes and showed them to users, and in turn the users would provide a large list of feature requests, which dramatically changed the costs of the next change that was done.
The ideal of OutSystems was a paradigm shift. Instead of trying to do everything correct up front and praying that there would be no more changes, why not assume that everything we were going to do would be wrong. That would dramatically alter the cost of change. We adopted rapid application development paradigms where we designed an environment that was where we could accommodate fast, dramatic changes without breaking the system.
We also realized that change was very much dependent on the testing and deployment phase. In the second version of the platform that we released in 2002, we released a fully functional DevOps capability where we could stage and build an application quickly, stage it in QA and move it into production in seconds. Over the years we added all the other things that our customers asked for that make up our platform today.
We figured out very early that if you want to address the problems of speed, change, and flexibility, you need to have an R&A component paired with a DevOps component.