This episode is brought to you by Bit. In the age of AI, don’t just generate code – compose software. Bit helps you create and reuse independent components to build reliable, scalable applications. Stop rebuilding and start shipping with the AI-powered composition platform at http://www.bit.dev
Agility requires a nuanced understanding of not just the technology at hand, but also the internal capabilities and collaborative potential within an organization. It demands a willingness to adapt strategies, embrace change, and prioritize value delivery above rigid adherence to traditional models.
Today, we’re going to talk about navigating the increasingly complex “build vs. buy” dilemma in the age of AI, and how an inner-source approach can offer a compelling alternative. To help me discuss this topic, I’d like to welcome, Luv Kapur, Staff Engineering Lead at Bit.
About Luv Kapur
Luv Kapur is a technology leader pioneering the future of enterprise development tools at Bit, where he leads core platform initiatives that bridge open-source innovation with enterprise-grade solutions.
Previously, at the Healthcare of Ontario Pension Plan (HOOPP), Luv architected and led the development of a comprehensive fintech platform that powers custom trading systems managing over $100 billion in annual transactions. His leadership was instrumental in successfully integrating the Bit platform across HOOPP, scaling it to empower over 10 teams and 100 developers.
Throughout his career, Luv has specialized in building high-performance platform teams that accelerate enterprise software delivery. At both enterprise organizations and now at Bit, he focuses on creating developer tooling that makes modern development practices accessible at scale – transforming how large teams approach component reuse, dependency management, and AI-assisted development.
Luv Kapur on LinkedIn: https://www.linkedin.com/in/luvkapur/
Resources
Bit: https://www.bit.dev
This episode is brought to you by Bit. In the age of AI, don’t just generate code – compose software. Bit helps you create and reuse independent components to build reliable, scalable applications. Stop rebuilding and start shipping with the AI-powered composition platform at http://www.bit.dev
Try ZipRecruiter for FREE at ZipRecruiter.com/audio
Don’t Miss MAICON 2025, October 14-16 in Cleveland – the event bringing together the brights minds and leading voices in AI. Use Code AGILE150 for $150 off registration. Go here to register: https://bit.ly/agile150
Connect with Greg on LinkedIn: https://www.linkedin.com/in/gregkihlstrom
Don’t miss a thing: get the latest episodes, sign up for our newsletter and more: https://www.theagilebrand.show
Check out The Agile Brand Guide website with articles, insights, and Martechipedia, the wiki for marketing technology: https://www.agilebrandguide.com
The Agile Brand is produced by Missing Link—a Latina-owned strategy-driven, creatively fueled production co-op. From ideation to creation, they craft human connections through intelligent, engaging and informative content. https://www.missinglink.company
Transcript
Speaker 1 (00:00)
This episode is brought to you by Bit. In the age of AI, don’t just generate code, compose software. Bit helps you create and reuse independent components to build reliable, scalable applications. Stop rebuilding and start shipping with the AI-powered composition platform at www.bit.dev. Agility requires a nuanced understanding of not just the technology at hand,
but also the internal capabilities and collaborative potential within an organization. It demands a willingness to adapt strategies, embrace change, and prioritize value delivery above rigid adherence to traditional models. Today, we’re going to talk about navigating the increasingly complex build versus buy dilemma in the age of AI and how an inner source approach can offer a compelling alternative. To help me discuss this topic, I’d like to welcome
Luv Kapur Staff Engineering Lead at BIT. Luv, welcome to the show.
Speaker 2 (00:59)
Thanks for having me, Greg.
Speaker 1 (01:00)
Yeah, looking forward to talking about this with you. Definitely a fascinating topic here and one I know I run into quite a bit. But before we dive in, why don’t you give a little background on yourself and your role a bit?
Speaker 2 (01:13)
Sure. Yeah, I’m a staff engineering lead at where my team and I focus on building the core platform that help developers create and share software and components. My background itself is in building large scale systems. Where reliability was critical as well as speed. Before Bit, I spent a number of years leading infrastructure teams for creating applications and finance and, you know, how finances with a classic high-states environment itself. So we had to ship features incredibly fast. was zero tolerance for failure.
And one of the key lessons I learned from my past experience was, you know, that the world that we are in, you can’t afford to reinvent the wheel, especially when you’re shipping fast, consistently. And the only way we could move fast and safely was treating our core and as a portfolio of assets. And this is what I learned by, you know, working in finance itself. you treat your core as a portfolio of reasonable assets, they’re independent documented components, then you can compose and move very swiftly and create these
consistent software for your clients. And that experience is what it brought me to bit. I want to help build the tools that would let any company around the world to achieve the same level of agility. So my role today is now making that vision of a possible software, a reality for everyone.
Speaker 1 (02:31)
Yeah, love it. Luv it. So yeah, let’s talk through a few things here, but I want to start with I mentioned a term in the intro and I want to get get your thoughts on on a definition here. The the inner source advantage. Can you explain what that means? What what that approach entails and how it differs from traditional maybe open source or purely internal development models?
Speaker 2 (02:53)
Absolutely. think a lot of people are more familiar with the open source model. And it’s basically applying all the successful principles of open source collaboration, transparency, reuse inside a company’s own firewall itself. And you can think about how open source works. Your developers from anywhere around the world can discover code, suggest improvements, and reuse packages. It’s really powerful. A lot of
most powerful systems are built upon software that are open source and are driven by the open source principles. And that’s what InnerSource entails. brings all the successful principles of open source to within the company’s own environment itself. So instead of teams working in isolated silos, and that’s the traditional way where entropy works in a large, large organization where teams go get into their own silos itself, they build their own private tools, and InnerSource is
pushes them back, encourages them to publish their work as discoverable, reusable components. So for anyone in the company to use. It’s a cultural shift completely because the traditional way of doing things is this is my team’s code. This is what my teams is going to deliver. And the shift is to it’s no longer my team’s code. This is our company’s asset. It breaks down silos. It creates a collaborative ecosystem within the company itself. And of course, for this culture to thrive,
you need a central platform where you can host, discover, and document and version these components. And that’s exactly what Bit itself for
Speaker 1 (04:22)
Yeah, yeah that really helps to explain it and I think the the open source analogy is a great is a great one that I think probably a lot of people can can understand I know you touched on on some of the the benefits but I wonder if you could talk a little bit more about you know what some of the key benefits of doing this are especially when as many companies are are faced with that build versus buy dilemma
Speaker 2 (04:48)
For sure. And the build versus buy traditional, when companies face this dilemma, they think they have only two binary options. We will either buy software or we’ll build. InnerSource gives you a very powerful third option called Compose. So instead of going into two rigid options, build or buy, you get a flexible strategy. And it gives you three advantages. And the first is you gain the value of having an option itself.
You can start by composing a solution from your existing internal components, internal software itself. Because this also gives you a good idea of what your capabilities are. Before you buy or build, you need to understand what your capabilities are, where is the gap, and what needs to be fulfilled. And that’s where you identify whether that fulfillment of the capability needs to be built in house or needs to be buy. And to make a more strategic decision, you need to understand the cost of it itself.
Once you have an internal set of inner source components, it gives you visibility on what your capabilities are. It gives you visibility on where the gap is in your own capabilities, why you’re looking for a vendor or an option itself. And think about the option to be like, I don’t need to pick one or the other. There’s a hybrid option where I can identify the gap, compose the solution around it, and just either buy that capability itself.
The second is also it lowers your vendor lock-in. that’s one of the key things with people think when they’re going from build versus buy solution. You don’t want to be locked into a vendor itself. So if you narrow down the radius of what you are buying from outside, the vendor lock-in also gets improved itself. And then the third is this goes well with understanding your capabilities because InnerSource gives you a clear understanding of
what you have built, how much it has cost to build, and what capabilities are, and gives you true price discovery, the ability to understand if you actually go and buy software, how much it actually costs to build in, and how much it is to purchase itself. And you’re no longer guessing at that point.
Speaker 1 (06:52)
Yeah, yeah. And so, yeah, I mean, definitely the the cost consideration that you mentioned, the the time considerations as well, certainly certainly a critical factor. And, you know, I do think that as more and more companies that may not have traditionally thought of themselves as software companies are this becomes increasingly important as more software tends to run more and more of companies than the again, you know, 20 years ago.
⁓ They might have thought of that. What about the component of AI? Certainly AI is on everybody’s minds. ⁓ While it’s not a brand new thing, there’s certainly a lot of renewed interest as of the last couple of years in it. How does incorporating AI kind of weigh into this build by intersource conversation?
Speaker 2 (07:41)
The AI actually introduces a different way to think about the build versus buy, because it’s no longer about cost and time with AI. Because AI is here to speed up a lot of development. We have already seen a lot of advantages big companies are getting by adopting a lot of these large language models itself. The other factors that start becoming more relevant when considering the build versus buy in the context of AI is the first one is context itself.
core differentiating capability of viewers as a business. And this is where you need to understand that AI, if it’s a unique capability that is very unique to your success of your business itself, you should be gravitating towards building it in-house, especially with AI tools, because a lot of this goes to the second part, is the control over the data. A lot of AI tools need data to help you make these smarter, intelligent decisions.
The question you need to ask yourself is, what kind of data are these AI tools need? Is it sensitive customer data itself? Because previous build versus buy solutions were not considered a lot of this, but this is now one of the key factors you need to consider now with adopting AI tools. If the data itself is not customer data itself, let’s say it’s only internal to the company and operations, like marketing needs to quickly build stuff, then it’s easier to ⁓ adopt an external AI tool. But if you need control,
or the data itself because of privacy requirements and making sure the customer data doesn’t leak. That’s another factor now you need to consider in the age of AI before adopting or buying one of these AI solutions itself. And then the third is the change in velocity, which is very, very relevant to AI because in the last 18 months, we have seen how models have quickly changed, how their capabilities have changed, and what that translates into your expectations from these products itself. 18 months ago, models could do
X amount of stuff for you. Within 18 months itself, the capabilities and the features these AI models can provide, what you can do has completely changed itself. So you need to catch up with this change velocity itself. Are your internal requirements changing as fast as how the models are changing? That makes you question itself, how and when to adopt these new AI tools itself.
Speaker 1 (09:55)
And so what about, you we have a lot of marketers and, you know, CX professionals, a lot of people listening to this show that are not necessarily sitting in IT or in the engineering side of the business that may be building some of these tools and yet certainly very reliant on the, you know, build versus buy decisions that are made within the organization. They might have a seat at the table, but, you know, not sole responsibility.
What’s the, you know, how, how should a, let’s say a chief marketing officer or someone like that, you know, how should they be looking at this when again, they may have some influence over some of these decisions, but you know, what should they be thinking about when talking with other leaders within the org that are, that are making these build versus buy versus, you know, inner source type decisions.
Speaker 2 (10:44)
This is a classic problem I’ve seen where there’s a disconnect between IT and business leaders itself. And a lot of this classic disconnect goes back to business leaders viewing what IT delivers or what they need from IT itself in terms of projects, not capabilities. When you think about projects, you’re requesting something from IT. This is where the IT that will build it have a different complete sense of how things will be built, how they will be delivered.
And the business leaders that have a need and a want for it at the end from these projects have a completely different perspective, and then there is a clash. The solution it is for leaders to stop thinking them towards as projects and to start thinking about capabilities. What capabilities your organization has to deliver stuff? We have reached a stage, especially with AI, where non-technical users have been empowered to build a lot of these tools.
without a lot of core technical knowledge. For them to successfully be able to build it, IT needs to provide them with enough capabilities that they have visibility and to be able to understand what can they do and what they can’t do. Where do they need IT to be involved? Where do do not need IT to be involved? If business leaders start looking at IT as a black box, this is where the disconnect and the frustration happens. Once they have a complete visibility on
What does my IT provide? What capabilities do I provide? What are my needs? What is the bridge between the capabilities we have and what I need to deliver? And then if there is a gap with this visibility itself, then the conversation around bill versus buy becomes very easy to have with IT. And you’re on the same page, you’re having a discussion, but if one side is looking at it as a black box and the other side is looking at it that we have full control over what this decision is being made, then you’re probably not making
the best decision for your company at that point.
Speaker 1 (12:36)
Yeah, yeah. Well, and then to build on that, let’s talk about measuring success as well, because, I think there’s there’s some let’s let’s call them traditional ways of measuring. You know, you you license software, you buy software. There’s there’s some ways of measuring success there in the in that siloed version of the, you know, the build scenario. I think there’s there’s probably some some metrics there. How do you recommend?
measuring success of this inner source approach. And I would imagine maybe it’s some of those others, but sounds like there’s some there’s some other things as well. And, you know, how do these metrics compare to some of those more traditional models?
Speaker 2 (13:17)
Absolutely. With Intersource, the first change that happens is you stop zeroing in into a specific project and its measurements. You think of the ecosystem capabilities itself. Metrics like whether the project was delivered on time, whether it was on budget, are absolutely important. But they’re not the core metrics itself that should drive your analysis on how your decision-making went. With Intersource, you take an ecosystem-based metrics, which is reuse, velocity, collaboration.
The whole idea is if I am building an inner source internally with these vetted components and a lot of effort has been put in, every subsequent project or a system I develop will be delivered faster. Think about it starting from pieces of Legos. You build the first one. You rebuild this project from the first piece of Legos. You extract more usability. Now you have more complex Lego pieces. Another request comes in, and you’re like, you know what?
I only need to build 40 % of new LEGO pieces I can reuse from what I have done already. Let me start assembling them. And then when you measure use, you look back in your last quarter. You said the first project took x amount of time and x amount of cost to deliver. How much faster were the subsequent projects delivered? They will see it’s less time, less effort it takes. The other key thing to look at is, and this is something I learned working in finance itself, I call it headcount liquidity.
Large organizations have priorities that change all the time. Because it depends on where are you in the market itself. Is this a time where compliance takes over? So the priority shift towards a lot of compliance-based projects itself. So this is where what you want is your internal headcount to be absolutely fluid. You should be able to move developers from one place, one project to the other, without added overhead and friction.
which is extremely hard to do with the traditional way of doing things because again, everything is built in silos. Every project has a specific way of developing stuff. There’s overhead and mental overhead for developers to move from one team to the other. Imagine now completely think about it when it’s built with the inner source initiative in mind. Every team has visibility on what other teams are building. Every project manager has visibility in what capabilities exist that have previously been built.
Every time a new project gets built, the conversation changes from starting net new to how can I build from an existing capabilities and existing solutions. So if priorities change and something’s more important, it gives that head count and fluidity and liquidity to the product manager saying, I’m on XM Auto developers to move to the new project so I can deliver faster, and I’m not going to lose overhead on it. And I think these are new metrics that are more relevant with inner source now.
Speaker 1 (16:04)
Yeah, yeah. Well, and I would imagine, and you kind of touched on this, but the idea of collaboration within an organization changes as well. And so maybe if you could talk a little bit more about how this approach can promote the transparency and collaboration within an organization and
how that impacts, you you use the Lego analogy there, but you know how it impacts the overall like software development life cycle.
Speaker 2 (16:34)
Absolutely. And the collaboration piece is one of the biggest advantages you get from inner source. And we have seen it thrive in open source model itself. A lot of times, the blockers for collaboration are a lack of visibility within organization across the large teams, where they have complete lack of visibility on what the other team does, how it does, what their priorities are, from technical also to
requirements-based. And what are they building, who their stakeholders are, why are they building this, where did this need come from itself? With InnerSource, everything is open and discoverable. Everything is considered as a shared company asset, not your team’s asset itself. And this is one of the differences I have personally noticed when we adopted an InnerSource model in a large organization where
It’s very obvious to expect the benefit of collaboration to reach at a developer level because you think, developers have to write less code, developers can reuse a lot of existing code and now assemble stuff. But the real value where I saw was the change in perspective of product managers. When product managers stick with stakeholders, the previous conversation always started with, hey, what are your needs? What are your requirements? What do you want to build? Why do you want to build?
And then they ask you for an estimate on how long will it take to build. And then product managers go back and look at, OK, we delivered this for you before. And based on this, this is how long it will take. With InnerSource, the conversation completely changes. Because when they ask there is a need, the product manager can open, have a complete idea of, OK, but last quarter, this is what I delivered for you. These were the capabilities we delivered for you. Next quarter,
This is what I can reuse and reassemble from it. The conversations are happening with stakeholders. I’m giving a more accurate prediction about the time things to be built, because they have more insight on what exists within their inner source ecosystem. And I think this is where transparency and collaboration provides the biggest value to product managers making these decisions, having this conversation with stakeholders, and setting up expectations on delivering with them.
Speaker 1 (18:45)
Yeah, yeah. What about security risks? You know, certainly, you know, everything from data compliance to to many other factors are top of mind for for organizations. Does this increased collaboration increase, you know, potential security risks or, you know, how does an organization effectively manage things like that while still, you know, fostering all the great things, the open communication and all of the other things that that this approach encourages?
Speaker 2 (19:15)
basis of the inner source and open source model is enforcing a standardization of delivery that starts off as basis for being able to collaborate seamlessly and also deliver seamlessly. As part of this consistency in how you want to deliver, each component or each deliverable when it delivers has security baked into its lifecycle itself.
When a team A needs a capability from team B and they realize they can actually contribute back to team B, they also have insight on the developing guidelines of team B. Team B have already automated the whole process. If you are actually introducing a change, it will go through our lifecycle of security checks, automated governance checks, validations.
But the other side of it is if you’re building in components and building an inner source and building in these reusable modules like LEGO bricks itself, think about as security vulnerability introduced in one piece of module. It’s very easy to roll back because you can pinpoint on exactly where it was introduced. Everything is versioned. So rollback becomes very easy. Compared to traditional way of doing things, everything is being written as big pieces of code. They live in repositories. You don’t know how much stuff gets duplicated. It’s extremely impossible to understand what depends on what.
If I change this, what am I breaking this? If I change it, is there a guarantee that everywhere this is being used, it’s not being rewritten? When you build on blocks, you have what we call is insight into a dependency graph of the code itself. When you have insight on the graph, what you understand from the graph is who are your dependencies and what depends on you. Once you have visibility on who are your dependencies and what depends on you, isolating security fixes, it becomes very seamless.
And I think this is one of the biggest advantage companies get by adopting this approach.
Speaker 1 (21:06)
Yeah, yeah. Well, as we wrap up here, one last thing, I want to get back to the ROI part of this conversation and looking at this from the I would say from the non-technical, from the marketers or other business exec standpoint. You mentioned that often, you know, I.T. gets thought of as just, you know, deliver me this thing or this this widget or I mean, I’m paraphrasing. But, you know, how how do you recommend chain?
kind of changing that mindset and that conversation into something that’s more, again, delivering capabilities and functions that really deliver great value to the business. Because I think what you’re talking about here is companies really investing in long-term capabilities that grow over time and that compound value over time. How does a CMO or somebody kind of change the way that they’re thinking about
how some of this stuff gets delivered.
Speaker 2 (22:05)
I think the basis of it is breaking down the capabilities into these small, manageable individual pieces, not just with code, but also what value, the end value it gets out of it. A lot of times, this disconnect from executive leaders happens because they have an ask, which is extremely big. Let’s say, build me a new marketing campaign page and let’s deliver it.
The delivery of it is not exactly how the ask happens. The delivery happens by breaking down, I need a new header. I need a new action hero. I need a new action over there. Some call to action buttons I need, and I need to assemble them into a page. But the executives don’t see this, absolutely. What they see is a big ask, and it gets delivered. Then they have another six different big asks just waiting in their pipeline, which they have complete disconnect of how it’s going to be built. So it starts with visibility. It starts with complete visibility of how
how software gets delivered. And to reduce that complexity of understanding how software gets delivered is to break down the delivery of software into these independent, manageable pieces, whether they are code, whether they are the capabilities that are linked to the code delivered. And this is one of the things we see a bit, is every time we talk in components, and component is a first class citizen, we call it in our ecosystem, the reason is because a component is not just code for a developer. It has documentation.
It has live previews so you can understand what it does. The documentation explains you why it is being built, what capabilities it serves. And then there’s a graph of these components, which connects stuff. if an executive asks me to build a certain capabilities, they have a visibility of how it is assembled. For each piece, they also have a visibility of what it does. This also makes them understand their asks and their capabilities.
from the IT itself and then this is a two-way transparency that creates between IT and the executives.
Speaker 1 (23:58)
Yeah, that’s great. Well, love. Thanks so much for sharing all your ideas and insights today. One last question for you. I to ask everybody what do do to stay agile in your role and how do you find a way to do it consistently?
Speaker 2 (24:11)
For me personally, I’m a big believer in feedback loops. When I work in teams, I love the collaboration aspect. I love the feedback aspect. To stay agile, what I personally will do is I will break down my tasks, just how composability works, and get as much feedback as quickly as possible with the right executives, with the right team, with my team members, and iterate. If you have a close, shorter feedback loop and you have a faster iteration on it, I believe you can tackle as big a
tasks. It is not daunting anymore for you.
