In this episode, Ali Raza, CEO and co-founder of Bevel, discusses the challenges of working with legacy code and how Bevel aims to provide solutions through AI-powered tools. The conversation covers the definition of legacy code, the importance of understanding business logic, and the vision behind Bevel as a company.
Ali shares insights from potential users, the approach Bevel takes to code understanding, and the competitive landscape in the software development industry. The episode also includes a demo of Bevel’s tool, showcasing its capabilities in navigating and modernizing legacy code.
In this conversation, Ali from Bevel discusses the challenges of legacy code in software development, the urgency for companies to modernize their systems, and the role of AI in facilitating this transition.
He emphasizes the importance of understanding legacy systems, the need for a fulfilling workplace culture, and the strategies for engaging with the developer community. The discussion also covers the implementation of Bevel’s solutions, data privacy concerns, and the evolving pricing strategies for their product.
Chapters
00:00 Introduction to Bevel and Legacy Code
05:59 Insights from Potential Users
08:58 Bevel’s Approach to Code Understanding
11:54 Company and Product Vision
14:52 The Future of Software Development
18:06 Demo of Bevel’s Tool
20:56 Navigating Legacy Code with Bevel
24:05 Competition and Market Positioning
26:50 Real-World Applications and Challenges
30:43 The Tipping Point for Legacy Systems
32:41 AI’s Role in Modernizing Legacy Code
34:36 Agentic Software Development
36:24 Implementing Bevel in Legacy Environments
37:30 Data Privacy and User Experience
40:11 Language-Specific Solutions for Legacy Code
42:42 Building a Fulfilling Workplace Culture
45:07 Navigating Early-Stage Startup Challenges
46:14 Community Engagement and Product Adoption
47:58 Pricing Strategies for Developer Tools
49:37 Final Thoughts and Call to Action
Takeaways
Legacy Code is a Massive but Often Overlooked Challenge
Legacy code, defined as code written without modern documentation and testing practices, is still the backbone of critical systems in industries like banking, insurance, and energy. Many enterprises struggle with maintaining and modernizing these systems, with trillions of dollars spent annually just on upkeep. The risk of key personnel retiring without adequate documentation makes the problem even more pressing.
Understanding, Not Just Rewriting, is the Key to Modernization
Bevel's approach emphasizes that the true bottleneck in legacy code isn't the code itself but the loss of business logic and application knowledge over time. Instead of simply transpiling old code into a modern language—often a flawed approach—Bevel focuses on abstracting and understanding the business logic, allowing organizations to maintain, modernize, or migrate their systems intelligently.
AI-Powered Code Comprehension is the Future of Software Maintenance
With AI-driven code understanding and visualization, Bevel provides deterministic insights that help developers navigate complex, undocumented codebases. Their product enables enterprises to proactively document, maintain, and modernize their systems in a secure, privacy-first manner, ensuring long-term stability and efficiency. As AI-generated code becomes more prevalent, tools like Bevel will be essential for making sense of both legacy and AI-generated codebases.
YouTube Episode
Spotify Podcast
Episode Transcript
Introduction and Company Overview
Rod: Welcome to another episode of the Chris Rod Max show. This week we're interviewing Ali Raza, CEO and co-founder of Bevel. Hi Ali, welcome. Great that you're here with us today.
Ali: Hi Rod, really nice to be here. Thanks for the invite and I'm looking forward to the conversation as well.
Rod: So before we get started, let's start by defining Bevel in one sentence. How will you define it?
Ali: Bevel is an AI-powered tool that helps developers that work with legacy code.
Understanding Legacy Code
Rod: So legacy code, that doesn't at first glance sound like the most exciting topic for a startup. How did you get there? Let's talk a little bit about where you were and how you're now. What's your background, your path?
Ali: Yeah, sounds good. Maybe even before that, I should define legacy code because unless you really know what it is, it's very hard to understand. In very technical terms, legacy code is code that doesn't have test coverage, but that doesn't really mean anything. For the layman, legacy code is basically code that was written in a time where code hygiene was not a thing. Imagine you work in a company and you have a code base that has millions and millions of lines of code.
You have no idea how things are written, how they are connected, because everyone who wrote it has left the company or retired, and there is no documentation. So it's very hard to work with such complex code bases. That's what we mean when we say legacy code.
The Birth of Bevel
And you're exactly right - it's a very niche, very specific problem. And we actually came across it very accidentally. The way Bevel started was it was very team first. I come from CDTM - Rod, you're also an alumni of that. My other two co-founders are also from the same class there. We basically started very team first. We said, we have very complementary skills, we want to work together, and we want to start a company someday. But we had no clue what it was going to be about.
What we did was we did hackathons in Munich. Every other weekend, we'd get together to do a hackathon. And at one of those hackathons, my co-founders actually built a code understanding tool. It just parses the code and visualizes all the dependencies. Then we got invited by an insurance company here in Munich. They asked us to present the idea to the team and they said, "You know what, we have this very large monolithic code base and it would be super cool if we could use something to bring understanding to it."
And we said, okay, sounds cool, but we don't want to just build for you, we want to build something bigger. We talked to more people, realized it's not just them, it's a huge problem in many different industries. So that's how Bevel was born.
The Scope of Legacy Code
Rod: Very good that you define what is legacy code because not everyone knows that. Whenever I think of legacy code, I think maybe somewhere in some bank, there is something that was written back in the 60s. And now it's gone completely, not only has the person retired, but there is no more any way to just understand what's going on. But yet this is powering maybe some important system and nobody can just go and say, hey, I'll shut down this button and then maybe replace it because it's not even clear what's the logic.
Ali: 100%, 100%. Every time you swipe an ATM card, think 95% of the time there is some legacy code in the background that's being executed. So our modern world is kind of running on the shoulders of legacy code in a way.
Early Development and Customer Discovery
Rod: And so you're also mentioning here, so CDTM for those who do not know is a program based in Munich. It's a study program with a focus on entrepreneurship. And you basically met your co-founder at this hackathon. So you had this tool that can visualize code. I imagine that then, this insurer looked at it and said, hey, it looks exciting. Were you already expecting what you would see, did you already know at that time that this could help with legacy code, or did that come once you were in there and saw what's going on at that company?
Ali: I think we were very much, because it's a young team, we just thought it's a cool tool that would help with any code base. So even a smaller, not legacy code base, can use some kind of understanding. That was the kind of framing. But then we saw this code base, and then we talked to more people. We did more research. And we realized, this can actually be used for a huge problem that is very pertinent and very persistent across many different industries.
In the beginning, we were quite naive about it. We were like, no, it's just a cool thing we built over the weekend, and we can use it for our own code base. And then I think it was more serendipity that we came across the problem itself.
Market Size and Impact
Rod: When you try to quantify it, when you try to put it in numbers, how would you define how relevant is this problem?
Ali: Very, very big numbers. Firstly, if you really look at legacy code itself, there are stats that out of the top hundred banks, 92 of them still have some legacy code on COBOL in the mainframe somewhere. Even all the really cool banks with really cool front-ends - everything that is user-facing - but a lot of them still use mainframes for batch processing.
Almost 80 to 90 percent of all Fortune 500 companies have the same issue. They're still running software written a long time ago, and there was this number - I think it was like $1.73 trillion that every year is spent on just maintaining legacy code. So it's a huge and very persistent problem across industries. Banks is just one example. You can think of banks, insurance companies, automotive, energy. So all of the tried and tested industries, they all have the same problem.
Customer Insights
Max: Just a quick question, just to jump in there. Based on your conversation with some of the potential users of Bevel, what was the most interesting insight that you got from them? Because I mean, you built the tool trying to understand legacy tools, trying to understand code and legacy code. What was the most interesting insight you got from some of your potential users?
Ali: Yeah, so I think the most interesting inflection point for us was that it's actually not about the code. We started with the code itself. We said, code is hard to... COBOL, for example, is a... For anyone who doesn't know, it's a language that's mostly used in banks. And we said, okay, it's hard to understand and code understanding is a huge bottleneck. But then we realized that's actually not the problem.
Code is not the problem. Neither is it the solution. The code is trying to do something. And this is what Rod already mentioned - it's the business logic. The code is trying to accomplish something. But in many cases, that's lost. So people who know what the code was written for are not there anymore, and there is no documentation.
So it's actually this higher abstraction of understanding - what is the business logic, where is it implemented? And if I change something in the code, will I break some critical business logic? That's the more important or harder problem to solve. COBOL itself, the language, is super easy to understand. It was written kind of more for business people actually, so it's very descriptive. You can find developers - if you go on LinkedIn, you will find a lot of developers looking for a job for COBOL. So that's not the bottleneck. The bottleneck is understanding the application knowledge that is lost.
Product Functionality
Rod: So then therefore the idea is to try to create some sort of documentation for this code. You mentioned that part of the initial concept was to create these diagrams that will visualize the business logic for the code. So is it maybe a little more focused on helping get an overview of what it's doing from this perspective, or is it more focused on moving from this older legacy code base to where something is modern and sexy?
Ali: What you said is the former one, but I think by definition that helps the second thing that you mentioned. The first thing is what is the business logic? Where is it implemented? And that's firstly a UX problem as well. It's a technical problem because firstly, it's very hard to just get that from the code itself. You need a lot more sources. You need something like a data dictionary, for example, that most companies don't have. So you need to enrich and give more context to the tool itself to really understand what is the business logic and then where it's implemented.
The way currently we do it is we have this one table where all of the functional requirements, all of the business logic is stored. Then we have these diagrams that help you trace through the code where it's implemented. Then we have this code lens that's in the code base itself where you can just click and see what is the documentation for it. And the documentation is always up to date - if you edit it, it stays that way and it remembers that.
It's always up to date. But that's what we're at. And then from there, you can go two ways. You can say, I want to just maintain the code - so I understand the documentation, I can maintain it. The second one is you say, OK, I want to modernize it or migrate it. Because for migration, usually what people try to do was they try to transpile the code. They said, we have this COBOL, let's translate it to Java, which doesn't really work because it's two very different languages, two very different frameworks of doing things.
And now you have Java, but it still has the same problems as the initial code. So what modernization really means is you understand or abstract the business logic, and then you re-implement it. And that's the thing, that's the missing link. And that's where we provide the context, not just for people, but also for other tools. So you can use Cursor or GitHub Copilot to rewrite the code, and we give the context to those large language model tools as well, so they can use us and then re-implement.
To summarize, I said a lot of things - we focus on understanding, but understanding can be used for maintenance as well as migration and modernization.
Company Vision
Max: Great, think that's very clear. And in terms of, I guess, the vision for the company, is it to change all 93% of all banks' payment systems because they're horrible? Just saying. So I'd love to understand the vision as well.
Ali: There's actually two visions we have that are slightly different. So one is the company vision, the other one is the product vision. And I'll start with the company vision. The company vision is actually not about legacy code. So people always find this very surprising because if you go to our website, our vision is we want to make Bevel the most fulfilling workplace to work at.
And the idea behind that is traditionally, companies always wanted to maximize shareholder value. So they said, let's do everything that we can to maximize shareholder value and increase profits. Then there was a second wave of companies like Amazon that came around and they said, it's customer first. We can sacrifice short-term profits for long-term gains because if we take care of the customer, the profits will follow.
And we took one more step and we said, let's take care of our team. If you have a very fulfilling workplace - and by fulfilling we don't mean that every day everyone is very happy and cheery - it's more that everyone feels fulfilled to show up to work every day and they feel like they're doing impactful work. If we have that in the team, we can take care of the customers and the profits will follow.
So that's the company vision. For the product vision, Bevel is a product that we are building and the product vision is we want to take on all legacy code in the world. There is a lot of that, but in the long-term future - like really long-term future - we want to transition or actually leverage what we already have into code understanding.
Because the way software development is going right now, a lot of code generation would be commoditized, at least in our view. So there would be a lot of code written by AI. You would have fewer software developers who would work on a higher level of abstraction to manage and maintain this code. And because a lot of this code will not be written by them, they will need understanding.
So that's our long-term vision. Firstly, help legacy and then use the same technology, the same product to go into this - how can we help developers understand code much better that was not written by them.
Future of Development
Rod: Interesting. Before we go to the demo Ali, I'm wondering, so you're basically saying there will be less and less developers. There is also like counter argument that people are saying hey because now it's getting so easy to write code through AI, pretty much everyone will become a coder. So just like we are writing now an email, people will write programs and therefore it will be that all of a sudden everyone is a developer. Do you think that this will also happen or when you say there will be less developers, you mean professional developers? How do you think this will develop?
Ali: Yeah, I think let me correct myself a bit. What I mean is less developers per application. So it will take less developers to write, maintain, and run an application. Maybe there will be more applications and hence more developers overall. I think it's very hard to make that call right now. But for one application or one company, there will be less developers because writing code and generating code, all of those things will be already much easier.
So that's why we think code understanding is the thing, because a lot of this code will not be written by them, and they will need help understanding and maintaining that code. Yeah, I think to close the loop, I think it's very hard to make a call right now, which way it will go. I think maybe everyone will be a developer, but probably writing an application and running and maintaining it will be so much easier. We'll just require a different level of thinking and abstraction. The role of a software developer will just evolve in a way.
Market Opportunity
Max: Yeah, I think just to add on to what you were saying, I think the thing about AI is we don't really know what will happen every three months. Some deep sick will come again. Maybe the next one is sick deep. Who knows? The funny thing is, I guess, you know, there is an opportunity on the legacy code base, right? If a lot of banks are still running or a lot of larger companies really still running on legacy code base, I think there's a huge opportunity.
Even from there, if you were to just try to modernize some of those, because they are critical infrastructure in which you can't go down. I think, I don't know if you saw, I think over the weekend, Rod, in the UK, Barclays obviously went down. Yeah, so I can see how a lot of the banks would jump on this, right? Just try to help themselves to be more resilient, not just for themselves, but for customers and also regulators asking for it. So it's quite interesting.
Product Demo
Rod: And I'm sure that for many in the audience this is definitely a massive problem, but I feel that from an audience perspective, especially those who don't work at a bank or aren't reading code, they might not really realize how relevant legacy code is. So I wonder if you can show us how it looks in practice. I don't know if you have some legacy code database or that we can see how we can go from this legacy situation, this chaotic code base towards something that is easier to understand.
Ali: I wish I could show you the ones that we're working with right now. So there is one which is five million lines of code. And I remember we got on the meeting with the company and we were talking and I asked them, can we use some documentation that you already have to benchmark our performance? The documentation we generate and the documentation you already have to compare them. And I remember they started laughing and they said, there is no documentation.
So there's 5 million lines of COBOL with no documentation. But most of these code bases are proprietary and closed source. So it's very hard to find them unless you're working with those companies. I do have a small pre-recorded demo video that I can pull up and show around if that's interesting for you.
Rod: Yes, it will be very interesting just to see because I also have many questions surrounding the development of product itself, given that you're working with code that was written decades ago and it's not, say, like the popular programming languages of today that there are so many resources online available. So if you have any demo walkthrough, please go ahead Ali.
Ali: I have a very small demo recorded by my co-founder Juan. He's our genius on the product presentation side as well. So I'm going to give the mic to him. Let me know if you see my screen.
Rod: Yes, you can see the screen.
[Demo presentation occurs]
Product Features and Technology
Rod: That's really good to see and have an impression on how it all works in practice. And earlier in the video, we're looking at basically an interaction diagram. So the idea is that here, the user can understand the logic behind, or does it just help document it better? So how do these visualizations play a role, especially because you mentioned earlier that you started pretty much as a tool to visualize code?
Ali: Yeah, so the diagram you saw was a sequence diagram, so it shows how data flows through the code base itself. And there we have actually a UX problem to solve, which we are solving, which is even if you visualize everything in a code base that has 5 million lines of code and I don't know how many functions and how many classes, it's very hard to give the right context to developers because you just get lost.
The goal is you have this documentation, but we still want you to be able to navigate the code in a way, to understand how things are connected to each other. So that's where the diagrams come in, because there's more visual way of understanding how things are connected, how data flows, and all of those things. And then you only see what's very relevant to you. And so one of the fronts we're working on is how can we make this much more easy to navigate, much more relevant for exactly what you want to do.
So if you have some very specific task in mind, you only want to see certain things. You don't want to see anything else. And how do we show you the right thing? So that's a UX problem we have. I think one more thing to mention here, which differentiates us from other tools - so there's some other tools just for code understanding, they just have this one feature that we have, diagram generation. They are not deterministic. So what they do is they take the code base, they try to feed it into an LLM and ask it to generate a diagram, this is not deterministic. So if you use a different model, if you use it twice, it might give you different diagrams.
What we are showing you is 100% deterministic. Every single time you see the same thing. And that's because we are leveraging tried and tested technologies. So we're using static code analysis. We're using a language server from VS Code, which means that all of the diagrams, everything there will always be the same.
Competition and Market Position
Max: Ooh, I think just while you're talking about that, I was thinking about competition-wise, you did mention VS Code, and I know quite a lot of large enterprises have some sort of static code analysis. A lot of times, I think they do it for security reasons, but I'd love to understand how do you think about competitors in this space. Sometimes it could also be a moot point because things move so quickly. But just love to hear how do you think about this.
Ali: Yeah, so firstly, I think our biggest competitor at least was just companies doing nothing about this. But I think now we are at this inflection point where a lot of people are just leaving the company - the developers in these companies are just retiring in the next couple of years. So they have to do something about it.
The second one is actually consultants. So there's a lot of IT consultants that actually do this, right? So they do modernization, migration, also sometimes maintenance here and there. But they're very expensive, firstly. It takes a lot of time for them to understand it and then even migrate it. So it takes at least a couple of years, five to 10 years. And by that time, the code is legacy again, because your own developers don't really understand it anymore.
So that also doesn't solve the problem. It just puts a patch on it. And we are also leveraging them - so we see them as our partners in a way. We basically use the consultants and we use them as a distribution channel because we also help them understand the code much faster.
And then we have all of these tools that comes to everyone's mind - GitHub Copilot, Cursor, everything, right? But they're very good at code generation and code understanding. But everything before that, like understanding of the business logic and all of those things is very hard to do and it's a very different problem. So we are very complementary to them.
If we can abstract all of these things out, and we can help companies build these things, this is the missing link between then using Cursor or GitHub Copilot or something else to generate new code. Then we have the static code analysis tools, like Sonar, for example. But what they do mostly is metrics or code quality, all of those things. And they're not really focused on understanding of the business logic.
Then of course we also have code understanding tools. There's also some YC company recently. They're mostly doing non-deterministic generation of diagrams from code to help you understand it. Because deterministically drawing these diagrams is not a trivial technical problem to solve, especially for large code bases.
That being said, I think at a startup we have the mindset that at least 20 teams are working exactly on what we're working on while we're working on it because the space is so interesting and it's ripe for innovation. For sure there's a lot of people working on the space as well. And one of our strategies is also to be faster than them. And I think distribution is the biggest bottleneck. So we want to get to the enterprises, get to the customers as soon as we can with a really good product that helps them.
Real-World Examples and Challenges
Max: Yeah, I think one good thing you have going for you is that today a lot of all these larger organizations are not doing anything with it in a way. So helping them to understand those legacy code bases, I can see the value of this. I mean, I have a story to tell, right? Like on this, I know there is a very huge critical system that's running a lot of the financial services in the world. It's actually run on this old language called Toptop.
So what happened is when they bought it, they wanted to just translate it. They literally just used a translator tool and turned it into Java. And let's just say it's not pretty. Just plenty of problems after problems after problems. I can see how your tool can just drop inside. Look, this is how it works. And not to mention, people tend to write their own code on top of the code. I was like, god, what are we doing here? So as I can see, there's a huge, huge opportunity. Exciting.
Ali: Wow, yeah, 100%. And I think people also underestimate, when we say legacy, people underestimate how legacy we mean. And that's why a lot of these questions come around using other tools like Copilot for this. I'll give you an example, actually. So yesterday we were talking to this company that's basically migrating a core banking code base from COBOL to Java as well. And they have tried all of these transpilers, right? And they don't work because they want to keep the same way of doing things.
They just want to understand what it did and now re-implement it so it interacts with the database in a different way, but implement it in a different way, right? And they also tried, I think, something from IBM, Watson X is called, that also does something like code refactoring automatic. Also did not help them. So when we say legacy, it means really, really legacy.
And one of the problems they have is the code base has many different symbols that it's very hard to define them. And usually you have a dictionary - so you need to have a data dictionary that defines, OK, if this symbol is used, this is what it means. It's not standardized. It probably is different for every company as well. And all of these tools don't really have this context.
So the way we are doing it is we're also helping them create these data dictionaries on the side and then use it for our tool to help them understand it. And this is, let's say, another moat that we have, that when we say legacy, we actually really mean legacy.
Historical Context and Timing
Rod: The problem of legacy code has been around now for decades. I remember, like in the late 90s, there was a discussion of Y2K, all this old code will not be able to adjust the date for the new millennium. So as a problem, I would say it has been known for quite some time already. And I wonder here, when you speak with companies, what's their succession plan or the solution to this?
So you were mentioning that one of these is, for example, consultants, maybe like offshoring. However, do companies have an idea in mind what to do with it? Because for example, Max was mentioning so many important systems are still run in programming languages that are by now many decades old. Even if we think something like Java, Java is from the early 90s, but by now it's starting to show its age. So therefore I wonder here, what are companies doing? What are they telling you?
Ali: Yes, you're exactly right. So the problem of legacy is as legacy as the problem itself. So it's quite old. And so the question comes from there, why now? Why is now the time to act? And there's a couple of answers to that.
The first one is, finally the problem has hit the tipping point. And an example for a bank would be that most of the people working, that know the application, are about to retire. So I was talking to the CTO of a bank, of a large German bank, and he told me there's a core module they have - only two people understand it. The only two people have understanding what's going on in there. Both of them are going to retire in the next one or two years. And they have no plan for that whatsoever.
And this is not just them. It's everywhere. There's examples of companies bringing people back from retirement, paying COBOL developers who understand the application, paying them a lot of money to just come in as a contractor and try to still run those systems.
Secondly, we finally have the technologies. With developments in AI, we now finally have the technology. So with static code analysis, you can only go so far. But now we finally have the technologies to come at the problem. So we have now the capability to retroactively document these systems, create some kind of understanding around it, which we didn't have before.
And I think thirdly also, banks and all of these companies face a lot of competitive pressure to be lean and to be competitive with other companies. And these software systems slow you down. It's very hard to add on top of that. It's very hard to extend functionality and all of those things. And all of these companies, they want to be agile and they want to be competitive with others.
And I think finally, it's like at the end of the day, even within companies, it's people, right? And one of the things that CIOs, for example, banks have on the top of their head is, what do we do about AI? I don't want to be the person who does nothing about it when everyone else is doing it. So there's also that around it. And all of these together, it paints a very compelling picture of why now is the time to act and do something about this.
Product Implementation and Data Privacy
Rod: Once a bank, for example, has understood, hey, we need to do something with this legacy code, and not only that, but also AI is this powerful tool that will help us - how do they go about implementing Bevel? So they say, hey, Ali, we want to have Bevel in our organization. Is this plug and play? Because I can imagine that for these legacy systems, they are running on very old hardware. I don't know, if one is lucky, Windows 95 or something, there is no easy way to access it. So I find maybe difficult that it's just I come with a USB stick or I can just download it from the internet. What's the process or the rollout for Bevel?
Ali: Yeah, so it's very simple. And so the whole idea was, let's make it very simple for these companies to use it. And secondly, let's make it 100% around data privacy. Because banks, if you have a proprietary code base, you don't want to share it with anyone else, right?
And so the way you do it is very simple. We send you the extension. You download it as one developer. You analyze the code. So it's a VS Code extension. You unzip the file. You run the extension on VS Code, and then you can just share it over Git with all of the other developers in your team. And that's about it.
And the cool thing is nothing leaves your computer. So if you're running a machine, nothing leaves it, not even a single bit. So we also have one version that comes with its own small language model, which means that everything just runs locally on the machine. Or you can just use maybe an Azure hosted LLM if your company has one. Otherwise, everything just stays on the machine, all the code analyzed. We see nothing about it. So it all stays within the company's premises.
Product Development and Feedback
Rod: And now that you're mentioning that so you basically give the extension everything is encapsulated so there is no data transmission you're not really seeing any logs whatsoever of usage here how do you make your product better? So how can you improve it if traditionally something that software has all type of logging and data transfer and so on they are sending so much data to the provider but in your case this is airtight and therefore you do not see anything, but you also do not see how people are using it while they are struggling.
Ali: Yeah, so two things. I think we have to do, or we're doing a lot of customer success, because I mean, already we're startup, right? So we're working very close. So there's two things we're doing. One is just more qualitative slash quantitative feedback. So let's say once a quarter, or I don't know, once every month, we basically work with the developers and we say, OK, what did you struggle with? What was your workflows? All of those things.
And secondly, we store the metadata. So the metadata is nothing to do with the code itself. It's how did they use the application mostly. So it's about the UX of our application, in a way. And we store it on their file, on their computer, right? And we can just request them afterwards. We say, can you look over the file? Look through it. If there is anything proprietary, you can just take it out and just tell us the metadata of how you're using the application, basically.
Programming Language Support
Rod: Are you specialized in any programming language? I can imagine that when one thinks of legacy code, there is so much out there. Have you said, hey, we will just target exclusively couple deployments or maybe like Java legacy deployments or something specific? Or you say, hey, any language we can support?
Ali: Yes, so we are not language agnostic. And the reason for that is every language has its own nuances, its own idiosyncrasies. So that's why we, for every language - so we're using the language server from VS Code. But for every language we have to do some customization. So some things that are just done differently in different languages.
That's the short answer, that every language is different, so we have to have customization. And anything that is agnostic of language is not good for any of those languages because it's very general.
And then what languages we start with? We basically let the market dictate us. We said, OK, where are the people who need us? What languages are they using? And so we got the COBOL, the FORTRAN, and all of those, also the TypeScripts. And we're basically adding support as we go. So as we get customers, it just takes us one or two days to add support for the language and we just are adding more languages and that's our plan. We let the market dictate which languages we are adding support to.
Rod: Which are the most popular ones, which ones are where there is the most demand?
Ali: So it's COBOL especially in the financial industry - mostly like a lot of them run it on COBOL so especially banks and insurances. So I would say that's the bigger one. But also Java is quite around as well.
Company Goals and Funding
Max: Cool. Yeah. I can imagine that there are quite a few of COBOL lying around. They're like those dead corpses in your baskets that you have to take out. I guess just a quick question, Ali, you mentioned that, you know, the goal for the product is what we talk about. And then the goal for the company is to eventually become a place where people want to come and work. I'd love to hear your thoughts, what's your vision on how you can build that and also give us a little bit of sense of where you are from a company perspective, are you guys raising? And just wanted to understand that more too.
Ali: Yeah, of course. I always love talking about the vision. So like I said, the vision is to have this very fulfilling workplace, right? And fulfilling does not mean happy, like always happy and always cheery or some kind of fake positivity. It just means that everyone feels firstly fulfilled. So when they come to work, they're working on something impactful. They're feeling like they basically are using their capabilities to the maximum. So they're utilizing their potential.
And what that means concretely for the company itself is that if you're a manager within the company - we are right now three people, so we are managing ourselves, but once we have more people and you're at a management stage - that your job as a manager is not just are we making money and is the product good and all of those things, but also are the people who are working in your team fulfilled? So we want to make that a key criteria of your management success.
And what that concretely means in terms of values, I think it's because most values are easier said than done and I think a company's values are not what they say, it's what they do when they have to take a decision. So when you have to make a choice, do we do this or this? What do you do, right? So that's why we want to have this mindset. Whenever we come to this fork where we have to make a decision, we will always take the fulfillment of our people that we work with also in consideration and at the top and then everything else after that.
So that's kind of our thinking around it. And we really think that if we have that kind of a culture, that everyone has this - if you know the term, Ikigai - where everyone has this overlap. And you have a team full of those people that you can take on the world. That's our thesis there.
And in terms of where we are right now - so we're actually quite young. We started four months ago full-time and we got what for the Germans they probably know about it - it's called Exist Grundungsstipendium. So it's a scholarship from the government basically so they give you non-dilutive funding for one year to support firstly the founders and then give you some business expenses as well. So we raised 128,000 euros from the government in non-dilutive funding.
So that's how we're running the shop right now. We're in very early stage, so we now have our first pilot customers as well. And we're running the MVP with them. I wouldn't even call it MVP, so we even have a fully functioning product that works. We also have people sign up to our private beta, so we have quite some traction now on the product side as well.
And for fundraising, our goal right now is to after Q1, so after March, have some very clear-cut answers on the product vision and also direction, what kind of product are we building, and does that kind of product and that kind of market actually need a lot of VC funding or not, or do we rather just want to have an angel round and then try to bootstrap it from there. So these questions are still outstanding, and I think it will take us a couple more months to get more clarity on that.
Marketing and Customer Acquisition
Rod: You just mentioned Ali that you may have a waiting list for that. How did that come about? How do people find you? How do you penetrate these customers?
Ali: Yeah, so we started out very enterprise sales like very top-down. But in the end if you do very top-down we have something that the managers really like but no one really uses it on the developer level. And so especially for dev tools it's super important that you have a community around it. Developers they love it. They use it.
And so then we also started doing a lot of product-led growth, right? So we're active on Reddit in the VS Code community, active on LinkedIn. You might have seen some posts from us, also some videos. We're building a community around it. And these people, these developers, they want to use it and they want to use it for their work as well.
And because it comes with a local LLM, so they don't have to actually go to the manager and go through all of those processes. They can just plug and play and use it. And so the goal is let them also use it, give us feedback, and then help us build a case with the managers as well that this is something that's useful and brings value, right? So it's kind of like a sandwich approach of sales, in a way.
Business Model and Pricing
Rod: That's really exciting that you started with an enterprise focus, really targeting decision makers, maybe like CTOs, CIOs, and now you went bottom up, targeting the developers. So how does that impact your business model? Because I can imagine that, for example, in the case of addressing developers, one is charging by the actual usage or maybe by the number of seats. How do you price it?
Ali: Yeah, I think you're spot on with that. So we have to balance the, let's say, community goals with the revenue goals, right? So we have two tiers right now. One of them is, so it's an open core model. For those who don't know what open core is, it means one part of the software, of the solution is free for use for anyone. And that's for individual developers, or a couple of people if they want to use it. And they can just download the extension, use it for free forever.
The second one is the license tier, which is enterprises. And there we have a custom pricing, right now is based on, like firstly, we do this onboarding pilot project, right? Because a lot of it has to customize to their workflow and their code base. And then after that, it's basically a subscription. And right now, we are pricing based on the number of developers. So how many people in the team are using it.
But we will actually switch this pricing sometime in the future, because our thesis is that charging based on the number of developers is a losing battle because the number of developers in one company will for sure go down. So you're basically undercutting yourself in a way. And so we want to transition more to this value-based pricing - how much value we're providing and how much can we actually then skim on top of that. But to really figure out that value, we still have some way to go. So we are slowly transitioning from the seat-based pricing in enterprises to more of this value-based pricing in the very near future.
Closing Thoughts
Rod: If there is a message that you want our audience to get from this conversation, what would that be?
Ali: A lot of messages, but I'll start with the first one is for anyone who works maybe in banks, insurance companies, large enterprises that might suffer from the symptoms that I talked a lot about during our conversation today - if anyone suffers from that, or if you know someone who suffers from that, reach out to me. You can find me on LinkedIn. I think Rod probably will also post a link somewhere or just follow our page. It's called Bevel. And you can just reach out to us. Always happy to talk to you.
And also if you're a developer and you also want to give it a try like I mentioned it's for free so you can just always download the extension. So feel free to reach out to me, always happy to share it with you and walk you through how to use the product.
I think that's the one message and I think a lot of enthusiasts also probably watch the podcast or listen to the podcast. So if anyone is watching and listening to it and is on the fence of whether to start a company or not, I always say this, always start with the why. So if you have a very strong why of you want to start a company then I would highly recommend it. It's a very fun ride. There's lots of ups and downs, but you learn a lot of things. And it's a very transformational journey.
Rod: I must say that here in the show, I know someone who is in the space of needing legacy, support for legacy software, innovation and so on. So you're in the right place, Ali. And if there are others who also feel in the same way, how can they find you? Where can they look for you?
Ali: So like I mentioned, you can follow us on LinkedIn. We are very active there. So we post all the product updates, everything there as well. We will very soon launch on Product Hunt as well. So stay tuned to that. You'll hear about that also on LinkedIn. You can also stay tuned to our website. If you want to join our wait list, there is a link in the website that you can just sign up to. And of course, you can always add me on LinkedIn as well. I'm very happy to stay in touch, talk about anything, also legacy, AI, future software development as well, but also in general. If you want to talk to me about anything career oriented as well, always happy. So feel free to reach out to me on LinkedIn.
Rod: Yes, the URL, the address for anyone who knows is bevel.software, right? So not .com or anything, but .software, the original one.
Ali: Mm-hmm. Yeah. That sounds about right.
Max: I think I really like the vision of you trying to build a company that's fulfilling. One thing that I guess I want to take away is that there are a lot of ways to be successful. We all don't all have to do one way compared to the other, like where the world is going at the moment, as you can probably see in the largest economy in the world. So thank you so much Ali. This has been super insightful on the product as well as the vision of the company.
Ali: This has been super insightful for the product as well as the vision of the company. Thanks a lot, Rod and Max, it was really cool talking to you. So Munich is very early day, and I think also in London. So at least I can say my day is off to very good start. So thank you guys for that.
Rod: Thank you so much for joining us Ali and for everyone else remember to like, subscribe and follow us, join our newsletter, chrisrodmax.com Until next time.
Your Hosts
Follow:
Chris: https://linkedin.com/in/christinewang0/
Rod: https://linkedin.com/in/rodriveracom/
Max: https://linkedin.com/in/maxsontjy/
Social:
X: https://x.com/chrisrodmax
Instagram: https://instagram.com/chrisrodmax
LinkedIn: https://linkedin.com/company/chrisrodmax
Subscribe: https://chrisrodmax.com
Tags: #chrisrodmax #ai #technews
Share this post