Sep 1, 2026 · 38 min · 11 segments
Payments has changed dramatically over the past decade, but some of its biggest challenges have remained surprisingly consistent. In this episode of Real Talk Payments, Kapil Mokhat is joined by…
Brian WeyGuest
Adam HollenbergGuest
Kapil MokhatHost
At some point, you have to assess, and you know this from Adam as well from prior days, you have to assess when you want to stop assessing the partners and deciding what you want to build in-house.
How do you think about that decision, which is to integrate another vendor or own this ourselves or go invest in another product? How do you make those decisions?
I think a lot of the folks that we've worked with have the benefit of working with, we work with smart people and smart people love to solve hard problems.
And sometimes that means the natural tendency is like, well, I'm going to build it, right? It's like you work with great engineers and you're like, I'm going to build that, right? And, you know, to your point, it does take some discipline to say, all right, maybe this isn't the right situation for us to build this in-house, right? Maybe it makes more sense for us to buy something.
And I think it helps to drive the conversations by having like a first principles conversation first, right? What's really important to us? What are we trying to achieve here? in this search? Is this a problem that is very, very unique to us? Or is this a problem that's been solved a bunch of different times before? Those are the basics.
One thing I've learned in more recent years is also just understanding you know, our internal payments team and, you know, down to a person on the engineering team.
It's like, what are you guys good at and what motivates you? Right? Like if you love tokenization and vaulting and like you want to spend your time on that, then, you know, it might make sense to put your dollars there and build that in-house.
But if you're a team that like, you know, really loves experimentation and really loves like, you know, optimizing things, instead of buying orchestration, maybe it makes sense to build that in-house.
The point is to try and match the team's strengths and passions and to take that into consideration when trying to decide, I'm going to build this or I'm going to buy this.
Yeah, I think taking the team's competencies into account is a really good non-intuitive one, Brian, that you brought up.
I think understanding whether you have the data necessary to make decisions in-house or you want to outsource that decision-making to someone else's ML algorithm or model that's been trained across multiple merchants, that's one way of looking at it for sure that I think is really important.
I also think that understanding immediate opportunity cost versus the opportunity cost of having to rip up whatever you did and rebuild it is the really tactical way you've got to think about it.
I, as a very business-oriented payments professional, try to put dollar amounts against... everything, just so I can create some sort of apples-to-apples comparison.
And just understanding what a week of your best few engineers' time is worth, on average, in terms of the initiatives that you've pumped out with that team in the last few years.
Understanding what that opportunity cost would be if you took 2x the time as you did to install whatever third-party software to both rip that out and build something new internally.
is a really good one to think about because you're always going to come back around when you build that debt into your tech stack.
If you're in a young growth business and you need to build a platform for the future, maybe you're more motivated to build in-house and make it a foundational part of what you do versus if you're a big company starting a new line of business, maybe buying something off the shelf and configuring and building around that is easier than because that's not your core focus or core competency.
At some point, you have to assess, and you know this from Adam as well from prior days, you have to assess when you want to stop assessing the partners and deciding what you want to build in-house.
How do you think about that decision, which is to integrate another vendor or own this ourselves or go invest in another product? How do you make those decisions?
I think a lot of the folks that we've worked with have the benefit of working with, we work with smart people and smart people love to solve hard problems.
And sometimes that means the natural tendency is like, well, I'm going to build it, right? It's like you work with great engineers and you're like, I'm going to build that, right? And, you know, to your point, it does take some discipline to say, all right, maybe this isn't the right situation for us to build this in-house, right? Maybe it makes more sense for us to buy something.
And I think it helps to drive the conversations by having like a first principles conversation first, right? What's really important to us? What are we trying to achieve here? in this search? Is this a problem that is very, very unique to us? Or is this a problem that's been solved a bunch of different times before? Those are the basics.
One thing I've learned in more recent years is also just understanding you know, our internal payments team and, you know, down to a person on the engineering team.
It's like, what are you guys good at and what motivates you? Right? Like if you love tokenization and vaulting and like you want to spend your time on that, then, you know, it might make sense to put your dollars there and build that in-house.
But if you're a team that like, you know, really loves experimentation and really loves like, you know, optimizing things, instead of buying orchestration, maybe it makes sense to build that in-house.
The point is to try and match the team's strengths and passions and to take that into consideration when trying to decide, I'm going to build this or I'm going to buy this.
Yeah, I think taking the team's competencies into account is a really good non-intuitive one, Brian, that you brought up.
I think understanding whether you have the data necessary to make decisions in-house or you want to outsource that decision-making to someone else's ML algorithm or model that's been trained across multiple merchants, that's one way of looking at it for sure that I think is really important.
I also think that understanding immediate opportunity cost versus the opportunity cost of having to rip up whatever you did and rebuild it is the really tactical way you've got to think about it.
I, as a very business-oriented payments professional, try to put dollar amounts against... everything, just so I can create some sort of apples-to-apples comparison.
And just understanding what a week of your best few engineers' time is worth, on average, in terms of the initiatives that you've pumped out with that team in the last few years.
Understanding what that opportunity cost would be if you took 2x the time as you did to install whatever third-party software to both rip that out and build something new internally.
is a really good one to think about because you're always going to come back around when you build that debt into your tech stack.
If you're in a young growth business and you need to build a platform for the future, maybe you're more motivated to build in-house and make it a foundational part of what you do versus if you're a big company starting a new line of business, maybe buying something off the shelf and configuring and building around that is easier than because that's not your core focus or core competency.
The rest of this transcript — segmented and speaker-labeled, so you land on the exact moment something was said
Search every transcript — by keyword, by phrase, or by meaning, across every show Radar indexes
Trends — what is surging across podcasts, measured against its own baseline
Alerts — when a name you follow appears in a newly indexed episode
No account is needed to search Radar.