Subscribe
Share
Share
Embed
The Value Creation Mindset explores the decisions successful leaders make to create real, lasting value for their customers, teams, and businesses.
Hosted by A.J. Singh, each episode features candid conversations with founders, CEOs, and builders who have been in the trenches, unpacking hard-earned lessons on leadership, technology, strategy, and execution. No hype. No shortcuts. Just clear thinking, first principles, and practical insight from people who have actually built things that work.
Full edit for Descript
[00:00:00] Hi I'm AJ Singh. Welcome to the Value Creation Mindset, the podcast that explores the principles behind the decisions successful business leaders make to create value for their customers and for themselves. We explore choices that create real value, what changed, why it mattered, the trade-offs and the proof.
Today, I am joined by, uh, Sulav Singh, founder and CEO of Vida International. In this episode, we will unpack the decisions that, changed the direction and trajectory of his business. The trade-offs made and the proof that it worked. You'll hear how sole reframed the real problem in African healthcare markets, why collections mattered more than capital, and how he evolved from industry specific lending to a building middleware orchestration layer between banks and payment rails.
[00:01:00] Welcome to the podcast Sulav. For listeners who may not know you yet, what's the problem space you are focused on and how did you get started? Yeah, great question. So we're, right now, we're solving the problem, or a lot of SMEs in emerging markets don't have maybe the resources or the team to make the right financial decisions.
And because of that they're less able to bank and access financial tools to support business growth. And so we're working with them and with the financial institutions to figure out how we can bring transparency to the market and effectively help these businesses grow. So of where are your customers? Who are you ultimately trying to create value for? Yeah. I think initially our customer base were the small and medium sized hospitals and pharmacies and the wholesale distributors. So effectively B2B within the healthcare [00:02:00] space. And at that time, the goal was to improve healthcare outcomes As we started lending a bit more, one of the things that came to light was a lot of these businesses were asking us how best to run their business, how to improve operations.
Really mainly to understand how best to become more bankable. And effectively we effectively to digitize a bit better so that, you know, banks and other financial institutions would be willing to give them money. When we realized this and we kind of started diving into it, we realized any business that's small scale and we, we classify small scale and, uh, teams with 50 or less, 50 members or less, those are the folks that could really help or could, could really use, uh, decisioning or our orchestration layer that can help them make the right decisions, uh, to, to help grow their businesses.
Now you're doing a lot of work in Nigeria, correct? Yeah. Yep. That's the initial market right now. Is Nigeria kind of the test case and then we wanna expand across Africa afterwards. What's unique [00:03:00] about the Nigerian and the broader African market that you find so compelling? Yeah, honestly, great question.
I think one of the things that we see in Africa and in Nigeria specifically, is a lot of the, the rails that we take for granted in the west. Um, like infrastructure, banking rails, even, you know, internet connectivity and power you have to build for intermittent, um, intermittent power, intermittent connectivity, uh, when you're building for the African market.
And I think while it might make sense the way to get around that, there's a lot of creative solutions for that, but that also leads to a lot of different types of problems that you have to account for. So designing for fundamentally unreliable networks is kind of a key aspect of Absolutely. And I imagine with, banking with financial transactions. That's, that's a unique complicating factor. I How many customers are you servicing now? So we have over, we have over 500 customers in the legacy business, which is the healthcare [00:04:00] financing, um, for Core, which is that Brex style platform that we've created. We have five pilot customers that are already onboarded, and then we have five more that we're sequentially onboarding over the next few weeks.
Talk to me about the, the thought process that you went through when kind of transitioning or refocusing on your core versus the initial market. You already had a foothold in what was the decision point or what happened to help you make that decision? Because it's a pretty strategic move.
Yeah, absolutely. I think honestly it was like three main things that happened. So first one thing we recognized was, as we were doing, as we were trying to automate everything in the lending space, and as we were automating the data collection process, um, for, for some of the folks that were, let's say, left tech savvy, we had to kind of explain why we were introducing certain products and certain technology to be able to collect certain data points.
As we were doing that, we were educating them on, Hey, listen, we [00:05:00] do this for this reason, we do this for this reason. And as that conversation kept on happening, we noticed a pattern where a lot of folks were very interested in the thought process because they recognize, Hey, listen, if I do this and I do it well, it seems like all there'll be a lot more, um, there'll be a lot more paths that'll be available for me, for me to access financing from different sources.
Uh, and so like that was, that was I guess, the first real feedback that we were like, this, this could be quite powerful for us. Second. We recognized one of the collections mechanisms we were going to use to automate was we were gonna start becoming, we wanted to become a microfinance bank ourselves. And the thought was, if we have them bank with us, we can sweep payments from the bank accounts with us.
So collections become, becomes a little bit easier. But again, with that, we recognized, Hey, listen, if you're an MFB, there's a lot of license friction and there's a lot of capital requirements. That's not our core competency. Like, is this the right choice? And then third, um, was as we were speaking to [00:06:00] investors, not even for investment, just, you know, we were having a lot of conversations here and there to keep people updated as they reached out to us.
We recognized the Brex style platform was kind of very attractive to folks, right? They kept on it like you could see a twinkle in their eyes, like, oh, this is quite interesting. Tell us more. And that's kind of where they wanted to dig deep. So I think for us, all three of those kind of reinforced each other to be like, okay, what's the proper way to actually solve for this?
Right? And that's where, I mean, we were playing around with a lot of different potential solutions for this. And as we, as we were going in the market and, and, and, and researching more, the Brex style model started popping up where we're like, Hey, this actually seems quite interesting. And this will allow us to do what we, we think we can do best, which is be customer obsessed, like ship quickly, um, but then add real value to the customer base.
Absolutely. So if I can paraphrase, you saw an unmet need in your customer base. You recognized that as [00:07:00] a pattern. So that was on one side, . You saw the huge amounts of friction and a barrier to entry to to become a certified what was the term you used to N-F-P-N-N-F-P on the other side.
And that kind of compressed you to looking at a middleware solution, which would, which would reduce the amount of friction that your current customer base or similar customers in parallel markets might be facing to excess banking services. Yeah, absolutely. So fundamentally, and, and so it was a friction reduction.
It half was friction reduction, half was identifying an opportunity that was larger than your initial one. Yeah, exactly. And, and honestly, it's like it was the combination of, like you said, one. The friction part was huge, right? Because even from a scalability standpoint, it becomes quite complicated, especially in markets, I would say like [00:08:00] in Africa, where regulation might not be as linear, if you will, from one territory to another, and it can, you know, fluctuate depending on what's going on with the administrations.
And so for us, we're like, yeah, one, this, this scales easier. But two, I feel like we're good at data and we're good at like, we're good at shipping, like creating products and getting it out to the customer a bit, a bit faster. Right. Okay. So it's like how we want, we also wanted to stay true to our core competency and we felt like this kind of allowed both two.
So is yeah, that, that was the third piece. Your confidence in your ability to innovate quickly and iterate. On these types, on these types of solutions. So on that side, what gave you that, confidence? Just your existing track record and pushing value out into the marketplace? Um, app solutions services or, or is there, I mean, you know, that confidence has to be based in a lot of trust in the core, in the core team.
How big is your core team and how did you attract such talent? Yeah, I mean, great [00:09:00] question. So I'll start with the team. So the team, the engineering side, the team is pretty small. It's seven engineers, but they're superstars, right? Our CTR knows what he's doing. He's kind of owned the product from inception, which honestly, I think people don't understand how much that, I think, how much weight that holds.
Like if you've been there since inception, you really can understand and drive, uh, you know, shipping and building a lot better, a lot better. Um, and so I think that's one of the, one of what my confidence a lot comes in the fact that our cton CTO's a superstar, he knows what he is doing, and when we ask for something, he can get it done.
Um, right. And then second, I would say it's a combination of, I think we've been tried and tested in the market, right? 20 24, 20 25. I think honestly 70% of fintechs in Nigeria failed market was tough. Wow. So I would say we've operated in very difficult conditions and we've come, come out the other side. So I would say I trust the team in large part because of actual evidence as opposed to, you know, theoretically we think we can do this.
And then lastly, and I think this is most important or not equally important, is we're, we're [00:10:00] oftentimes working against, or people see the banks or the pay stacks, which is like Stripe as their competitor. And, and here's the thing, banks in Nigeria are extremely regulated because default rates are very, very high.
Even if they wanted to, they cannot ship fast and their systems are archaic. If you play with them, like if you wanna download a bank statement, it's in PDF, right? It's like, it's very, very different. It's a low bar to beat that. And then the pay stacks, truthfully, they're doing a phenomenal job, but they need to be, we, we can be, um, we can be agnostic with, with the layer, but the pay stack, the payment companies need to be true to the layer that they've created, right?
The payment processing. And that's a challenging problem. And they're doing it across Africa and expanding. So they don't have, I mean, they might have the resources, but that's not their core competency. They're focused on that for, which gives us the opportunity to be able to combine exactly. And, and ship faster.
I get you, I get you. Yeah. The, the, having the father of your platform for, I mean, it's a little paternalistic term, but it's still, I think, correct. The, the, [00:11:00] the still with you is something which I, I think. Undervalued a lot of times. I mean, these days it seems that, um, well if you listen to some people expertise and experience doesn't, doesn't matter.
It's all commoditized. Why do you need experts when you've got a clawed or, or a chat GPT or Gemini where the
part of the success or what, what makes an engineering team truly effective and efficient and successful really comes down to team dynamic. And, and you've got yes, superstars, yes. But it's, it's sort of like you can't, if, if you've got a team of seven sled dogs, you need them all pulling in the same direction and.
How involved have you, have you been in, in, in, in, in kind of doing that? Has your CTO been been able to marshal all [00:12:00] the resources, push in one direction or have they needed you to kind of guide them a bit on that side, on the engineering side because yeah, engineers know how to do, how to always be extremely busy doing very important things.
That's the nature of it. And as an engineer myself, I mean, I get it. Yeah. But what, talk to me a little bit about, uh, about how you've, how you've harnessed that raw talent and the experience and the expertise on your team to kind of move the business needle, not just solve technical problem. Yeah. Great, great points.
So I'll kind and like, I'll jump into the question real quick, but I think one point that you made, you mentioned that I think again, I really, people do, I think undervalue like just being there from the beginning, it's like you don't, you don't necessarily, like if I went into a new company and I was asked to potentially drive, you know, strategy for something, I probably couldn't do it as well as I did at, I do it at Vitus because from inception I've kind of seen where it needs to go and I understand the business through and through [00:13:00] and it's like, so it's not necessarily me just being smart, it's me being smart in this particular situation because I've had a lot of experience in it.
And I think that to your point that's, it is invaluable. It's like that that can make anyone a superstar if they're like, if they have the drive right. Um. Then, and then to your point, yeah. With respect to the engineers being I guess, an engineer in, in my past life, I get what you're saying. So I think in the beginning, I would say 2020, I would, I was definitely much more involved in the engineering process just to make sure that I think we aligned on things.
Uh, but I think quickly within six months to a year, I think the CTO showed that he, I think I could fully trust him. Having said that, I do think engineers make the worst testers because they know the product well. Right. So we've purposely made it abundantly clear that, listen, one, you guys can't choose what features need to be.
Prioritize because what you want and what someone who's not as involved in technology want are very, very different. Correct. Um, right. And so it's like we've created certain silos or certain, sorry, [00:14:00] processes where we're ensuring that there's a constant customer feedback loop that's getting to the de developers and they're being told what to prioritize in the feature development.
Um, which in the beginning was some friction. 'cause they'd be like, oh, we think we should do X, Y, and Z. And we're like, look, great. Not to say that's not important, but it's not important for the customer. Yeah. No, it's, it's, it's the, that process is like putting a transmission on the engine, right. You can rev that engine, it'll burn through all your fuel.
But unless you can, unless you can put that power down to customers. It's a very, it's, it's, it's not just a waste of time and money, but it's a waste of talent. You know what I mean? Hundred percent. Because in, I've seen a number of projects that have not gone well, and we're often though folks who are called after that and have had to come in and, and help, and help and help [00:15:00] sort it out.
But I can't even think of a single case where the root cause was poor engineers, right? It, it's, it's, I haven't met an engineer yet who doesn't want to create value, who doesn't want to really make a difference and touch a customer. So a lot of times the guidance that I will, that I will provide is put your engineers in front of customers.
You wanna get somebody motivated, send them out into the field, or let them handle customer service calls that'll teach. What they should be doing. Right? Yeah. But the, the, the, so I I, I, I totally get you there on the, the interface between, you know, it's, it's like you're swimming in your space. You can see, you know, you're like neo in the matrix.
You can see what's actually happening, and it's because of your experience and your expertise and your insight and the fact that you've been soaking there. That's what, that's what you're passionate about. That's [00:16:00] what you are looking at. You are looking for those opportunities, and that's like other successful entrepreneurs see the same sort of thing.
Right. And that's one thing that, that, that helps you define the, the vector, the, the, the, the point in the sky. You need to move towards. In order to bring value to a marketplace in order to grow, uh, in order to create value for customers, the market segment and yourselves. Right? So that's the, that's the, that's a direction and full context.
And if you've got that paired with a really good engineering team who is good at execution, the interface in between is an area where, where we found a lot of folks are relatively weak, and that's in product design and the discipline about product development, not software development, two completely different sort of things.
Can you talk to me a little bit [00:17:00] about how, how you've tried to tackle that and strengthen the product design and, and, and, um, process of it? Not the software set, but the product engineering, the product design part of it. How have you addressed that? Yeah, honestly, it's a great question and I would say we were weak at it in the beginning as well, right?
But I think the benefit is, is when you're a small company, you get to iterate faster. That lifecycle's a lot quicker. So you quickly start realizing, oh, this is a problem. Right? Um, and so for us, honestly, it was a lot of iteration. So like initially there and, and, and I think understandably so, we would say, Hey, we want this, this, this developed.
Engineers would butt heads with us to be like, no, we think this should be done. And it's like, okay, fine. It's growing pains. I think eventually what we got to is we just had to start having weekly meetings with the cross-functional team, right? And so it was like, even though we were small, we recognized, hey, listen, there is, I think part of the frustration is coming because there's a lack of transparency.
And like you said, the moment the engineers understand the [00:18:00] problem, right, the problems that the customers are facing. It becomes less of a, what needs to be developed and more of a, oh, obviously if this is what the customer is saying, that is a, is a, is a pain point, or we're trying to tackle this issue and work backwards from how do we make that experience the best for the customer?
It becomes less of a he said, she said, and more of a Oh, okay. Yeah. Obviously he thinks need to be prioritized. Right. So we started creating, we created a, an engineering, uh, we created an engineer, sorry, we didn't create an engineer. We took a, an existing engineer and we added them to the customer feedback loop.
So they were in the conversations with the sales team and having those conversations on a weekly basis. The sales teams were doing it on a daily basis. Right. And then we also then had the cross-functional, uh, um, conversation where in that conversation, the sales team would come with the top priorities and the engineer would also, the one that was communicating with the, with the customers would come in and.
Give their weights on what also needs to be prioritized. The second that happened effectively, the [00:19:00] friction went away. Right? Because even the devs were like, oh, even one of our guys is saying, yeah, this is the right move. It seems like this is the direction that we need to go. And so, and, and, and I think that was a good learning for us in that, Hey, listen, it doesn't matter how senior or junior you are, if you can get people to understand why you're doing something, the path or the goal that you're trying to get to and bring transparency, everyone gets on board a hundred percent.
The, the, if you don't know the why, yeah, you're gonna be lost. I mean, you know, it's like, I, I always thought what you do is less important than who you do it with. And if you, if you couple, if you couple that with a clear why. That is understood, kind of up and down the organization. Things tend to line up and friction tends to kind of go away.
Um, the comment you, you made, you made earlier though, that, um, engineers make horrible testers. Uh, that's very true because they're very close to it [00:20:00] and it's, it's, it's, it, I I, I remember a time, a very long time ago when, um, uh, I've written a piece of code and it was working when I was, when I was using it, and I would literally get up off my seat and, and, uh, and I would have somebody else sit and when they would use it, it would break like four cap and then, and then when I would use it, it would, it would work.
And when they would touch it is like literally. Then it took us a few minutes to figure out exactly what was different. And I, and I forgot what it was, it was using a keystroke rather than a mouse click or something of that nature. But, but it, that's kind of an intrinsic fundamental issue with an, with an engineer.
So how have you solved that, that that quality issue then? Do you have separate testing organization? Um, how are you resolving that? Yeah, we honestly, it's kind of interesting. We've used the, and so like, I've never been in a, like a, like a sup, like a software company, like a Facebook or a fame. So it's like, I realize this is commonplace there, but we actually have testing companywide, right?
Because our [00:21:00] sales guys are, finance guys are definitely not as, as tech savvy as the engineer. And so it's like, it's not a perfect solution, but as they test things out and they use the product, right? Um, we, and, and that's another thing we've created certain, certain systems. In a way where our, our, one of our internal teams can be seen as quote unquote a customer, right?
Like when we werere, like for example, we had an LMS software that we needed to create internally, like early on, because in Nigeria there were no softwares In the US it was like a hundred thousand dollars a year. So it's like, obviously that's not a pragmatic solution. So we had them build it as the sales team and the risk team were the actual customer, right?
Because they had to use it as the customer would use it. 'cause they were helping with the onboarding and they were helping with the risk assessment. So it's like they're using it as actual customers. So when they were giving feedback, it was actually pretty decent. So then by the time it got to the customer, yeah, there might be a couple things here or there that the customers are asking to improve.
But for the most part, I would say 70 to 80% [00:22:00] of the issues were taken care of prior to it getting to the customer. That's a smart idea. So, so, so you, you, you have a release cycle where non-technical members of your organization are committed to helping to test and vet every single release and Yeah, I get it.
Um, and that's the, it it, it's a, it's a whole of company effort. It's not isolated to one group, it's not external. So you maintain ownership of it, but at a, a larger, broader level. Yeah. And it a little bit easier for us too, because honestly, part of the KPIs, if you will, for like our sales team, it's like, listen, everyone has to be onboarded, so it's like, you better be happy with this product.
And I'm, and I told them like, if you're not happy with the product, you have no one to blame but yourself. So like, test it. Right? And then like, and the risk team too, were like, listen, we need the risk assessment to be semi-automated. There's a manual component and there's an automated component. Like, if you're unhappy with this and you tell me you've tested it and you're happy like this [00:23:00] to you.
Right. So like, as we started driving ownership, um, it was great because then like we, we got into the weeds for some of these conversations, but I think it was very, very productive. Cool. Um, what have you got planned for 2026? You know, so, so, so you, you started out in the healthcare space, you, you saw some opportunities, some potential friction.
You identified this, this middleware play you wanted to go after you invested in it. That was the strategic mode. Um, where do you wanna be at the end of the year and, and what do you think the main challenges you are going to be facing are? Over the next, I guess, 10 months, I guess. Yeah. Uh, I, I mean, ideal scenario, if we, we want to close our round, that's probably number one.
We wanna close round by April 30th. Um, we're gaining contraction on that, so we're hoping it keeps on heading in that direction. The second we close, uh, two things happen. We want to scale to 500 customers within three months. And so what that means is we need to hire immediately, right? Because our [00:24:00] bottleneck right now really isn't demand.
There's a ton from the existing customers. It's more can our engineering team ensure that the platform doesn't break? Right? And because we're dealing with people's money, we, we, we don't wanna risk losing, like gaining, regaining trust if a system breaks is much harder. Well, regaining trust once it once is broken with anyone is exactly incredibly difficult.
So doing everything so you don't lose it. Certainly. Okay. So, so are, are you looking to, I mean, is is this a seed round an a b round? So this is seed. So we're raising for Vitus core, so it's like a $2 million safe. Um, and effectively, like I think 40% of it is going to engineers, uh, uh, like there's 20% going to the tech stack.
'cause obviously that's gonna grow as the, as the customer base grows. And then some for like office space, legal, some of the regulatory stuff. But really the main driver is engineering because we want eng, we don't want engineering to be the bottleneck and it definitely is right now. Understood. So, so on that side, I mean, you've got a team [00:25:00] of seven engineers now in including your, including your CTO and they're good guys, efficient, they work well as a team.
You have a proven trustworthy team. So, so, you know, your engineering team isn't, is isn't keeping you up at night. No. But the technical challenge you have ahead is, and you know, in, in my experience, there were really. When you're bringing to life any, any commercial offering and in, and, and, and in the FinTech space, this is more true than anywhere else probably.
Um, solutions has to be absolutely stable. You don't have stability, you have nothing. Once it's stable, it has to be scalable enough for your needs. You don't need infinite scalability. It has to be scalable enough for your growth curve. Once it's stable and it's scalable, it has to be profitable to operate.
If you're, if your cloud costs are too high, uh, it's not profitable, why do you even start? Right? So once it's stable and it's scalable and it's [00:26:00] profitable, the fourth thing is it has to be serviceable because whatever capability you have at, at one, at one point in, in a time. You're gonna need to find ways to continuously deliver incremental value out to the customer quarter after quarter, after quarter, after quarter.
And if that's not serviceable, if it's not designed, architected, built in such a way that you can bolt, bolt things onto it. If you have to rewrite it, if you have to rip it apart every time you need to make a change, that's then the serviceability is going to be a challenge. So out of those four, out of those four areas, stability, scalability, profitability, and serviceability, which is the most, which do you think is gonna take the most resources once you close your round?
What's the biggest challenges that you, that you think you're gonna need to solve? So I, I would say stability. And, and the reason why I'm saying that is we're gonna [00:27:00] over index for stability, right? Because to your point. Yeah, it's, it's, it's like, it's like I can the team do it with seven Sure. Do I wanna risk it?
Right? It's like, no. So I think we're, we're definitely gonna over index for it because again, also forget, forget trust in the us, trust in Nigeria or an emerging market, easy, even less place because fraud is more prevalent. Right. So I think for us, we want to just, we want there to be zero concern on the stability thing.
The rest of it, to your point, I am, I'm just very confident we can, we can deliver incremental value add, as you mentioned. 'cause it's critical because the guys that we're going against are slower. It's like there's a lot more bureaucracy and red tape, uh, with the banks and the pay stacks. And we already have identified a, like, I mean, for the last six to eight months we've been.
Nose deep talking to convers, talking to our customers to be like, what do you want? Right? And not just in healthcare, in a bunch of different industries horizontally. So we're confident we have a laundry list of things that it's gonna take us a long time to get to. That's gonna consistently add value, make the customers happy, [00:28:00] make the experience good.
So my thing is, okay, let's just assume for now that, that that feature list and, and the tools are the correct tools. It's like, okay, great. I know my team can deliver. So then okay, then if I'm confident they can deliver. In general, what do we wanna make sure, I wanna make sure that security and safety and stability of the platform is never an issue.
No, I I, I, at the end of the day, our job is to make sure that our customers sleep well at night. Whatever we do, that's our number one job. And, and on that front, if your solution, if your solution is unstable, I mean that's a red alert. Right. So, so the, the, talk to me a little bit about that because the, the, the, if, if the bulk of your investment is going to be in making sure you have enough capacity to address the execution of your, of, uh, of your plan and your vision.
Make sure things are, make sure things are [00:29:00] sta are stable first. Makes sense. And in your particular market scalability. I mean, you've got a little bit of a luxury of some time in Nigeria be, be, be, uh, 'cause there's an, there's a larger barrier to entry. So scale is less, less, less of a priority than stability currently on that side.
I mean, let, let me ask you the, the, the, the same question any investor's going to ask you before they write a check. Um, how are you gonna use ai? To, to help with this execution. That's a large open-ended question, and I'll, I'll leave it large and open-ended for you. No, that again, that that's a million dollar question and, and it's the right question, right?
It's like at this point, I think to be relevant, you, I think you need, you, we need two things. You need to leverage AI and you need to incorporate ai, right? And and to be successful. So for us, one, from a scalability standpoint, I'll touch that before I jump into this. Sure. You're absolutely right. I think.
But I think what we've identified is based on our [00:30:00] execution model, once the platform is stable, getting to Ghana, to Nigeria, any country where our banking partners already, already are, have a footprint, becomes very quick because it's an API backend configuration. Mm-hmm. So that's kind of why we're like, great.
Get it right, get it good. Then expanding it out will be, not that it'll be super easy, but it'll be much easier then getting the product where it needs to be. Understood. Then the second part is from how are we gonna incorporate it for the customers? That's the orchestration layer because we have access to the multiple data points.
It's gonna be like the BA deposit data, payments data, accounting data, POS terminals. We are creating an agent layer on top of that that's going to be helping with SME decision making. And the goal for us is, hey, listen, if you're a team of 50 or less, let's say you don't have a dedicated finance team, no problem.
You don't need a dedicated finance team. We're gonna cut costs for you. We're gonna allow you to talk to our A agent and it will tell you like, Hey, how much did you spend on marketing? Or How much should I budget on X, Y, Z? Right? All of those basic things that [00:31:00] a finance person could do for you, we will allow this to do for you so you don't have to worry about it.
So that's the first part. The second part, and this is we're already starting to incorporate this, like we definitely are gonna be leveraging cloud and like the, like we're, we're, so right now we're using GPT, but like sonnet. But I think we might be switching the cloud, but we are gonna be leveraging AI to code.
Because at this point it just doesn't make sense not to. Now, having said that, I think we're gonna be careful about how we do it initially, where it's gonna be very micromanaged with a developer right there, making sure that things aren't breaking. Because again, right, we're dealing with people's money.
We can't lose trust. But I think we wanna get to a point where we can start shipping and we can start having AI test, like a act. Like if we can give it like, Hey, this is your u, like this is your user profile, this is your, your user persona test as if you're this person. Like, if we can start doing some of that stuff, that it, and it actually comes back with very good feedback, which [00:32:00] apparently it does.
Like, then we need to start, we have to leverage that. Otherwise we can't compete. I'm, I am totally with you. I mean, you know, I've, I've been in the engineering space for, uh, well, you see all the gray hair, um, the, the, the, there are so many aspects of product. Development product engineering, and, and I differentiate that from software engineering.
Software engineering is lovely. It's an important discipline, but product engineering is next level. And when you've got zero room for error, I, I think you are right to take a bit of a conservative, uh, approach here. But at the same time, like the, the, we just came out of an AI summit, uh, last week in, in internally where, where our tech leadership team came together.
We unplugged for a couple of days, ripped through all kinds of stuff and, and, and made some, made some [00:33:00] decisions. But in the process, we un we, uh, we uncovered a few core tenants. You, you, you hit on something which is, you know, also one of our core values. I mean, trust is everything, is everything. When it comes to any relationship with a customer or your wife or your child or piece of code, or the car you drive or the plane.
You might, you might, you might, you might, you might fly in. There are some things that, where good enough isn't quite good enough. So a few basic tenets and, and, and over time, I mean I, I, I always try to identify timeless things, right? Because they make me, they help me make sense of the world. Um, one timeless principle that, that, that is immutable is garbage in, garbage out.
Absolutely. And that's true of AI and, uh, certainly, but on the, on. As you explore getting into coding with ai, we're doing the same thing. [00:34:00] If you, uh, a core principle we've established is you have to understand whatever code you push into production. Yep. I mean, at first, you, you, you, you, you kind of say this to any engineer in a different discipline.
If you're not in software, if you're a mechanical engineer, you're an electrical engineer, you're a manufacturing engineer, you're a chemical engineer, can you imagine a chemical engineer, um, saying, you know what, I'm just gonna create a new, a new, a new chemical product that really understanding it. I'm gonna define a new process and I I don't really need to understand it.
Yeah, no, that ain't gonna fly, brother. Yep. So same on the code side. So, but at the same time, it's like I. I found, and this is, this is true, and, and we're all on our, on our own AI journeys, right? We're trying to figure out how to leverage this technology to create more value for our customers. If you use that as a fundamental lens, say, listen, I've got, I've, I've to build a, a, a, a [00:35:00] stable product, a scalable product, a profitable product, a serviceable product.
If AI can help you do that, if AI can help you create more value and less time for less money, why the hell wouldn't you do it? But it's the if then it's a question of shifting to, okay, how do I do it? So as long as the ownership and accountability remains with engineers who you trust, you're getting them some help.
Wonderful. Right? And. There are lots of tasks that, that, um, can be accomplished in a more automated way with ag agentic ai when, uh, what's the latest term that I've heard? Age agentic engineering, right? Where you've got, you have agents that collaborate that, that, that you can have a swarm of agents that are collaborating that, you know, one is a qa, one has a QA role, one might have [00:36:00] a coding rule, a, a coding role on another, might have a creative asset generation role.
Each has their own separate contexts, but you can leverage them so they can collaborate with each other. It's a virtual worker. Right. And I've been struggling with this a little bit, but I, I came up with a con, I, i, I, I came up with a framing that I want to, I want to get your opinion on, because.
At the root of, of these AI models, and it, using them in a n agentic way simply provides the right management in infrastructure and superstructure on top of it. It puts guardrails around what each of these LM instances do, but, um, every LLM, uh, is a block box, right? If you look at how it's trained, it's, it, it is trained by providing it a input, seeing its [00:37:00] output, and giving it feedback.
Was that correct or was it not? Correct? Right. And the, the, they were trained at great expense on a variety of data. Every, every LLM with, whether it's provided by a cloud, uh, a cloud pro, cloud provider, or an open source provider, you, uh, um, and it, whether you are running locally or you're, or you're running in, um, a public, uh, uh, public cloud somewhere, these little things, the LMS at the heart of each of these agents, um, don't have any intrinsic knowledge and understanding of what good software practices are.
They don't know the laws of the universe. They've just been trained, Hey, if I see this input, this is the most likely output that I should generate. And that's not to denigrate them because they're hugely useful, but you have [00:38:00] to, uh, you have to be aware of what these things are trained on. And the public ones certainly.
Are trained on, on a whole lot of public data, public code stuff, you might have scraped off of Reddit or Stack Overflow. So just be a little bit careful there. But the, the, lemme get back to book two, my framing, um, because they are black boxes, they don't really have any values if we're gonna personify them, understand that these are little sociopaths, they don't have any values.
The other thing to understand is that currently, I mean every single LLM will hallucinate Yeah. To they will to some degree. And, uh, apparently right now though, with if, if, if, if given proper context, proper markdown, proper initial prompting, proper fine, fine, fine, fine tuning. They can work very effectively in certain roles.
For a certain period until [00:39:00] you get context rot and you need to REIT initialize, and they start, they, they start going off and I know there's, that's improving constantly, right? But my frame and my ask is like, uh, alright, if we're gonna personify these AI agents, I think it might not be a bad idea to think of them as sociopaths on hallucinogens at that.
That doesn't mean that they can't do effective or useful work, but you really have to control them and bound them and review what they do. But I don't know. Do you think that's an unfair framing? No, I actually think that's an extremely fair framing. In fact, I, I think at least as as LLMs are right now, or as agents are right now, I think the problem is they're at a point where you can become comfortable with them.
Once you become comfortable with them, you forget that they [00:40:00] are like, you do have to treat 'em, like you said, like a sociopath, like a child, because they can go off the rails very quickly because they're not that sophisticated. We're just, they seem sophisticated at times, but then if you interact with them enough, you'll be like, oh yeah.
It's like when you're interacting with a kid and you're like, the kid's acting normal for a little bit and then he, you know, eats some sugar and goes crazy. It's like, yeah, it's 'cause it's a kid. So it's like, so I think, I think the biggest problem is I don't think we're anywhere near a point where we, we don't need to constantly have guardrails and constant monitoring because you might be getting what you want 90% of the time, or even 99% of the time.
But like when you're building something for a customer base, that 1% is what's gonna break you. So you have to ensure that it's done and, and to your point, yes, it can't, like while the LLM is the black box, like you said, everything you build, none of it can be a black box. So you need to underst. You have to understand it.
And, and I, I think, you know, again, that's kind of a timeless thing and I, I don't know if [00:41:00] vibe coding is run its course, it will eventually do. So, you know, if you want to vibe code, uh, a quick, a quick prototype, nothing wrong with that, it's fine. Right. But I don't believe in throwaway code. I think I, I, I, I, it sort of sets a bad example and, um, yeah.
You know, I, I, I dunno if you know this, but we've been in the code generation space for, since we started the company. That's been the, that's been from beginning, our approach has been fully deterministic. Meaning any code that is, that, that is emitted by, by our, uh, uh, our tech stack. You can take to the bank, it's the same every time.
It's not like it comes out differently every time you hit the button and it's trustworthy, but at the same time, you know, so at this point I think we, I think, I think we've hit about 80%. So the commercial software product, we can automate about 80% and it's, [00:42:00] it is fully trustworthy, but that last 20%, it still takes a good chunk of time.
And we've been looking at how to effectively leverage, um, AI models and a gentech engineering to see if we can get from 80% to 90% effectively cutting our, our, the manual labor still needed to bring to life commercial software products. I even with our advanced, uh, advanced tech. Tech stack, I think we still have an opportunity to reduce the, the hand coded stuff by about half.
That's our target that, uh, we are reaching for. What's your target for your team? Yeah, I think that's a good question. And I guess I would pose a question to you before I answer. How are you, are you also leveraging a, like AI agents for the testing? Are you keeping that manual right now? Like what's your process on that?
Uh, uh, we are, we are moving in that direction. I think [00:43:00] QA is a phenomenal opportunity to, uh, to, to use AI agents, how effective they are. We're still exploring that, honestly. Uh, that's where we are on our, uh, on our journey. But if you look at the entire life cycle, AI is very useful when you're doing research and doing dis doing discovery work.
We are planning on, we are planning on leveraging a, a gentech AI to accelerate the design of products both at the entity model level, which is within our existing tools, wi, which is within our ex existing tool set. And, uh, and in the ux d design area also. Yeah, I can help with the design aspects of it.
The interesting thing is like the, the,
then it can help with the execution. So now again, a, a big chunk of that [00:44:00] execution is already handled by our tech stack, but there's a lot more that still needs to be done. And then once it's executed, uh, how can we automate the construction of additional unit tests? How can we leverage it to do additional integration testing?
How can we leverage it to do automated scalability testing? Right? How can we use it to, how can we, this other thing, we are trying to, uh, figure out how can we fine tune a model on our proprietary
knowledge base so that we can offer our customers access to the knowledge which is in, you know, our institutional knowledge, right? So we can more effectively answer, answer questions and help with [00:45:00] customer support. So there's an opportunity to leverage this in, in the entire lifecycle and the entire organization.
But the, the question that I'm, that I keep on asking is. How is this gonna create more value? How can we do it in a way that that maximizes value creation and minimizes risk? Because if an, if an AI agent that, that we create for a customer, so support, for instance, is providing the wrong answers, providing the wrong guidance, is that really gonna help us scale, scale out our value creation across the customer base?
It won't, but it's a direction worth investing in, certainly, and validating. But at the end of the day, the ownership of the quality of the stuff that any of us are building, that remains with us. Yeah. Until we're replaced by agents, CEOs, but don't do a better job. Yeah. No, I think, I think that's the right [00:46:00] approach.
Um, yeah. I, I think we're seeing something similar. Right. I would say as of right now, I think. At a, at a very, I guess very high level I'm seeing based on what's available, I would feel comfortable for one, a one engineer of ours to maybe handle one to two AI agents at max right now. And I would want, if, if we're gonna do that, I would want it done in a capacity where we're taking a AI agents and we're compartmentalizing what they're doing, making it like, making it more and more specific so they're better and better at what they do.
Right? Then I would say at, and I would only do that at a, at like one to two agents right now because I would wanna be testing it out to being like, what's working? What's not working? How do we make this process work for us? I would say once and again, these, these platforms are just becoming much better, much faster.
Right. Um, so I would say in about a year's time, I think each engineer could probably handle five to 15 agents. Normally, but if you've made it so each agent is doing a smaller subset of work, I would say you could [00:47:00] potentially make that, you know, 15 to 25 agents. Right. Because it's like, if the agents are more specific, my suspicion is they're gonna be better at that task because it's a smaller, smaller, uh, smaller thing that they have to be specialized at.
So that, that's kind of where we're heading. I honestly think we're gonna get to a point, even within Vitus, within a year, if everything works well, where, yeah, I mean, like, it sounds bad. I mean maybe from like a, you know, hiring dev standpoint, but yeah, one, one dev for like 10 to 50, 10 to 20 agents. So it's like that one dev is more managing it, testing it, ensuring everything is working well.
So then you should be able to ship really fast, right? You can have a, you can have a team of, I mean, again, I'm making up numbers, but you have 10 people managing 10. That's like a hundred team, a team of a hundred for 10, you know, so it's like, can we get there? I, I think the, it's a good. I hope you can get there.
Execution is gonna be much different. Well, I mean, here's the thing, right? Is is like the accountability still has to remain with the engineer. Yeah. And the kind of [00:48:00] pernicious thing about this, where I can see a lot of people, um, getting into trouble is we'll say, okay, you're responsible for reviewing the work of all of these agents, right?
So you'll have to review all these mer re uh, mer requests on a daily basis. Well, when you, when and you look at that and you see somebody's reviewing and approving a bird requests of 400 or 4,000 line lines of code and they spent eight seconds reviewing it. Yeah. You're really vibe coating at that point.
It's true. So it's, there's a, a limiting factor of. So that's why like the one thing that I'm, I'll, you know, maybe I'm the old man telling kids to keep off the grass, but you have to understand what you're shipping in depth. Yeah. Not on a surface level. 'cause if you don't, I mean, look, [00:49:00] stuff is gonna break it.
It does. We're, you know, I, I was, I was gonna say we're all humans, but I guess soon we might not be Right. But, but the, the, the, and, and that's another interesting piece. Hand coding used to be a bad thing. Right. Wanna minimize it. Honestly, that's why we scarred the company to automate as much as we could possibly do.
Let engineers focus on working on the things that create the most value. And hand coding was something to minimize with the inherent, with, with, with. Some of the constraints that are there, at least on, at least on current generation agents, and they've advanced a lot just even the last few months. Who do you think creates fewer defects?
Humans or these AI agents? They're, they are sociopaths on hallucinogens. Yeah. And, and again, maybe that's a little negative frame, but I [00:50:00] don't think I'm wrong. Um, so in that sense, if, if, you know, we've all heard human error, right? Oh, it's human error. And we do, we have all kinds of processes in terms of qa, it was all eliminate Cuban error.
Yeah. So it, so if you have fewer lines of handwritten code, that was a good thing, right? Less things to go wrong. But agents are not error free, not by any stretch of the imagination. Agents will. Readily duplicate the same chunk of code multiple times and it, it's gonna find your, it's gonna find its way in your code base.
And now you've got logic coded in four places instead of one. And each one might be a little different. So that's the danger that I see. And, and, and, and I think the a as long as, as long as we don't surpass the human capacity to truly understand what we're shipping, I think we'll be fine. I mean, do you think, do you agree with that or do you think, um, over con um, overly conservative on this front?
Well, no, I think, I think there's gonna be, [00:51:00] I think people are gonna go the opposite route as you, and I think that is the wrong route, but I think they're gonna get burned bad, right? Like you said. And I think because they're, 'cause I agree with you. So like, my, my thing is like for us, we all, again, we b based on just the mechanics of where we're at, we tend to be a bit more conservative on our approach of things, right?
So like, for me. As we start to incorporate ai, we are gonna be incorporating it at one step, at like a stepwise function, right? Slow. And then we're gonna, and we're not gonna do, oh, let's do a hundred and then step down to see what we can handle. We're gonna be like, we're gonna start with one, we're gonna step up.
And then there's gonna be a magic number where we can't, one, one engineer can't handle that many that much code, right? And we're gonna be like, okay, that's the cutoff. So if that's the cutoff, going forward it like, let's say that cutoff is five. It's like, all right, we're gonna need to make sure we have one human engineer for every five AI agents.
Great. We're gonna keep on doing that. And then like we might iterate and test that from time to time as the AI agents improve. But I think that's the right approach because again, like it, depending on what market you're in, it might not matter as much, but like if you're in a [00:52:00] market where trust matters, especially like when you're hand handing people's money, you can't afford to make that mistake.
But just like, just tell me something in which market doesn't trust matter. I mean, the markets that I would say trust matters less or I think the perception is trust matters less. It's like, like a, like a Facebook when it started out. It's like, yes, right? Like it's social media. Yes, people want it to work, but if you, if it's, if it's broken, it's like, it's more of an inconvenience as opposed to you get what I'm saying?
So it's like, and again, like, yeah, so it's like getting capacity like that. But I also think, I, I think most people are not gonna take that approach. Kinda like the 90 90 nine.com era. People, this is new. People are going to use it, they're gonna use it too fast too soon and shit is gonna hit the wall. I, I think you're absolutely right about that.
I, I, it's, it's, it's a little, um, you don't wanna be, you can't be overly enthusiastic, nor can you be pessimistic. You need to be. Pragmatic and, and the, and the filter that I keep coming back [00:53:00] to is how can we use this to create more value? And the, and the, and the, and the thing is like, you use these tools wrong.
It's very easy to create negative value. Yep. Right. Even inadvertently, I mean, I, I I, I had a case in the past where I, we had a project we, uh, had, we had resourced it and I made the, the, the stupid decision to add another resource to that, to that project because we had a new hire who wanted to get 'em wrapped up.
Okay, great. Let's do that. That screwed up the, the execution of that project. Adding a resource sometimes can add negative value for sure to group book to quality, to whatever else. If that's the, if that can happen with just human resources, it can certainly happen with ag agentic resources. So I'm, I'm, I'm, uh, I am still struggling with the kinda right.
Mental framing. I mean, are, I mean, there are some people who named their agents or some [00:54:00] people who are having relationships with their agents. I mean, it's like, it's like, it's like the movie Her Come to Life, and I heard, I forgot if this was either Open AI or, and or, or Anthropic. One of their models was obsoleted.
Rather than just removing it, they left it alive and they gave it a substack, uh, blog. Oh, I see. Say, Hey, we're gonna put this model out to pasture. So it's a little off, you know, you, you know what I'm saying? But it's, it's, uh, it. It certainly is a little bit wild, but I, you know, it sounds like you're really bullish on, on, on where you're headed.
I really appreciate you, uh, joining us on, uh, on this podcast to live and, and wish you all the best. I, I've, I've got one last, I've got, I've got one last question for, I've got one last question for you. You know, as, as a, as, as Stephen Coy says, you know, begin with the end in mind [00:55:00] and the end for him is, you know, kind of, kind of the end of his life, right?
That's what's the end point endpoint. And after reflecting on that a while ago, you know, I, I, I, I, I truly believe that our legacy will be measured by how well and how far we lift all those we touch. Know, at the end of this, what do you want your legacy to be?
Uh, I guess I'll split that into two questions. It's a great question. I think, um, you know, holistically, it's like we, I I do, we do want to, we wanna improve quality of life. And, and, and I think for us it's like being able to do that at the base of the pyramid makes the most sense. You'll touch the most people and I think it's an acute problem.
And you, if you raise them, like it does a lot for society as a whole. And, and so like, obviously that's something that would be helpful. And with healthcare and financial inclusion, we feel like, you know, we're altered to the problem can potentially impact it core specifically. And I think this is the part like we've been talking about.
I, [00:56:00] I was talking to someone very recently about this, like in the early two thousands, late 90 nines, like if you wanted to talk to someone in a different country, it was kind of a pain in the ass, right? Like you had to call someone, it was expensive. It was not commoditized. Then WhatsApp came and everyone's like, yeah, why can't we talk to everyone for free?
Like, it doesn't make sense not to, I think banking is the same. It's like, why can't we bank everywhere? Like when I'm going to Nigeria, if I'm going to Greece, if I'm going to India, like why can't I bank in a capacity that's seamless, right? Yeah. You have different, it's just like, so my thing is Nick, for, for us for core, it's like we are the middleware that can connect with any platform and then make it so that if you have core, if you're in the us, if you're in India, it's like wherever we are, your banking becomes as accessible as WhatsApp in a phone call, right?
So, like to me, I think that's where I wanna head. And as the world is becoming more connected, I feel like that's just a na natural progression and finance needs to, you know, get, get up to speed with some of the other technologies that are, that are around. Amazing. I I, I, [00:57:00] that's an amazing vision.
Appreciate that, man. I appreciate that. And I, again, I appreciate you giving us the, the, the platform to t to talk. This is a very interesting conversation. It certainly was for me as well. Alright, any final words? Uh, no, honestly, I think, uh, I want you to keep doing what you're doing. Giving founders a platform to chat is always great.
And I know you guys have a ton going on, on your own f uh, uh, startup. So it's always, I think it's always fun to chat with fellow founders to get their perspective and then, you know, feed off that energy and then go back to doing what you do. I appreciate you. Yeah. Uh, we're, we're a startup, uh, 26 years in we're startup.
Absolutely. That's, uh, the good place to be if you've been that successful, that long. Yeah, no, I, I, I, in some ways you gotta choose to be un un killable. You have to adapt. Of course. And I was talking with another founder a little while ago, and we were, we were commiserating that, I mean, you know, and, and you know this [00:58:00] being the head of your company, you can get a little lonely up there.
And we were saying that, you know what, while we need to be is we need to be like, like zombies because the hits are gonna keep on coming. The bullets are gonna be flying at us, they're gonna be knocking out bits of flesh. We'll lose a few limbs, but we keep on going and in the end, yeah, the zombies always win.
Right. So honestly, it's great. I like, I was talking to someone kind of about this, but it's like, yeah, every founder, you have to be an eternal optimist. 'cause if you're not, you're not gonna su survive. 'cause the amount of rejections, like you said, the amount of hits you take if you can't handle it, it's a, it's a tough position to be in.
It is. Well, my friend, I, I wish you all the best. You're on an amazing mission. Um, good luck with the funding round and, uh, let's keep in touch. Absolutely. Thank you so much, aj. Really appreciate it. Thank you, Sulav.
[00:59:00]