Rob Koplowitz (00:01)
Hi everybody and welcome to this week's episode of Low Down on Low-Code. This is a particularly good one, one we've been particularly excited about. Let's kick off with just a little bit of housekeeping. So for those of you who are out there listening, we come to you on YouTube, we come to you on any one of your favorite podcast platforms. Please hit the like button, please hit the share button. Help us get the word out because there's a lot of interest in this topic and we're small folks looking to grow our audience. So thanks so much.
for that. I'm Rob Koplowitz. I'm one of your co -hosts today. I go back a long ways in low -code, started my enterprise software career building Lotus Notes applications. I worked for Oracle. I worked for Microsoft. I worked for IBM. I spent a number of years with Forrester. throughout my career, I'd say I'd probably failed as much as I've succeeded. And probably my biggest failure was that retirement.
So I find myself back in this game doing research with my old friend and colleague, John Rymer How are you, John?
John Rymer (01:06)
Very well psyched to be here, Rob. So I'm John Rymer, a former Forrester analyst, worked at Forrester for about 17 years, worked as an analyst for about 25 years. And I wanna relay a little story that involves, that includes our guest today, Paulo Rosado, CEO of OutSystems. I was in the...
Forester office in San Francisco, we're winding down for the day, it kind of later in the afternoon. And I had a briefing with this company that I had never heard of.
and income named OutSystems and in comes Paolo Rosato. And Paolo, I think you must have been at the tail end of a very long trip around the world working with customers and because boy, you looked exhausted. And so we sat down, you remember this, and we sat down and Paolo and I was like, I've never heard of you. What is this? What is this product? And we sat
Paulo Rosado (02:01)
Yeah.
John Rymer (02:13)
and Paulo took me through a full robust demo and I ended up writing a report because I was impressed by what I saw as a way to speed up application development considerably. And two years later, and Paulo, after that report, Clay Richardson and I coined the term low code and we've all kind of never looked back.
So I thank you for that for that initial briefing, even though you were exhausted. You probably would have preferred a glass of wine is suffering my dumb questions. anyway, Paulo, Paulo, it's so great to have you as really one of the founders of this industry. And I'm sure I'm sure I don't know the whole your whole backstory, although you and I have been friends for a while.
Paulo Rosado (02:38)
That's true.
That was my permanent state at the time. So exhausting.
John Rymer (03:06)
But I wonder if you could just help us help the audience know, how'd you get into this crazy game? And where did it all start for you?
Paulo Rosado (03:19)
It started towards the end of the 90s, actually. My previous life, I had been building these massively large systems. This was back in 98, 97. And I didn't deliver a single project on time and on budget. And so I kept on trying and trying. I failed about 10 projects and then I decided to sell the company. I stayed working for...
another company for like 18 months, but kept on going back. What the hell? Why did we could not deliver? So I tried, maybe we were kind of, we were idiots. Maybe there was something that was evading us. Then actually what we, what myself and some colleagues realize is that we're trying to build projects the way you build bridges, which is you specify the requirements upfront.
And then you expect that the requirements don't change towards the next 18 months, two years for a mid -size large project. And in fact, that's an absolutely incorrect assumption. And so what we did was we thought about if changing something is so costly, why don't we assume that the requirements upfront are fundamentally wrong, that they're going to change. And we just concentrate on building
on changing something, either a platform or a process, that would allow us to decrease the cost of change by at least one order of magnitude. And that's what we did on the OutSystems platform was actually the inception of that fundamental first principle, which is decreasing the cost of change. We never expected that we ended up by fixing one of the fundamental problems in building software.
John Rymer (05:04)
Bye.
Paulo Rosado (05:13)
And then the platform ended up by being a result of us reverse engineering the fundamental four to six issues that increase the cost of change. One of them was the use of code. And so that's how basically the company started.
John Rymer (05:34)
Excellent. Thank you. Rob?
Rob Koplowitz (05:37)
So Paul, I wanna sort of start by saying, if you're an idiot, usually maybe we're idiots, you got a lot of company because we've heard this story before. It was a huge problem that you guys and others have set out to solve and the commonality of responses is kind of striking. Paul,
John Rymer (05:48)
you
Rob Koplowitz (06:04)
We talk to a lot of different vendors that call themselves low -code vendors, right? We'll go all the way from sort of simple situational no -code applications up through people who have come from maybe deep BPM type backgrounds. And these things are not all the same, right? There are certain applications that are really well designed.
to handle certain situations. And we kind of like to boil this down to, I'm an accounting Zach and I work for OutSystems and I've just walked into a new prospect. What am I hearing that says the characteristics of the process, of this prospect, what you are trying to accomplish is really what OutSystems is designed to do.
Paulo Rosado (06:54)
That's a very good question, by the way. Actually, when I personally enter and start having a first conversation with either a CIO or someone at the C -suite or even a VP of APDEF, usually what we try to... It's a good sign when there is a sense of urgency. I mean, we're talking about a platform that takes a project of about three years and compresses it to seven months. And we're talking about the previous version, pre -Gen .AI.
Right? So that attribute of speed needs to be something that's highly valuable because the thing is mission critical. The other thing that I really like is when the projects are already in the medium large to extra large. Because those type of projects usually it's projects that are sitting on the shelf because a big SI went there, did an analysis.
figured out we need two years plus, sometimes four years, 100 developers to 400 developers to basically just build this project. And we all know that a project that takes more than two years is impossible to deliver because the requirements change too much and it needs to be re -architected again. It's what we call impossible projects. We like those because we take a project of four years, reduce it to between seven months to 14.
John Rymer (08:05)
to.
Paulo Rosado (08:22)
And because we're very good at handling surprises given the focus on change, we ended up by delivering the project on time and on budget, even when there is a lot of turmoil in the requirements of the projects. And so we know that that particular use case, we have several others, about three or four others. That particular use case, we have no competition whatsoever. And we love doing that. that's fortunately...
I think companies, a lot of companies have reached a point where they have so many legacy systems that are in need of modernization and purely right to cloud to get new architectures because they have like these huge backlogs hanging on with not being flushed that it's a huge opportunity now for this type of approach. So that's where we
John Rymer (09:13)
it.
Rob Koplowitz (09:14)
Thank you, John?
John Rymer (09:18)
Interesting. So, sounds like, and I know I saw this even three years ago when I was at Forrester, OutSystems was really tackling some very large, complex projects. I'm thinking of the big worldwide logistics system that you guys were just working with Maersk on when I came out.
These, you know, many of these applications, these large enterprise applications, the conventional thinking was you have to buy them. You're going to go to SAP or you're going to go to Oracle, you're going to go to, you know, Epic or whatever it is, one of the big, you know, enterprise apps players that specialize in that area. And you're going to buy it because there's no way in hell you're ever going to be successful building it. But I wonder now if you're seeing a re -thinking of
build versus buy logic for these large applications? What are you seeing out there?
Paulo Rosado (10:22)
Actually, it's interesting because a lot of our customers, by the way, things are changing as we speak, And so that equation is getting more strenuous, the buy versus build, because of Gen .ai. But if I go back like one year, we got exactly that question from customers. mean, we've done, for instance, claims processing systems. That's a good example of something that is kind of in the gray zone, whether you should buy a package or you should build
What we find is that, what we tell our customers is, listen, if you believe claims processing, you'll never want to change the process. If it's a commodity, it's not part of your competitive advantage, maybe you should buy it. But be aware that when you design the the project, count how many change requests are within the RFP that you've created.
If it's more than 4 % it's already in the danger zone and if it reaches more than 10 % the project might not finish in time. And so what we tell our customers is if you want to buy something, buy something that you can deploy out of the box maybe with some extensions, with other tools but if you have to do large customizations you should build it. And
So everything that has to do with workflows around the portals and stuff like that, that's a no -brainer, because you should never deploy that as a package, because those things are hit with change so frequently that you have to have a platform that's dealt for very rapid internal change. However, what we've seen, we just recently finished, not us, but our partners, finished a huge policy management system for life.
customer. So we're seeing now there is another customer which is an hospital who's replacing CERN, a big HMS system with a completely bespoke system built in out systems. So we even got surprised with that. We go back, why did you guys do that? Because we're tired of having our nurse ward management system changes as we change the procedures of the hospital.
John Rymer (12:32)
Huh.
Paulo Rosado (12:45)
And it takes forever to deploy that in the digital system. So we started realizing what are the things we need to change, what are the things and almost everything we need to change. And so of course, this is a customer that has already built two or three systems. So they know this thing is mission critical. They can change it and whatever. But it's funny how they were able to reverse engineer a lot of the stuff with the processes they wanted, including like Manchester protocols and things that I don't even know because I'm not a healthcare expert.
and they built that thing in less than one year. It takes about two to three years to customize a package. So at this very large end, you start getting... The only issue is when you have a commodity, you don't want to reinvent the wheel, there's processes inside the software, then there is a reason to buy it. Otherwise, if you're going to already impose the way you work into the software, you might as well start with something like OutSystem.
John Rymer (13:15)
Yeah.
Paolo, you've been at this a long time. I have trouble imagining that the number of processes that are not going to change is going up. I think it's the other way around. Isn't even processes that in the past were fairly static, aren't they? Are you seeing now lots and lots of change even with them, with those processes that would tilt you towards
Paulo Rosado (14:00)
Yeah, the other way.
with it. I can tell you're absolutely right. Listen, for instance, something that was supposed to be a commodity, which was anything related to HR, like
John Rymer (14:13)
Sorry, build.
Paulo Rosado (14:25)
talent management or performance evaluation.
Like for instance, the performance evaluation workflows that used to be a yearly performance evaluation at the end of the year. Now, I talk with a lot of CIOs and a lot of VPs and even CEOs and they say, talent is at the top. We need to do real -time evaluation constantly. We need to almost have GNI kind of give us an idea whether there is a problem. We need to query the 360. And so they're talking about innovation
talent performance and evaluation. So we go back to Workday, for instance, which is the system we use, and we don't see that there. And so we've built that portion by extending Workday. So things that we thought were going to be commodity get flipped whenever the differentiators of the company shift towards another direction. And talent, for instance, has become one. One thing that we haven't seen change is probably general ledger. It's the only thing I've never...
John Rymer (15:27)
go.
Paulo Rosado (15:29)
But even parts of claims processing, for instance, calculating premiums, which is usually something you'd expect from a financial system, we've had several customs where the calculation of premiums is so complex and so bespoke that they moved it into out systems. And so it's always that dichotomy between whether it's a real commodity that's not going to change in the next 400 years or it's something that's going to change in the next three months. And most of the process you're right, they change in the next
John Rymer (15:58)
Right. Great. Rob?
Rob Koplowitz (16:01)
So, Paulo, I apologize. I want to slide in an additional question here as a follow -up to that, because you've hit on a couple of themes here that I think are really important for our audience to understand. You talked about massive upfront process, massive upfront requirements gathering, but the process is changing as you're gathering requirements. You mentioned I'm no healthcare expert, right? Well, the experts in how the business are run are embedded.
in the business. You mentioned where we find our differentiations, Workday is great, but I need to identify my business differentiators and build it on top as an extension. This is a fundamentally different way of developing in the sense that it involves
the business users and business expertise in a different way. They're much more involved in the process. They're much more involved in identifying opportunities and iterating within the process in a continuous improvement type model. Is that part of it? that a big part of where OutSystems differentiates from certainly from traditional coding?
Paulo Rosado (17:11)
I think that's the case. the thing that we see in things that change with people that embark on these processes for the first time is a shift in the way they evaluate risk. most of the professionals we deal with that haven't experienced this type of process
they come with an extreme conservative approach. so whenever they, especially when they're tackling the larger the project, the more buffer for surprises they put at the end of the project. And so things that could be done maybe in two years end up by having from the start, budget of three years and a half. And so what we tell them usually is, and this is a very important, we tell them, trust us that this thing is extremely predictable.
Not only we're going to deliver four times faster, but we're going to eat the date. I don't remember in the past 10 years, and that's true, I don't remember a single project that was delayed more than two weeks, two to four weeks. We talk about seven months projects that got compressed from two and a half to three years. And so why is that we're able to do this? It's because the capacity to recover is so fast. We have studied
Over many years, everything that can go wrong, like integrations that are not documented, data that was expected to be available, it's completely dirty, the data. Suddenly you lose half of the developer team because they go and start a startup. There's so many surprises that occur during a big project that we've managed to, over the years, kind of compensate for one. Integrations is a big one. Losing the sponsor is another
You know, and we recover from all of these India's secreties and surprises. So we're able to always meet the target. The first time it takes, it takes time until the practitioners actually realize, my God, I can, I can say yes. Yes, we're going to deliver in seven months. And say, but you, you haven't done a full analysis. I don't need to, because I can, I can do it as I show you more.
I show you the intermediate versions of the application. You as a customer, can give me feedback. We can change it together. The system will become very tuned to what you need, not what you perceive that you needed before we started. And in the end, because this thing recovers from surprises so fast, we're going to hit the deadline together.
When you think about that, relationship between business and IT changes dramatically. It becomes more of the business asking for something. And instead of always getting a no from the IT, what they do is they get a yes, but can I deliver in four weeks? And so it's always reasonable type of conversations. And the businesses get highly, highly involved and committed to the project, which actually
One of the side effects of this is that the change management deploying a large project, a new one, a new system, a new software system is dramatically decreased because the business is involved from day one. They see the early versions, they become champions, they become walking manuals. Whenever they are there, they kind of give you feedback. This UI is very difficult to use. Get this feedback and we change that UI in like two or three hours. It gets flushed and so...
The customers don't, the users don't even have time to become frustrated because things change and adapt so fast. So usually we have very, very successful projects that before were considered impossible.
Rob Koplowitz (21:23)
Thank you, Paulo. So I want to just take a moment for a quick commercial break. So for listeners, John and I come to you through analysis .tech. company is analysis .tech. If you'd like to engage with John, with myself, at a deeper level with Dave Marcus, with Ryan Dugan, Francis Cardin, or Andy Bartels, our chief economist at a deeper level, you can find us and all of our
John Rymer (21:24)
Thank you.
Rob Koplowitz (21:53)
in our research at analysis .tech. Paolo, when John and I were working together quite a number of years ago and working with you as well, we had this contention which we think is becoming the case. So if I could sort of look at the poster children for who I was covering, I was kind of on the...
the BPM later, the DPA side of the world, and maybe Pega and Appian were kind of my IBM, or kind of my poster children. On John's side of the world, maybe OutSystems, Mendix, and some others. And our contention was, is that these worlds were going to merge, and that applications that are process -driven would no longer be different than applications that are necessarily transactional.
people are looking for things that are able to handle a number of different workloads. At the same time, orchestration has been coming to the forefront as a significant issue. Is this something OutSystems is seeing? You mentioned claims management, classic process application. Are you getting pulled further and further into this process and orchestration world?
Paulo Rosado (22:59)
It's not so much further further, but it has always been there. And so it's part of the, in terms of the way we design the language or the model that supports creating these applications, the workflow abstraction is an important one. It's an important one, complemented with the repository or the database, complemented with the UI that includes mobile and web.
complemented with integrations. And now complemented, for instance, there's a new type of abstraction, which is the agent, the AI agent. And so we always kind of try to create the highest level of abstraction so that we can basically model something that's in the mind of the designer, the developer.
So we've always had kind of workflows. We introduced workflows when we started getting a lot of case management projects. But what we realized towards the end, because we measure a lot of this, is that if you take all the objects and the change management that's required on the system that includes all of these components, one of the pieces that changes the list is the workflow, which was surprising for us.
John Rymer (24:23)
Hmm. Hmm.
Paulo Rosado (24:24)
but it's about on average 7 % of the system. It's a very small percentage. And so the work, the effort goes into other areas. Typically UI that takes about more than 50%. So the interface has changed dramatically. The integration flow of the data and the repositories change about 15%. Also, they get hit 15%. And so we ended up by improving the product by flocking to the high change portions and
optimizing the I -change portions of the applications. And so they are important, but they are relatively stable, which is a funny thing. And that's why you sometimes see other BPM -centric platforms that end up by having to go to code to handle a lot of nitty -picky changes on the UI, on the repository, on the rules, on the integrations.
A lot of those things tend to have to be done outside of the core model or the core visual development. And that's a problem. That's a problem for legacy. That's a problem for change. That's a problem for keeping an application evergreen.
Does that make sense?
Rob Koplowitz (25:44)
It does make sense. Hey guys, I'm gonna call a stopping point here for just a quick second, cause I got a little frisky earlier and I over asked a question that was gonna step on our next question on the business expert, John thing, John. So John, should we just have you follow up now and just do the AI question follow up? Okay. Perfect. Okay, great. Three, two, one, restart, go.
John Rymer (25:46)
Thank much.
Yeah.
Yeah. Yeah. And then I'll turn it back over to you for the close.
Thank you, Paulo. You mentioned AI, and we've begun to see what you guys are working on at OutSystems.
AI looks like it's going to be a very, powerful addition to low -code platforms. It looks like it may disrupt some existing markets as well. For the audience, help them understand what you're doing now to apply AI. Gen. AI is of great interest, as you know. And I'm curious, as someone who was one of the founding fathers of this field,
Looking ahead, Paulo, 10 years, where do you think this new set of AI capabilities is going to take us?
Paulo Rosado (27:07)
Yeah, maybe I'll start with the first one, John. Thank you very much for the question.
So we have been tackling this AI on two pillars, two parallel fronts. One is we built initial, we built very quickly, we built an editor to be able to create agents. Because we wanted to experiment in the market, no one knew. And still today, there's a lot of confusion on how these things are deployed, what is the life cycle. And we wanted to experiment with that.
And so we had about 40 customers using this tool. We have been changing it almost every week. And we use it internally also. One thing, for instance, that we've realized is that while an agent is a component, for instance, you can put an agent with a portal or you can put an agent in the middle of a workflow. The fact of the matter is that the life cycle of these things is different from deterministic software. And so
And so we've been going on and on and on. And as we move on, we realize that the cycles of continuous delivery and change are broken in different ways that deterministic software are. So there's a lot of research we've been doing that, but it's really experimentation. And so we've been deployed so far, I think we have deployed probably 150 agents, use cases in real life situations among ourselves and our customers.
And we've changed this tool like 500 times. And so we've been experimenting with it and it's becoming really cool. The second area, is more, how shall I say it, the much bigger investment is that because we have this language, this full stack language, we have a huge opportunity to actually generate. We're looking at generating a very large portion of a massively large application.
John Rymer (28:46)
Huh.
Paulo Rosado (29:12)
but at the same time make it possible to be tuned and adjusted later. And so we're using AI generators, AI editors, copilot type of approaches with one fundamental advantage is that our generation, our cogeneration is broken into. And
So we generate, we've been using AI to generate into this language. And then we have a deterministic code generator, almost like a compiler that generates the rest into real code that runs in our hosting. And the reason why we did this in two phases is because with a portion that's non -deterministic, which is the neural network, and the other portion that's deterministic, which is a normal algorithm, we can, for instance, make a patch, a security patch.
on the code that's generated on the bottom layer and make sure that the AI will never regenerate a bug that removes the security patch. And I have tons of examples where this two -layer approach is absolutely fundamental to be able to use GenAI without creating a huge problem in terms of compliance, terms of security, terms of scalability.
and in terms of a bunch of stuff that are required by very large organizations.
So fundamentally, the type of applications, John and Rob, are changing. They're changing. They're dramatically. And so you talk about workflows. We see more and more the workflows disappearing, being replaced by an agent that redirects the flow. The UI's are changing. The forms are disappearing.
Why would you need to type a form if you can talk or dump a bunch of text and the agent kind of structures the data out of the unstructured text into the form? And so the UI practices are changing dramatically. And because we tackle all of these issues, we have teams that are kind of trying to understand where this thing is going in these multiple areas. And, you know, it's, I've been around, I've been in this, doing this for the past 23 years.
And every time I think, okay, this is stable now, probably can retire, whatever, here comes another interesting moment, another exciting saying, and another future where we're seeing where this thing is going. it's, my God, it's really exciting. In terms of the future, it's what we talked in the beginning. I believe there's going to be a dramatic shift in the buy to build equation. I truly do.
John Rymer (31:47)
you
Paulo Rosado (32:06)
There will be more software overall. There is a huge hidden pipeline of software, backlog of software that's going to be flushed. And we also see no reason why companies will stop having so much legacy for so many years. Systems can be replaced much, much quicker as we move towards the future. So there is no reason why you should have inactive systems
frozen systems that no one touches or whatever, given the fact that with these new tools you can fundamentally rewrite a new system extremely, extremely fast. I think it's amazing. This is an industry that's completely disrupted
John Rymer (32:45)
Right.
Is there anything that scares
about AI.
Paulo Rosado (33:00)
No, not the AI that exists today. Actually, we like this model where everyone, the investors, when you talk with them, they say, there's no money in foundation models, at least not for the little ones. It's going to be like three or four or six, I don't know, companies building foundational models. And so everything that we do, all of these guys like Google and whatever, they're building our foundation models.
where we can basically augment them either with context windows or with context tags and grounding and all of those techniques, which basically removes a huge amount of learning curve for people who want to build these agents in a very, very effective way. And we have experimented with so much that we've realized what is the anatomy.
of the patterns to do this and also the life cycles of this system. So we excited because we usually like to speed this up. We also like to tackle the life cycle of change. It's a, you John, that's always been our saying, right? And that was very, we were a little bit fuzzy like six to nine months ago, but we've kind of nailed it now. And it's amazing. It allows us to do and give our customers.
John Rymer (34:08)
Yeah.
Yeah.
Paulo Rosado (34:26)
capacities to do some stuff that's really, really impressive. But the technology is relatively simple. The patterns are simple. It's just that the impact is huge.
John Rymer (34:37)
Got it. Thank you. Rob, back over to you.
Paulo Rosado (34:37)
So I don't. Yeah.
Rob Koplowitz (34:42)
Paulo, thank you so much. This has been so informative. The quote about sort of the shift in the bill versus buy and the hidden pipeline was so powerful to me, but along with so much other great content you provided today. Thank you, John, for co -hosting. Thank you, Paulo, for coming in and sharing your insights. It's been an absolute pleasure hosting you here today.
Paulo Rosado (35:09)
No, likewise guys. And it's really nice to see you every two years, John. Next time I hope we go for a sushi, for some sushi as we always did in the past.
John Rymer (35:16)
We're gonna have to fix
Yeah, yeah. By the way, if you like this episode, you know, on whatever platform you're viewing it on, hit the like button, please, and tell your friends and neighbors. We're excited about the interviews that we're doing on the Lowdown and Low Code. We think there's a lot of great insights to share.
And so please, if you agree with us, give us a little love. Thank you.
Rob Koplowitz (35:53)
Thanks everybody.
Paulo Rosado (35:55)
Thank you guys.