Orbit 56

A certain level of chaos is healthy: Franz Faerber on fighting bureaucracy and the importance of deep domain knowledge in AI

Franz Faerber spent 26 years at SAP building HANA before walking away to found Everest Systems. In this episode he challenges conventional wisdom on where and how to build next-generation enterprise software. Speaking with Hg's Sebastian Zureich, Faerber makes the case for Germany over Silicon Valley, citing equal talent at a fraction of US costs, and pushes back on Sam Altman's vision of throwaway software, arguing humans fundamentally crave stability.

After four years in stealth, Everest emerged with "live sandboxing" technology that eliminates complex multi-system ERP landscapes and an AI-native architecture that allowed his team to build a warehouse module without writing a single line of code. Faerber's counterintuitive leadership philosophy ("a certain level of chaos is healthy") and his advice for SaaS leaders to assume AI costs zero and ask what fundamentally changes, offer a masterclass from someone who led innovation inside SAP and now builds against it.

Watch video

Listen on:

Episode Transcript

Franz Faerber

I am a big believer in a certain level of chaos is healthy, right? I don't want to eliminate that chaos. At some point in time you have to reduce it and look at it, but chaos at some point in time is creating innovation, it's creating energy, it's creating things. And I want to really give the people the chance to create some chaos. Of course, we have to eliminate it at that point in time, being very, very, very careful of introducing bureaucracy. My learning is if you have introduced something, it is so hard to remove it again.

Sebastian Zureich

Welcome to Orbit, Hg's podcast series where we talk to business leaders who build some of the most successful and sector-defining software companies around the world. I'm Sebastian Zureich, a Director in Hg's Munich office, and today I'm joined by Franz Faerber, co-founder and CEO of Everest Systems.

Franz, I'm super excited to have you here. You actually were many, many years with SAP as a senior technical leader. You were actually responsible for building SAP HANA, and now you decided to found your own company a few years ago, Everest Systems, to take on those very giants like SAP and Oracle and actually set yourself the goal to build a really modern and sector-defining ERP system.

I think this conversation will be super insightful because you bring a rare dual insight. On the one hand, you know what happens in the big incumbents. On the other hand, you made the decision to leave and start up on your own. And I'm really much looking forward to learn from you what it means to build such a software company, how we think about building it in an AI age, and also how AI informs building that company. Thank you for being here.

Franz Faerber

Thanks for having me here. It's an honor to be here. I'm really excited to discuss with you about what we are doing in Everest, also the future of AI, and the topics.

Sebastian Zureich

Actually, the first thing also for our guests here is can you tell us a bit more about Everest and specifically also the USP you're building towards? You took off on a big challenge to compete with giants like SAP or also Oracle. What is it that you're trying to build for customers and the USPs you're trying to generate that you think this is actually a viable goal?

Franz Faerber

Yeah. You know, in our journey when we started in 2020, things changed a little bit. As of now, there's the big AI revolution which came in between when we started our journey, right? The motivation for me was mainly there must be a different approach to build such a business system which users like, which are easy to use, which is fast, which is comfortable, which is not super expensive. And that was the initial thought.

And over the time, right, when we looked into architecture and looking at the changes, then of course we saw that with AI you can really think the business needs for a company completely different, right? And then now we see that it's the first time in my life what I'm seeing in software, that it's possible to really innovate the big giants out.

Normally when we started in our journey, right, we thought, ah, it takes at least 10, 15, 20 years until we really can compete against an Oracle or an SAP. Now it's much, much faster, right? First time in ERP since ERP was founded is possible, right, to innovate them out much, much faster. And there we are looking into how can we make it simpler? How can we give more control to the customers? How can we make it cheaper? And how can we make it that really users really like to use it? I think that's our motivation.

Sebastian Zureich

Okay. Yeah. Can you give us one or two examples of the way you now see a real opportunity to do this differently? Also, particularly from a product perspective.

Franz Faerber

First of all, when you look into the landscape of an SAP system, right? You always have a huge landscape, right? It's not that it's just one system where you go productive. You have a quality system, a test system, a development system. Many, many copies of that, which makes it really expensive and also cumbersome to do that. When you want to do an upgrade, you don't do it on your production system. You always do it on your test system, try it out and do things like that. And then at some point in time you go to your production system. So the complexity of the landscape is a pain.

We developed a technology which we call live sandboxing, which allows us to just have one single system, which makes it much simpler from the IT perspective.

The next thing is how long does it take really to do such a change in the system -business changes, upgrades, and so on. That's normally a very long, super expensive system. There's a lot of consultants, lot of stuff there. If you can do that much simpler because your technology is simpler, your setup is simpler because you have the technology, then a lot of pain which you have around your system is just gone.

Sebastian Zureich

Okay. Actually, we'll get back to the aspect of sandboxing. Maybe still staying on Everest and where you are in terms of your lifecycle of the company. How far have you progressed the build out of the platform so far? And maybe you can also give us some insights as to where you are at the moment in terms of commercial traction.

Franz Faerber

Yeah. You know, we took us—and that was really a kind of a change in how I was looking at how investors look at us or look at companies and how you build normally such a startup. We had the chance to build our platform four years completely in stealth. And of course, if you have this time, then you really can rethink how such a platform should look like.

And the founders - two of us are coming from SAP. We had all long experience of how a platform should look like from SAP. We looked at other systems, how they did that. And then we really sat together and said, okay, what does it need to build a platform? What is necessary? What is overhead? How do we do that with a new technology today?

And there we had the chance to build a platform which we really love. It's not like that we always say every day, oh, we should redo it now again because we are outgrowing the system with our platform, with our applications. We build all the stuff like lifecycle management, delivery, multi-currency, whatever, multi-books, all the stuff.

Translation, all the things which is in addition to the standard functionality we built into the system from scratch with an integrated design. And therefore this platform there, we are really strong and encoded.

Then one year ago we decided to go out of stealth and go into the market with our first applications, which are mainly on the finance side, to try to find customers and so on. You know, the problem of the stealth mode is right, I like it on one side - we had the time to build it. But if you really do a good stealth mode, then nobody knows you. Then you come out after four years of stealth mode and believe now we have a great product, and then you have to find customers who really do that.

And in the ERP space, that's difficult because it's not a tool. Until a company decides to really go with an ERP, normally they go for a long time. They bet their future on that. So it takes a little bit. So that is why it took for us this year, right, to get the first customers live, which we have now. And live for us means having at least one quarter in close, having a pipeline of customers which we have now, and now we have also the references. But it took us a year to have the first 10, 15 customers which we are having now, and now we are starting to scale.

Sebastian Zureich

Yeah, it's not too surprising given that you really tackle enterprise large scale customers, right? So sales cycles are different and as you say, you're not known. Also, on behalf of our listeners, I mean, it sounds quite like a special situation that you were able to build for four years in stealth mode. Not many companies are able to do this. How did this special situation come about and what enabled you to do that?

Franz Faerber

First of all, when we discussed about that, right, in the first round, also with our first investors, and then it was clear if we do such a huge journey and really want to build a next generation ERP, either we build the platform really in a solid way or it'll be super, super hard as we go forward. So that was an agreement from the beginning.

The problem then was when we really executed that, how do you motivate the developers that for years you don't see a real customer? We discuss with companies and whatever, but don't see a real customer, don't have really this success and this feedback. This was a real problem in this phase. Of course we did a lot of events and stuff like that and brought experts in and whatever. But that was kind of the challenge of the journey which we had.

Sebastian Zureich

Okay. Yeah, that makes a lot of sense. So, in terms of the status, would it be fair to say you really had the chance to build a product that is actually ready to be shipped for four years? So the platform is up and running and customers can use it, and now it's about really building the commercial traction and actually getting your developers excited that they finally also shipped to customers?

Franz Faerber

It's mainly this, but on the other hand, we also learned, right, that even if you know the space and if you know the application and whatever, you learn a lot when you see your first customer, what you are still missing despite of believing that you're so great and everything is fine and whatever. The reality is, without the customer feedback, a real customer going to a real product, you have to learn a lot.

But nevertheless, yes, from the platform perspective, we are really good because we use our own platform to build our own applications. So all of us, we had customers which were ourselves, and you can imagine our own developers are the most critical customers you can have. But from the application perspective, of course we are still in the learning phase. We're very in the beginning, in the learning phase. I'm sure for the next 20 years we still will learn what would be.

Sebastian Zureich

What would be your insights, like maybe one or two tips that you say that you would look at first or prioritize on that journey?

Franz Faerber

You know, when I look at how we currently build software and how we are looking to the different applications, the differentiator, let's say against the big business applications or the big ERP companies was in five years ago, it was still the big portion of that was application functionality, application feature. Because many companies build a lot of extensive features and whatever.

And if we really assume, and I think we are quite true now, right, that applications can be generated by AI, especially the coding, but also some of the definitions and that everybody can do, the differentiator is not in single application features anymore, right?

If I would now create a new SaaS company, I would go as soon as possible very deep into the domain. I think that very deep domain knowledge, which is not out there in every document and whatever, where AI can easily bring things together and generate the same thing, is a big differentiator. Standard functionality, just traditional stuff which you know in the past is boring because anyhow it will be there for everybody. Deep domain knowledge. I would immediately go into the deep domain knowledge. It'll be hard to develop something which is looking nice, which has the main features, whatever. Everybody will have that.

Sebastian Zureich

Yeah. Okay. Second thing that we should get back to, but maybe first one other question. Given the speed of change that we all see and experience around us in terms of model capabilities, technology built around / on top / below AI, it feels like everything is changing on a quarterly basis, but actually sometimes on a weekly basis, right?

On the other hand, I mean, you were a company four years in stealth mode, you probably have a product vision that is probably five years in the future. How do you build towards such a long-term vision, especially from a product perspective, when everything around you is constantly changing and how do you make sure that you're not jumping to and for too much and that it just gets a big mess?

Franz Faerber

Yeah, very good point. You know, because that was a discussion we had also back and forth. I believe when you look at the functionality company's need, this is not so dramatically changing, right? You have to close your books, right? You want to make revenue, you want to bring orders in. You want to look at your costs, you want to do production planning, you want to run your factory. That is not changing, right? The question is how do we tackle them? What is the processes? How do the processes change? And how fast are we to develop new functionality? And how do we enable them to adapt their business much, much faster in the software stack to the reality of their business?

So when you look at the high level plan, what we want to deliver, we still want to deliver an ERP software. We still want to go, at some point in time, do manufacturing. We still believe that there's a service business out there, and we have to provide the functionality. When we now look at how we design the product - I think that was more your question you wanted to go into - then currently, we are always looking into, when we build something, do we grow?

If we build that in that way with the growth of AI, because that is clear that this is exponential, still exponentially growing, and if we don't grow with the growth of AI and we are putting ourselves at a certain state, then we will be behind of the competition.

I'll give you an example on that because that's a little bit theoretical. The model of how we want to develop software today is, you know, people are writing code and more and more you ask AI to write your code. But what AI is currently writing is with a methodology and the capabilities of the models of today. Therefore, if you want with a coding which we produce, want to be at the methods and the methodology and the capabilities of tomorrow, we must be able to exchange this code at any point in time. Because otherwise you are locking yourself at the state of the models of today or of the UIs which you generate of today.

Therefore, our approach is that we go back and saying, our truth is not the code. Our truth is the specification and the requirements of the application. And what AI can do is generating out of that the coding and the application that we can do at any point in time. That's a goal where we want to go to. And that's just one example of where we say, then we grow. Really, if the models become much better, they generate much better code, much better UI, much better simulation. Then you grow with that.

Sebastian Zureich

Yeah. So essentially, if I understand correctly, you say you manage to attach yourself to this exponential growth curve of AI development and you don't feel like that something new comes out and it forces you to go two or three steps back. Because now you can do things maybe better in the long run, but you need to do it differently and therefore it costs you time that you always sort of go back to square one. That doesn't feel like that?

Franz Faerber

Currently not, yeah. But you know, the development is going so fast that you have to look at it. So we have some assumptions and if these assumptions are getting wrong, of course then we may have also have to go some step back. So currently our assumption is that we have a business platform or a business operating system, which we want to have more on a traditional way where we really have the coding, want to run it quite some time, want to stabilize it, and building then the application on top.

Giving an example, doing the accounting, the core accounting stuff, it's just traditionally developed, right? If now we see that the generation of AI is getting so good and so without hallucination that this prerequisite, which we believe should be done by us is getting wrong, or we say, okay, database can be generated or whatever, or kernel layer can be generated without hallucination, in such a quality that it's much, much better than today, then we also have to rethink. Currently we assume that the platform is something which we have to build.

Sebastian Zureich

And out of interest, is this something that an SAP for example could also do? Or wouldn't they have the flexibility, for example, to go from a deterministic to a probabilistic AI driven accounting module?

Franz Faerber

You know, software, right? You can change it. But looking at the dependency such a company has on their customer base, right? If they change something on this low level application functionality, the customers would kill them.

Sebastian Zureich

Yeah. And why will your customers not kill you if you do it?

Franz Faerber

Because currently we don't generate the accounting system, right? We are saying we have a base which we don't generate and we're generating other application on top, for example, inventory or others we generate on top. But the pure hardcore transactional system where we say we have to absolutely guarantee is kind of handcrafted, manufactured, right?

Currently, I would assume if I would go to a CFO and telling them, you know, your accounting system is generated, don't be worried - well, this guy would not come with us.

Sebastian Zureich

Okay, I understand. But so my question was also, do you think you're more flexible in doing it from a technological perspective? I mean, of course the customer will always want a solution that is bulletproof, right? Especially in a field like accounting.

Franz Faerber

We build a system that's also this AI native. You have to build your system that you say, okay, things can be changed also by AI and build modularized in a way that if there's a system which can generate it, that you really can do that. And this is how big are your modules? How good are your interfaces? How you design the system, you design the stuff. That's—how you build after 50 years of coding is hard.

Sebastian Zureich

Staying a little bit longer on this topic. So, having been so long within SAP, are there certain things as a leader and also as a technological leader, you are deliberately doing different now that you found your own company and have other options and flexibility? Could be either in terms of your leadership, but also in terms of how you develop technology.

Franz Faerber

First of all, you know, I was long enough in SAP that I would not have stayed there if I didn't like it. I like it there and it's obvious, right? And I'm a big fan of the culture of SAP and I know so many people are still living in Walldorf close to SAP. And it must be -

Sebastian Zureich

Like the persona, not -

Franz Faerber

Yeah, kind of. But it's not the case because still I'm a fan of SAP. So I don't want to criticize. On the other hand, of course, if you do your own company, you want to do things in your way. I think the main thing which I have learned, especially in my journey in SAP, what changed there and which I at the end didn't like so much—you really have to be careful not to build your bureaucracy, your processes in a way that it's really hindering you at some point in time.

Of course, you cannot avoid it. If you become big and bigger, then that's maybe the natural way to go. But this is the thing which I'm fighting every day, right? Do we really need it? Do we really absolutely need it? Or is it just because somebody thought, of course SAP has it or other companies have it, we also have to do some of the processes and whatever.

I'm a big believer in a certain level of chaos is healthy, right? I don't want to eliminate that chaos. At some point in time you have to reduce it and look at it, but chaos at some point in time is creating innovation, it's creating energy, it's creating things. And I want to really give the people the chance to create some chaos. Of course, we have to eliminate it at that point in time, being very, very, very careful of introducing bureaucracy. My learning is if you have introduced something, it is so hard to remove it again, right? It is very easy to introduce it. It's almost impossible.
It's the same is true also for organizational layers. You know, people are leaving your company if you reduce layers.

Really good people are leaving. Nobody's coming to you because you introduce one, right? And nobody's getting super happy if you introduce one. And of course you are pushed and I see that all the time, right? Oh, is it too many people in the team or whatever.

That's my daily fight which I want to fight because I believe that it's so wrong, so wrong. If you introduce something, then you lose flexibility. Minimal set of processes, avoid bureaucracy and a certain level of chaos.

Sebastian Zureich

Yeah. That also resonates with us, right? On the one hand, we see it on our portfolio companies who are, most of them are also on a steep growth trajectory. So they also always have to make these trade-offs between what do I change and how can I stay lean and nimble.

Within SAP, you've also seen one significant platform shift, probably not yet completed. Not as far as they want to, but you have seen the on-prem to SaaS platform shift. There's a certain playbook around it, right? We've also used it, I don't know how many dozen times with our own portfolio companies. Does the playbook still hold or is it different this time?

Franz Faerber

Our assumption, my assumption is totally different this time, right? And a few things. Because when you looked at going into the cloud, it was internet. And of course also there was HANA shift in SAP very specific to SAP. There was the cloud shift, but the structure of the software was still the same, right? It was a platform shift.

It was an infrastructure shift, cloud at the end. It's also thinking model shift, but the software itself is kind of very similar, right? You don't have to completely rewrite it. It's not endangering your business model overall.
Of course, we saw that the new SaaS companies were coming up, Salesforce were coming up and the competition with SAP. But overall, when you looked at the business model was very similar. You deliver software to your customers, they pay for it. Maybe they paid monthly instead of in one shot. But also service was before that.

I think it didn't change the fundamental stuff. With AI, first of all, this goes so much faster, right? And when you look at the journey, how long it took until SAP or Oracle, all these guys really had a real cloud solution, not just - and then it took, I don't know, years, years, years. Now you don't have this time. That's the first thing.

And second thing, I believe that the fundamentals of software industries are really changing. You cannot sell application features anymore, right? And that's a big, big, big shift. That was always the thing. What the software company sold - application features. Of course also platform, you know, partially, but mainly application features. This time is over, right?

And adapting to this massive shift in such a short term, that is such a challenge which I think was never there in the software market. And that's a chance for us as newcomers to really out-innovate. And therefore that's my belief. I had the first time a real opportunity to really be a big player in that game.

Sebastian Zureich

Okay. Can you take it a level deeper what you mean by application features and this is no longer what will eventually be commercially successful?

Franz Faerber

You know, when you look at how with the help of AI, you today develop an application - let's assume you don't know an area. Let's say you want to build now an application for production planning. To do a first version of that or even a second version, you just go to AI and ask, vibe code it a little bit. You can even do it more serious and say, hey, give me a summary of the existing system. Do a market analysis, look at research. Out of that, extract your requirements, write me super nice specification.

Then maybe you hire one guy who is a domain expert and discussing with that and saying “AI, generate it”. And then if you have missing features, then first of all, you analyze maybe your own software with AI and saying, are there missing features compared to X, Y, Z, which somebody said, somebody told you about, this is much, much better, this software is much, much better than yours.

Then you need the expert maybe at the construction company. You need a set of experts who really know how it's how it's really working. Then it comes to the point that you're saying, okay, is it now a generic software in the sense of an ERP anymore? And then I build my personalized application at the customer side with a specification and the knowledge of the customer side.

That is where I believe the whole model is completely changing. Much more personalized thing, but not programming specification and the generic thing, which is for free because everybody can do that.

Sebastian Zureich

Okay. And wow, now we have a lot to tackle and there was a lot in there. So maybe, first of all, to tie it back to what we earlier discussed here, this idea of developing software from first principles and you need to find a way as an incumbent and as a startup to do that.

Let's look at it from a few different perspectives. But let's start with AI and R&D, right? I think you also alluded to it. I understand your warehouse management module—you built it without writing a single line of code.

Franz Faerber

The inventory, yes. The warehouse management, yes. We did it explicitly. That was our challenge which we gave to—we just have three developers now. We started with one. Explicitly was don't write a single line of code. That is your challenge, right? And we are not allowed. Try it. How far we come. And now we deliver the first version. We didn't write a single line of code by ourselves. It took for us a while. Of course, we had to look at how we use the tooling and how we do that. What is the process? And the models are not perfect yet, right? And half a year ago was even less.

Maybe looking first about the developers who are doing that. They have a lot of fun with that. Yeah, of course. They're much faster. They can produce something which they never hoped before. And if I look at the new kids, new guys who are joining our companies from university, they don't want to program anymore. They're saying, why should I do this ugly stuff? I'm so much faster. And it's so much fascinating to do the things faster.

I think the value comes from this personalized, not as a person, as a company, personalized software and adoption to the requirements of the company. And having a platform which allows you to combine the generic things with the stuff which is absolutely different at the customer side.

At the end, if you look at today's software, the complex ERP, it's a joke that they are building this generic software for every industry, for everybody, for all types. And then they give the pain to the customers or to the consultants and then now configure it with a hundred thousand slides to do that. Why should we do that?

Why is it not much better to saying, hey, I deliver 80%, and maybe I even deliver the a hundred percent for some guys, right? And it's not that we don't want to do that, but then saying, hey, you customer, you know it much better what you need. Specify that. Merge your specification with our specification and then let's generate this software. And this process of doing this personalization, it is a combination of what we as a system provider are doing, where the platform is needed because you have to give guarantees, and the work at the customer side. And I think that's the value of the future from my point of view.

Sebastian Zureich

Will this still be monetized by a company like Everest in a way that the overall software market will grow because these 20% are just so valuable? Or is there risk that given customers do it themselves, that they basically will also not be willing to really pay up for it?

Franz Faerber

You know, if you would believe that AI magically can generate everything which you imagined, right, then there is no need for a software company anymore. But I don't assume that this will be the case, right?

Even if you generate your own application, you want to have a guarantee that it's legal, that it's auditable, that it's really running, that you can support it, and all the kind of things. This comes from, well, software design. This comes from a platform which gives you that feature, but it also comes in discussions—how you really do that, right? In the sense of you have your requirement, you know what you want, but you also have to say, what does it mean if you are now translate that into requirements that AI helps me to do so, but I still have unique support in the sense of how do I do it in the right way that it's fulfilling all the other requirements.

And you know, what's coming this 20%? It is when you look today at this 20%, but if every company does this 20%, then the number of software, the size of software which is out in the market will grow dramatically.

Sebastian Zureich

Okay. Yeah. Let's dig a bit deeper here. I actually had a question in here. Listened to Sam Altman the other day and he described basically that software will become instant and one-time use. What do you mean by that? I'm an end customer user of software. I, on whichever front end and whichever operating system, but I will—I basically describe in native language a task that I want the software to perform. Then as if by magic, like software is spun up, right? It's written, it executes the task, and once it completed it collapses again. That's how I would describe it in my words. That's basically I think what Sam Altman wanted to say.

How far away are we from that and how do you take this idea on at Everest? Because I think, or I would assume that brings us to the idea of sandboxing.

Franz Faerber

To be honest, I would doubt in this theory that this is true. And it depends in which kind of software. If you look in consumer software, maybe that's more true than in business software. Do you really want to have a software which is changing every day?

You know, do you want to have that your UI is changing every day, that how you act with your system is changing every day? I think that's not the nature of what we want to do. We want to have stability as human beings, right? And of course then you can say your AI, you can do everything with natural language. Natural language is helping you a lot on the user interaction. But do I want to have changes every day when I go to work as doing my job? Not everybody wants to play with AI, right? They want to do a job. A lawyer, you know, or whatever, a producer—do they want to train their people every day to a new software that's behaving different?

I think some stability is in the nature of us as human beings. We want to have stability, right? That's also the reason why sometimes it's hard in an organization to do a change management because people are logically are going for stability, right? And therefore that we now produce software where in all cases we just have throwaway software, I don't believe that, right?

I think he's right in that software can be adopted in real time much faster to changes in the business. This I totally believe. But that I personally create every day my software and throw it away the next day, I don't see that I want it, right? And that's a question, would it be possible? I think it could be possible.

Sebastian Zureich

Let's call Everest the operating system for that business unit in the end, that user. And then you provide the guardrails within Everest, right? What the individual user, to which extent they can customize it. And can they also go sort of outside of the scope of Everest in a sense that—think like, and that you can start automating workflows that partly also happen outside of Everest.

Franz Faerber

That's, by the way, that's one of the things we discussed about that of how we go into bigger company scale. Of course if they have an SAP system, if they have an Oracle system, of course we want to be the platform for also having extensions there. And then of course you access the data from other system and then it's kind of the application there you generate. It's kind of a workflow bringing data together. The question is do you model it as a workflow? Do you generate the coding? Depends on the application. But that's exactly what you want to do. And very often it's a combination of that.

Because the nice thing if you have an ERP as your basis, right, then if you want to load, let's say master data or customer data, you have already a data structure where you can store it to, right? That makes it much simpler. The AI doesn't have to generate everything. You have already something where you can play on top of that.

Sebastian Zureich

Okay. Also, trying to reflect a bit on what you said earlier, and that suits nicely to what I heard your co-founder Sandeep saying in an interview. He basically said that you are bringing down implementation and customization times, obviously after what you just described, you're bringing it down to weeks in some cases even days.

I assume it's a very nice thing for you at the moment, but also there, where do you think we'll land with it? Because ultimately it drives competition to really a next level and classical, let's call it customer lock-ins, basically disappearing. Is that right?

Franz Faerber

At least you know, if they're disappearing, right? I think in future it'll still be easier to change your editor than you change your ERP system, right? That's obvious. You still have some level of lock-in. And you know, this implementation times, also depends a little bit on what the customers really want to do. Is it a technical implementation? Then of course it stays. Very often customer use the opportunity even they change the ERP also to rethink their business model, right? And then there are two phases. One is a technical thing and one the business model.

But if it's - you're right. The times of really changing the system will massively go down, which I think is a good thing for the industry. It's a good thing for the flexibility. I think it's also good thing for the software providers, to be honest. If you have the guarantee that your customers anyhow cannot change, you're getting lazy, right? And your innovation is going down.

I think for companies, an organization, it's good to always run into a very competitive situation and not laying down and saying, we can afford it because the customers are anyhow with us. I think that's healthy. You know, do companies have to exist for a few hundred years? Maybe. That's not necessarily - having this competition is good.

So I'm not worried about that. You know, if you are not good enough, we should not be there. If customers don't like us and want to go to a competitor, that's totally fine. So we have to be just better, right? And this being close to customer, companies are just forced to do that. If there is pressure, if not, then they're letting the customers alone.

Sebastian Zureich

Yeah. I think we are all making our own experience every day, right? We certainly use business applications where I wonder how is it possible that we still do it this way? And that describes naturally a certain complacency, right? If you have a massive pressure to change it, then the organization change it. If they don't have it, it's not this company or the other. It's clear competition is good.

But then I take away also another important element from your insight because it sort of boils down again to our nature as humans, right? We don't want to change every day and we want to have some stability. And if I understand you correctly, you're saying as long as the product is good on a relative basis, then customers will not want to move away from it. So we will still have stability, but you need to be really on top of your game in order to create similar log-ins than you maybe did in the past.

Franz Faerber

You know, I believe - I don't have data for that - but I believe if customers have the chance to change and have the possibility to change, they are more happy with you than if they don't have, right? This mental thing to be a hostage is really negative about you. It's not positive. Then they say, I anyhow cannot change it, I have to accept it, right?

If they maybe would compare it with others, they say, ah, maybe it's not so bad as a thing because I also have a lot of advantages. Then they can make the choice. But if you don't have a choice, right, it's—I think for everybody of us, if you don't have a choice, then you criticize it a hundred percent. If you have a choice, then you have to look at, find something better, right?

And that's sometimes not so easy because of course we are all thinking that what we have is less than what you see outside, right? The cherries in the neighbour's garden are more red than our own. But if you really have to make then the decision, then you really have to look at that. If you just see the cherries there and you know you don't get it, then of course you want it.

Sebastian Zureich

Okay. One last aspect with regard to the mode that traditional SaaS had and how we can basically translate this into an AI world. What role will verticalization play? Because from my perspective, that would be one element that creates this real life viscosity and last mile complexity, right? Because of vertical knowledge that is somehow encrypted and built into software. Must be a differentiator also in the future. Would at least be my take. What do you think?

Franz Faerber

I think it's getting more and more, much more important than today because the generic thing is not differentiator anymore. No company will accept anymore that they get a generic thing and they have to adopt it by their own bank configuring. Having not this knowledge embedded into the software - of course, it'll be not so complicated anymore to build verticals.

The question is really do we have then for every vertical a different software stack? Different things. I don't believe that. I think I still think that there is a chance to have a business software stack which is basic for the verticals. Like the accounting is very similar. I think HR is similar. There are things which are very similar across the verticals, but not having a very specific solution for the verticals. But nobody will buy that anymore.

Sebastian Zureich

I believe that even in accounting for example, there are vertical elements that you can, again, coming back to the customer value and the excellence of the product, where you can go deep even in a rather horizontal category of software.

Franz Faerber

Absolutely. Yeah, absolutely. There are the topics. Look at SaaS in industry. Look at other—yeah, there are. But still there are, you know, there are regulations which make it quite similar. Nevertheless, which are global. Therefore, there you also have this global components as well.

Sebastian Zureich

I think a lot of people think that the general purpose LLM will be the operating system that end users use on a daily basis as their UX in the future. What's your take on that?

Franz Faerber

You know, I compare it a little bit also with the big cloud platform. We had this in SAP in my times in SAP, a lot of these discussion - is now Amazon, Google, Microsoft, in parts are these big guys now replacing all the software, business software out there because they have all the infrastructure and why should you run it somewhere else and whatever.

Getting the DNA and the knowledge of building business software is not that you just do it because you have some people who understand AI and whatever. Look at automotive industry. How hard is it for them to change from a production company to a software company? Super hard. That's one of the crisis we have here in Germany, right? It is because it really is hard changing from a technology company to a business company and understanding the processes and how do you treat the customers and whatever is super hard.

Is it possible? Everything is possible, right? But money alone will not fix it. You have to change a way of the DNA.

You have to bring the right people. Look at Google, how hard is that for them? And they invest a lot in becoming more business application software.

So I'm not so worried about that. Of course, currently a lot of people believe also developers in our company say, oh, I can build this application there. Look at it. That's all possible in AI. But if you then ask, okay, how do we deploy that? How is it auditable? How is it integrated into the other stack? What is about the other things? Upgradeability and all this kind of stuff. Then you need the knowledge of building business software.

So I'm not so sure that the technology company can easily migrate to become a business software company. I think these are two different DNAs.

Sebastian Zureich

And maybe as you earlier said more on the consumer side, but when it gets to deep B2B application levels, then it's a lot harder.

Franz Faerber

It's harder. Yes.

Sebastian Zureich

Talking also about German car manufacturers and coming to software companies. We are now having this conversation in Munich, right? And obviously the AI narrative is very much driven, dominated from the Silicon Valley. And I guess how software companies operate and have to operate is different here, right? Different cultural aspects, different access to talent, also subjected to different types of regulation.

The general narrative would be, it's a disadvantage. What's your take? Is there also the flip side where you say it's actually good to do it here? And you might have decided otherwise you wouldn't be building in Germany.

Franz Faerber

Exactly, right? Our company, I think we are a combination of a German-US company and nevertheless we decided to do 80% or even more of our investments here in Germany, especially on the development side. And that was—you know, we could decide to do it differently. We could also decide to do it in a more low cost location, right? Also in Europe we could also have done it in US.

There are, you know, there are some disadvantages here in Europe. We see from my point of view, the biggest disadvantage is the investment culture. Good luck that you guys are here and trying to change it. It's harder in Germany and Europe to get money for a startup. I think that is the biggest disadvantage.

There is also some regulations and bureaucracy and so on. But to be honest, when I look at our journey, that is not a make or break. Do I like them? No. We all have stories. We also have very ugly stories about what is it? But that's not the point.

When I look at the talents here, the talent pool is really huge. People are really motivated to change things, to do things. People are cheap, right? Compare it with US. It's really cheap. It's cheap honestly. That's a huge advantage. The US guys almost don't believe how we can operate so cheap here, right, with really good talents. And I think the difference on the talent between Europe or Germany and US, there's almost no difference. I would say. And we have the chance to get the good guys, right?

On the other hand, right, what I'm seeing—we have in Europe, we have to be careful that we really have all the culture of that we absolutely want to be successful, right? And that's a little bit when you look at how it's spoken about hard work, about pushing yourself into that, being totally motivated, saying this is my life. And this is a little bit different discussed in US than in Europe.

And I think that's for me the second disadvantage, right? The biggest is about the investment culture. The second is, do we really have enough people who really have this belief in saying, I want to achieve something and I don't speak about work life balance. I speak about I want to have success, right? And both is a valid life which you want to have. But if you want to really compete, then we need people who are willing to jump in and doing everything in order to be successful.

But on the other side, there are enough people here. Could be more. And I think when I look at software development, I think Germany is a perfect place. Not saying that France or Italy or whatever are worse. That's not what I'm saying. But if I would create a new company, I would do it in Europe, not in US. And main thing is talent plus cost factor, right?

And it is so international. You don't need to be in the Silicon Valley, right? It's not necessary anymore because information is everywhere. Of course, maybe you know a few people more there if you are going through the street. That's not, I would say that's not a big differentiator.

I think we have a big advantage here in building application software because we have a lot of different industries here, which we should use as our advantage. US is more driven from the pure technology side. If we use the chance and saying this is our space, we don't want to compete very urgently with a lot of money against the OpenAIs and whatever, which is maybe really hard looking at the money which is going in there and how late we are - and we use the free spots, which you have mainly using the AI and bringing that into real life, then we have a big opportunity.

Sebastian Zureich

I have two more questions for you. One would be, if you'd have to give one piece of advice to many of traditional SaaS leaders to strive in an AI age, what would be the one takeaway you'd give them today?

Franz Faerber

You know what I've learned when we did HANA in SAP times, right? There when we started that and when we looked at our technology and memory technology at that point in time, that was kind of the faster database and whatever. And there I learned from, especially from Hasso in SAP times, because he then went to the application and saying, think of if data access would be zero. Let's assume no cost. How would you do things differently?

And that's the kind of thing which now also drives me in the AI world. Let's assume AI can do this and that - can generate coding, can do much easier evaluations, can do planning, can do forecasting and whatever. And then the thinking is what would it change beside of having three functionalities which everybody will do. That is not the change. Everybody will do some process optimizations here and there. That's common sense.

But I would always look at my product and think how could we change it? What is changing? What is AI changing fundamentally? And what is the big revolution in this space? And I think there's a lot of things which you can think of in very many verticals, in many SaaS applications. Because it can change so much, right? And that would be my first thing. Let's try to generate the vision of what can be changed and how does it change the world?
Sebastian Zureich: Okay. You're basically saying let's envision that we build towards that, even if it's not yet a reality, but basically based on your assumption that it will happen.

Franz Faerber

Yep. Okay. Exactly.

Sebastian Zureich

And then my last question would be maybe you go back to the day you decided to actually really do it, leave SAP and become a founder of Everest to build what you're now building. Knowing back then what you know now, what would be the advice to yourself?

Franz Faerber

You know, first of all - and I was asked a few times already - what would I do, first of all? And that's not the advice to that point in time. Because at that point in time I would not have been able to change it. I would do it much earlier. That is my point.

You know, when I look at from the age perspective, that was really funny. When we started to start Everest, then I had an article in the Frankfurter Allgemeine. There was a distribution of software founders and their ages and whatever. In my age, I didn't find somebody anymore, right?

So the point is, when you are in a big company, you always believe that this is your world. And yeah, you have to stay and if you go outside, you are falling into whatever problems. And this is, you know - and then also interesting to read in that context when Hasso Plattner left SAP, he wrote an article, had an interview and he said, "Hey, I was so astonished that out of SAP there was no other company founded which is competing to that."

And that I would tell my past, right? Do it earlier. Because this is so - it's helping your life and it's enriching your life so much. You learn so much more than being in a small function in a bigger company. If you can afford it, if your life is allowing you. And sometimes it's not possible. But I would always recommend try it out, even if it's failing, try it out. It's enriching your life and it's making you just more confident and just enriches what you're doing.

Sebastian Zureich

Taking the leap of faith earlier.

Franz Faerber

Yes. But actually I think it will play out well for you because now you've got given the second chance in a way that you can do it so much faster given what we see now. So it doesn't matter anymore.

Sebastian Zureich

It's positive. Exactly.

Franz Faerber

I really - yeah, good luck. I really hope that we do. But that was a little bit good luck, to be honest.

Sebastian Zureich

It's super fantastic to have you Franz. Thanks a lot. I really, really enjoyed this conversation. Thank you very much for your time, and I'm sure our listeners will also enjoy the conversation.

Franz Faerber

I hope so. Thank you. Thank you.

The views and opinions expressed in this podcast and transcript are those of the contributor and should not be taken to represent the views or positions of Hg or its affiliates.

Statements contained in this podcast and transcript are based on current expectations or estimates and are subject to a number of risks and uncertainties. Actual results, performance, prospects or opportunities could differ materially from those expressed in or implied by these statements and you should not place any undue reliance on these statements.

Orbit episodes

Latest

Orbit Podcast

The corporate immune system: Google Cloud's Daniël Rood on building Europe's first AI team

Episode details

Orbit Podcast

Skin in the game: Professor Neil Lawrence on vulnerability, accountability and why the next generation will thrive.

Episode details

Orbit Podcast

The 3 speed problem: Oji Udezue on CPO leadership in the age of unlimited engineering

Episode details

Orbit Podcast

Fevered determination: Building Zalos from zero to enterprise in 5 weeks

Episode details

Orbit Podcast

Trust, velocity, and building the Answer Engine: Dmitry Shevelenko of Perplexity speaks to Farouk Hussein

Episode details

Orbit Podcast

The long road to the last mile: Nic Humphries and Matthew Brockman reflect on 25 years of Hg

Episode details

Orbit Podcast

AI, Control Points, and the Next Wave of Vertical SaaS with Tidemark Capital founder, Dave Yuan

Episode details

Orbit Podcast

Refounding in the face of AI with Des Traynor of Intercom

Episode details

Orbit Podcast

A golden age of software engineering with Russell Kaplan of Cognition

Episode details

Orbit Podcast

Quick and dirty prototypes with Andrew Ng

Episode details

Orbit Podcast

A glimpse of the next generation: Zoe Zhao and Annalise Dragic of Azlin Software

Episode details

Orbit Podcast

Incubate, experiment and implement: the real business case for AI today

Episode details

Orbit Podcast

Risk-taking & resilience with Sukhinder Singh-Cassidy, CEO of Xero

Episode details

Orbit Podcast

Vulnerability as strength in business: Nick Mehta of Gainsight

Episode details

Orbit Podcast

Thousands of small experiments: Merete Hverven of Visma

Episode details

Orbit Podcast

The art of pattern recognition: Darren Roos of IFS

Episode details

Orbit Podcast

Do tech leaders have to be tech experts?: Elona Mortimer-Zhika of IRIS

Episode details

Orbit Podcast

The business case for AI: Brent Hayward of Salesforce, David Carmona of Microsoft & Nagraj Kashyap of Touring Capital

Episode details

Orbit Podcast

The greatest tech comes when we ignore ROI: Raghu Raghuram of VMware

Episode details

Orbit Podcast

Mastering the billion-dollar software playbook: Joe Lonsdale of 8VC & Eric Poirier of Addepar

Episode details

Orbit Podcast

What drives business quality in an era of AI and digital platforms?: Jonathan Knee of Evercore

Episode details

Orbit Podcast

LLM AI, the fourth pillar of software

Episode details

Orbit Podcast

Insurance, the O.G. Data Business

Episode details

Orbit Podcast

Sustainable IT and IT for Sustainability

Episode details

Orbit Podcast

Unlocking real-time behavioral data in SaaS

Episode details

Orbit Podcast

Why Tech is Deflationary in an Inflationary World

Episode details

Orbit Podcast

Data Science in Drug Development

Episode details

Orbit Podcast

You are only as strong as your weakest point

Episode details

Orbit Podcast

Volcano Cat Bonds and Other Innovations

Episode details