Hidden Costs, Smart Choices: Mastering Your Technology Stack

Unlock Expert Insights – The Build vs. Buy Decision

Join Oyster Consulting’s technology specialists, Jeff Wilk and Dan Garrett, as they delve into the pros and cons of the build versus buy decision for financial institutions and fintech companies alike. Whether you’re part of a traditional financial services firm or exploring new business models, this podcast equips you with the knowledge to navigate complex technology decisions that can impact your organization’s long-term success.

Cost Considerations

Understand the true cost implications of building your own platform versus purchasing third-party solutions. From initial development to long-term maintenance, we break down the financial aspects to help you make informed choices that align with your business strategy.

Team Dynamics and Culture

Explore how organizational culture and team structure impact your technology decisions. Learn strategies for fostering a collaborative environment, whether you are building in-house or managing tech vendors.

Technology Integration and Data Strategy

Learn how to effectively integrate emerging technologies and manage your data across different platforms. We highlight the importance of APIs, data warehousing, and ensuring your tech stack supports your business needs without becoming a tangled web of incompatible tools.

Compliance and Security

Stay ahead of regulatory requirements and cybersecurity threats. This podcast covers how to embed compliance into your technology strategy, whether you’re building internally or relying on third-party vendors.

Managing Vendor Relationships

Effective vendor management an important key to achieving competitive advantages. Vendor relationships are also a cornerstone of effective incident response and compliance, and we unpack how to proactively navigate these critical areas.

Additional Resources

Choose The Right Wealth Management Technology Core

Is Your Tech Stack Right for Your Business?

Cybersecurity: Mitigating Vendor and Change Management Risks

Generative AI: FINRA Vendor and Communication Rules Still Apply

Communication Strategies To Improve Vendor Management

Proven Expertise At Your Fingertips

Oyster Consulting’s experts bring years of experience in fintech technology, offering practical advice and real-world examples to guide your decision-making process.  Oyster will help you define your technology goals and ensure you are getting the best value from your current vendors. Our consultants have the experience, proven process and resources to guide you from planning your tech stack to implementing the changes. From planning your tech stack to implementing changes, we’ll guide you every step of the way.

Transcript

Transcript provided by TEMI

Bob Mooney:  Welcome to the Oyster Stew Podcast. I’m Bob Mooney, General Counsel for Oyster Consulting.  In today’s podcast, Oyster’s technology experts Jeff Wilk and Dan Garrett dive deep into making informed technology decisions.  They’ll explore the critical factors behind the build versus buy decision—breaking down hidden costs, navigating team dynamics, and ensuring seamless integration of your tech stack.  Whether you’re building in-house, managing third-party vendors, or considering a hybrid version of these, Jeff and Dan share their insights on how to align your technology with your business goals, stay compliant, and keep your systems secure.  Let’s get started – Jeff?

Jeff Wilk:   Thanks, Bob, and good afternoon, everybody. I’m Jeff Wilk, Managing Director here at Oyster Consulting within our Strategic Planning and Execution unit, and I’m joined today by Dan Garrett. We’ll turn it over to Dan in a moment, but we’re here to talk to you about building versus buying your FinTech technology solutions. Whether it’s a platform you’re building from scratch as a startup, whether it’s a platform where you’re looking to enhance or transform to something new, there’s lots of considerations. So, we are going to spend time diving into each one of those, very much in a conversational way, and let’s just see where the conversation goes. Dan, welcome. And thank you. You want to say a few words?

Dan Garrett:  Yeah, thanks Jeff.  This is Dan Garrett. I joined Oyster earlier this year – so excited to be part of this great team. 30 years of experience in the industry, working for RIAs, broker-dealers, clearing firms, and some software companies, and holding roles as Chief Operating Officer or Technology Officer within those different entities, and being responsible for building out technology platforms, mobile apps, web apps to serve financial advisors and clients, money managers, and so forth.

I’ve had a passion for combining technology and finance my entire life and have built a career over that, and I’m doing some of those same things now with our clients here at Oyster, helping them look at their technology and make decisions about where they go from here.  So, Jeff, I’m really looking forward to this conversation.  You know, you and I are kindred spirits in this area and, and I love talking about this stuff with you.

Jeff Wilk:   No, absolutely, Dan, it’s interesting hearing your background too. It just makes me think for a second how there’s so many similarities when it comes to technology, regardless of which lens you’re looking at it from.  My 30 years were spent more on the strategy side, less on the technical nature of technology, but more about how you put the different options together, and then how do you implement and roll out and get adoption and things like that. But in the end, I think what everybody is going to hear today is that the fundamental questions that go into build versus buy are largely the same, regardless of the type of institution you’re with or the type of firm that you are.  Obviously, yes, they may have different levels of magnitude based on your resources and size of organization, and things like that, but the basic building blocks of this perennial question stay the same. Maybe we’ll pick a handful of them and just start off talking about cost, right? I think that’s one of the first things that typically comes to mind when considering your tech stack, whether it’s new or you’re looking to rebuild it or remodel it, but first thing invariably people think about is often cost, and what’s it going to take?  Why don’t we spend a couple of minutes going through some of some of those considerations?

Dan Garrett:  Yeah, that’s great. It’s really interesting. I saw a presentation the other day about building out your tech stack and what that looks like, and how firms or the industry really needs to focus on building this holistic stack that could be used by everyone. That presentation could have been given 20 years ago, and it would’ve been relevant back then. And I think that same presentation can be given 20 years in advance from now, and it would still be relevant. So the question of, why hasn’t anybody come along to do this? Why doesn’t this exist already today? Cost is a big factor, and it hasn’t been because firms haven’t spent money.  If you look at the industry, very large firms, whether it’s clearing firms or tech firms, have spent millions, if not billions, trying to build the uber wealth management solution that has the best of CRM and planning and reporting and trading tools, all together with account opening and working seamless between RIA, BD and your clearing firm, and everything talking together.

And why don’t we have that today? A lot of it does come down to cost, and it’s very expensive and things are constantly evolving. So we’ll get into that. But there’s some other things I want to touch on later, too – why I don’t think we’ve seen this uber platform come to fruition. A lot of it is cost. I think firms need to realize, especially firms that do not have technical wherewithal, you don’t have a development software development team. You don’t have the resources and skillset in that area. You have to be very careful about what the costs are and make assumptions about what it takes to build something, and how long it takes to build something, because it is quite expensive.  About two years ago, we saw a huge increase in the amount of money being spent on developers.

The cost of a software engineer today is skyrocketing, and the reason for it is because every company is becoming a technology company.  Because of that, everybody’s trying to build technology, they’re trying to automate things, and there’s only so many developers that can go around. And even offshoring today is becoming more and more expensive, as demand drives up. You know, first and foremost, what is your budget, and is that budget realistic in terms of who you’re going to need to hire or who you’re going to need to work with to build out your technology stack.

Jeff Wilk:   Yeah. Dan, I think it’s interesting when you mentioned cost too. Something that struck me there was when you’re talking about the cost of a software engineer or developer over time, because typically one of the things that I’ve come across with some of our clients is that they look at today’s cost. They’re looking at column A, column B, right? What’s it going to take me to build? What’s it going to take me to buy? And in the build column, they’ve got today’s cost. Some of them will project out three years, maybe five years. But, in that build scenario, I don’t think there’s much of an argument to say you’re not looking to build your own platform for the short term. In most cases, you’re looking to do it for the long term. And in that case, exactly, to your point, you’ve got to build in a realistic escalation,  you know, more than just an inflation rate, if you will, on certain expenses. Simply because the technology changes, the demand on the expertise to work with that technology and not just to maintain what you have, but to deploy the new, is just going to increase exponentially as well. And I think that’s a great point to highlight because it does often, at least in my experience, get overlooked when you’re doing a long-term projection. And then what, right? Couple of years down the road, all of a sudden they’re looking at, well, what happened to my platform costs? We only projected it to be X and it’s 2x, it’s 3x.

Dan Garrett:  A lot of folks naively just think, oh, we’re just going to build it and then it’ll be fine. We won’t need those developers or anything after we get it built. Well, there is no end to the building right there. There’s always new regulations. There are changes that occur, there’s enhancements that you want to make, there’s bug fixes, there’s the cybersecurity issues that you need to be aware of and stay on top of, and so forth.  Typically, what I’ve seen in the industry, is you have about five years. You know, you build a product, and that product probably needs to be rebuilt in about five years. And at about the 10-year mark, if you haven’t, you’re now starting to run into major problems where you’ve probably developed it in a language that you’re going to have a hard time finding developers that even know or want to learn or support that system in. So things are constantly evolving and you need to budget in maintenance to make sure that those systems, like I said, are adhering to new regs or dealing with cybersecurity issues and so forth.  It’s something that people really need to think about.

Jeff Wilk:   You’re touching on, I think, a second perhaps topic here, that’s critical in the build versus buy conversation, which is the culture of the organization itself, right? So, how does that organization think today? How do they do their planning process? How long is it for? Do they have a culture of sticking to what may be a five-year plan for a certain project, or does that initiative – say a new build, a new technology build that’s going to take two to three or four years to actually completely realize – do they have to go through an annual budget process every time, which might put the project in jeopardy that was initially laid out for a three- or five-year cycle. I think you’re touching on a very important topic, too, on I guess what I’m labeling as culture of the organization. Any insights or experiences in running across, I guess the pluses or the danger zones with organizational culture within a firm?

Dan Garrett:  Yeah, boy, we could do a whole other podcast on that topic. There’s a lot that goes into just building out a technology team. You know, you’ve got a lot of interesting personalities when you bring together folks that are business analysts and software developers and quality assurance folks and getting them all to work together on a common goal, usually very fast paced, usually very budget restrained, if you will, to get things delivered and so forth. And that culture of having things very well-organized, responsibilities, well-defined timelines adhered to, and making sure that the team is delivering on the promise of that technology – it’s difficult. I’ve built so many different tech teams over the years. People come and go, people advance in their careers, and the team dynamic is constantly changing.

I think you have to be a culture that can adjust and adapt to change very quickly, not just with the change of technology as that’s spinning around and new things are coming about, but also just the chaos of the team dynamic and bringing in different people or new people into the team as things go on; and, still have a coherent leadership and structure and culture that keeps that application going and supporting the business and providing good service to clients.

I think that’s one thing that’s so critical when you’re developing technology, is to be very client focused in your culture. You’re building for that user. You’re building for that client, whether that’s an end retail client or a financial advisor, or a trader on a trading desk. You cannot build that with assumptions. You cannot build that on your own. You have to have a culture around the client and the client experience and building what it is that they want and need.

Jeff Wilk:   Oh, and Dan, I think it’s a really interesting point because you speak to the individual expertise and the individual mindset of some of the technology developers, the software engineers, and those teams of individuals who are very specialized, who have very targeted skill sets in terms of building out certain components of your technology platform. But at the same time, as you mentioned, you need to have somebody with this much broader view who I think is chiefly responsible for the scalability of a platform, the flexibility of a platform, so that it can address the changing needs of the business as that development process goes on, right? There’s certain building blocks that have to be put into place regardless, but then there’s other pathways that may open up. There are other technology enhancements that may appear that you want to take advantage of, or you need to take advantage of, a regulatory change that takes place. That team of developers can’t be so locked down that you can’t pivot and make a change or put something additional into the tech stack because it’s a very time sensitive or business sensitive need. So, I think that flexibility and that kind of vision on the scalability and the flexibility of the platform is important, or it becomes a large vulnerability,

Let’s kind of shift gears a little bit here.  When you go onto the buy side of things, I think one of the areas of caution, and I know I’ve seen it, I’m sure you have too, is that there’s this kind preponderance of thought that says, well, building, it’s just going to be easier, right? All I have to do is pick a vendor, and then all I have to do is make sure we’re staying on top of doing what we need to do and stick to our contract and pay the bills. Whereas the reality of it is, even on the buy side and leveraging top scale or newcomer third party FinTech platforms, comes with a battery of responsibilities as well.

Whether it’s the need to, and dare I use the word, customize. When you’re building and when you’re buying something, but there is customization typically always, or maybe let’s call it what I kind of call the smaller “C”: configuration. I’m sorry, but that’s still some customization for your business. All of those things are things you need to manage. You need somebody who’s going to watch over that. You need somebody who’s going to monitor, is it doing what we need it to do? And is it doing that on an ongoing basis for the three, four or five plus years, maybe, of your contract? Similar to one of our other topics here today, you mentioned we could spend a whole session on the regulatory requirements of third-party vendor management. It’s elaborate things that even on the tech side, just because you signed a contract and you outsource a certain set of functionalities or a large platform set of functionalities to somebody else, there is still big responsibility inside the firm to manage that, whether it’s for business function or for regulatory aspects as well.

Dan Garrett:  Yeah, so much to explore there. First of all, you need to do your due diligence. You need to define what it is you really need and want, and then go out and make sure that you’re asking the right questions of these vendors before even buying. But even that, once you’ve signed the contract, that just is the start. I did a blog not too long ago about vendor relationships and how important those are, that you are meeting with your vendors on a regular basis, talking about what they’re doing, what they’re concerned about, what they’re building, are they staying on top of regulatory issues? Are you communicating with them what you like or dislike about their system? Are you staying on top of the latest versions and releases that are coming out?

You know, these are all the things that you need to do. And like you said, you are still ultimately responsible for your clients and operating within the best interest of your clients, and dealing with all the privacy considerations. I’ve worked with a few clients now on putting together the incident response program for them. In doing that, a lot of that is working directly with your vendors when an incident occurs. Let’s say you have a breach of data. It’s not your fault, it’s one of your vendors. Well, it’s still your problem and it’s still something that you have to deal with, with that vendor. You have to communicate with your clients. You need to be ready and prepared for doing those types of things and have conversations with your clients and with your vendors ahead of time about it if this happens.

And some would say, not if, but when this happens, which is even scarier, but if this happens what are you going to do as a vendor? And what do I need to do on my side to get through this breach of data or, essentially a threat to the system or an outage even where the system’s gone down and having all of that prepared, it amps up certainly more when it’s your system. But when you have a vendor involved and you’ve bought a system, you still have to stay on top of those things and think about those worst-case scenarios, those rainy days that will come to be prepared.

Jeff Wilk:   No, absolutely Dan, and it’s an interesting topic, the whole incident response plan. Oyster has done a number of engagements with firms and the whole business continuity, disaster recovery planning areas, which includes the incident response plans. And somewhere in the past 12 months, there was a large, fairly industry-wide, or almost industry-wide outage. Thankfully it wasn’t long lasting, but it was long enough to cause issues. And it was interesting how within Oyster, we got a couple of phone calls from firms who we had worked with who went all the way through a full business continuity planning process and built out very robust incident response plans. Some firms who had, let’s call it slightly less developed, they were there, they captured the essence, but they didn’t go all the way through to actually have an executable plan on what to do thinking, well, this critical point of failure is a mega vendor. They’re never going to go down. And if they do, you know, they’ll come back up very quickly. So there won’t be a problem. Well, like you said, rainy days do happen. It was just interesting to see, it was good to get the phone calls from those firms that were fully ready and they had a plan in place and then, unfortunately, to get the calls from the other firms saying, what are other firms doing? Because we didn’t take that last step. So, these are real issues that firms need to think about. The regulators are all over it. They are as part of routine exams now they are looking for not just business continuity, but they’re going pages and pages deep and looking at incident response plans in terms of what are you going to do?

Dan Garrett:  I’ll tie it up a little bit too, because we were talking about culture, and I think having a culture of compliance is important. Compliance is everyone’s responsibility at the firm, and if you’re selecting technology or building technology or integrating technology, you need to be aware of the compliance ramifications of those systems and be responsible for those pieces. And a lot of times I’ve worked with a lot of compliance people that are great, but they’re not tech people, right? And so, it’s a difficult part of their job because they’re not tech savvy.  But yet, they have to be responsible at the firm for all of that. And I think it’s the burden shouldn’t be put on their shoulders a hundred percent. I think that burden needs to be carried by folks across the firm, and especially with technology folks that do know the technology and do know cybersecurity risk.

They should be up and aware of our regulatory requirements in the industry, imposed on us by the SEC or FINRA, and really understanding those roles and regs and the systems that they have, and also the vendor relationships, because I think that’s where it needs to start. You need to work in conjunction with your compliance officers.

The other thing I wanted to touch on, kind of circling back around – it’s not just buying a system and then signing a contract, and you’re great. You know, the one thing that we see a lot of is integrating these different systems, whether you’re buying or building. If you are buying, chances are you’re going to be doing a little bit of building, and that may be offset to your vendors; or, maybe you need to bring in somebody to help you, but the critical thing is that you’re buying these different solutions out there. But all those solutions need to talk to one another.

In a lot of cases, these vendors do have APIs or links to other vendors, and so there’s data sharing that occurs, and sometimes there’s not. And so that’s another thing that doesn’t a lot of times get looked at in the due diligence or in the contracting of getting a system, which is to ask the questions around, okay, well I need the data in this system to also flow over to this system? Yep. And, making sure that the contracts are written such that you include those kinds of considerations or be aware that you’re going to need to probably hire somebody or work with someone to get those systems to talk to one another. So, integration is extremely important.

Jeff Wilk:   Yeah, Dan, I couldn’t agree more that it’s really a hybrid approach that has, I think, taken on a whole new, I think sense of interest, both from the tech provider perspective, but also the firms looking to deploy technology. And that whole nature of the contracting is, it’s always been critical, but I tend to say it’s more now than ever that the devil’s in the details. I mean, how many firms have we worked with and how many different providers have we brought to the table for firms to work on doing evaluations? Invariably somebody will say, “Oh, well we have an API for that” and that will be it. That will be the entirety, the entirety of the conversation. “We have an API for that” and move on. And nobody’s asking, what does that API do?

What exactly are you delivering access to through that process? And does it do what you think you’re answering the question that’s being asked? And vice versa. You got to get under the hood, way under the hood and really see is in this hybrid approach, which is totally rational. Are you going to get what you’re expecting to get or what is critically necessary to get? I think the other area that is becoming very popular with some of the pro platform providers who are taking on this area of being a hybrid provider. In that case, when I say that, I mean more of a core platform of their own with a robust, you know, API store to conceivably allow you to plug and play connectivity with other third parties. They’re also launching these developer portals, and I think more clarity is necessary in conversation around those opportunities.

What exactly does this developer portal do for a firm’s technology team? How much flexibility does it afford you? Does it match with the skillsets of your tech team? So, I do see a lot of terminology that’s being used. A lot of, I hate to call it loose conversation, because I don’t want to make it sound deliberate, but it is loose conversation that firms need to be very careful, very mindful, not ashamed to ask a question. Tell me more, what do you mean by that? You know, give me the full 20-minute conversation on that three-word answer you just gave me so that you don’t wind up with surprises down the road.

Dan Garrett:  Yeah. And if you don’t know, get with somebody who does know and can help you. If you’re not technical and you’re not going to ask the right questions or dig into things in detail, bring on somebody that can help you in that area, that has maybe worked with that system before or has integrated that system before and knows the questions to ask. Things get complicated. If you work with a particular custodian, great – that custodian has the lion’s share of your accounts and all of your data, and they may have APIs, and you could pull the data out and you could get some other technology solutions to get data in. But then there’s, what about your assets that are held off platform? You can’t forget about those too. And your clearing firms may or may not help you with those, and aggregating those, and consolidating those. But the technology vendors that you do go with, you need to bring that data in there as well.

Some firms are so large, they need to have a data strategy, and this is probably a whole other podcast, but, those are things that you need to think about too. Can you get your data out of these systems, not just to put into another system of yours, but to put into a data warehouse for you to do analytics around, or reporting around, or just management of how much do you have? Those type of questions come in a lot of times when the regulars come in and start asking questions. They want to know your business and you should have those numbers easily accessible and sometimes they’re not all in one place.

In the case of off-platform assets, along with your clearing assets that you have at your clearing firm, and being able to bring those two numbers and, and aggregate them together. Sometimes you have to do some work to do all of that.

But Jeff, I wanted to talk to you, so kind of coming back around, I really wanted to get your thoughts around this presentation that I recently saw, which was, hey, the industry really needs to build this uber system that has everything interconnected and that’s been talked about for 20 years or over 20 years, and a lot of money has been spent on it. And I just wanted to get your thoughts of like, why isn’t it here? Why don’t we have it?

Jeff Wilk:   You know, Dan, I think it’s going to always remain as that uber achievement, right? That you call it the uber platform. I think it is an ungraspable goal, and the reason for that, in my opinion, is just that technology changes so rapidly. The one thing that never stops changing is the speed of technology enhancement and the enhancements that come with that in a very rapid pace. So that uber platform is never going to be here because the goal line is always shifting. At the same time, business needs are always shifting. So you’ve got these different dynamics, one being technology itself and the expertise and everything that goes along with that development, and then you’ve got the business cycles and the business needs for what they need to react to for their consumers, for their clients.

And so, you put those dynamics together, even with the most well-resourced company, yes, there will be some who are doing better than others. Yes, there may be some who are delivering enhancements faster than others, but is there ever going to be the single one source platform that is the right and best solution for everybody? I don’t see that. I think that creates opportunities and it certainly creates challenges, particularly on the strategy side. It also creates challenges for firms who are looking to always be mindful and providing the best level of service to their clients.  And most of our firms, it’s also for their advisors in addition to the end clients – but what do they want? What do they need? What do they experience in their day-to-day lives, not just in their financial lives? All of those competing forces, I think, are just going to drive forever the moving goalposts that firms have to chase after. Regardless of how big and how dynamic and how nimble they are.

Dan Garrett:  I think I totally agree with you. It’s interesting because I just saw, this is a novel idea. Why don’t we survey what firms want? And is this something that they want? And their surveys are coming back saying, this is not something clients want. This is not what firms want. They don’t want an uber system, so why are we trying to build it? It’s almost like a fool’s errand, throwing millions of millions of dollars into building the system when you don’t have a customer or client base that actually wants it. What we’re seeing again, coming out of some of these surveys, is to your point, I want the freedom to pick the best breed systems out there. And like you said, there’s different firms that focus on different parts of their business. Maybe they want the best of breed financial planning tools, or they want the best of breed performance reporting tools or trading’s really important.

So, all these firms are different, and at all times there’s new technology that’s coming about and coming together to really bring those tools. I’m not always saying the newest, latest thing is always the greatest thing. Because a lot of times it’s not – but there’s always new entrants in the market. There’s new tools and techniques, there’s great new ideas, there’s new products that come to market all the time, so it’s ever shifting. And to think that you could put together this amazing platform that does everything and talks to everyone and is perfect – I don’t see it happening. You know, where I think the industry has gone for many years now, which is just, hey, you know, I’m going to be a CRM solution, but I’m going to talk to these three planning systems and these four performance reporting systems, and they too are talking to me. And so, we’ve got this kind of industry layer of communication between these firms, which makes those products kind of have a network effect around these vendors, if you will, will play nicely together. And I can package these up into a stack that’s appropriate for my business and for my clients.

Jeff Wilk:   No, I think Dan, we are virtually identically on the same page here too, and we haven’t even touched on other components of variables that are needed. You talk about it from an end client perspective, what about the different personas of the types of clients? I mean, the age categories, the geographic make up, the different income levels, the wealth spectrum. They all drive different needs; they all have different use characteristics. And again, trying to find the one single platform that accommodates all of them, I just don’t think it’s out there, nor do I think it will ever be out there in a single source type of a solution. On the flip side, I think we’ve also seen and experienced in our prior careers wanting to work on the one hand with fewer technology vendors than having this huge tech stack. At the same time, perhaps being concerned that you’re putting too much in one basket.

So, there’s always that dynamic going on too. I think what we’re saying here is that there are so many different components of what firms need to look at when they’re starting to put their tech stack together. They’re all critical that go into this build versus buy conversation and decision making, but there’s none of them that’s the silver bullet, right? There’s no one lever that’s going to make this decision. It’s so multifaceted. And, to work with folks like Dan, myself, all of the other consultants here at Oyster Consulting who have done this for many, many years, have very, very deep relationships with the major providers, the newcomers and the FinTech space. We know a lot about what these different platforms do, what they can provide, how they work together, what their cultures are like, and how they might interface very well with a firm’s culture. And how to help work with you in that decisioning process to bring together, whether it’s a build strategy, or it’s a buy strategy, or it’s this seemingly ever-growing area of a hybrid strategy. Leverage the expertise that you have available to help you with that decisioning and that discovery and that evaluation process. Dan, any last comments?

Dan Garrett:  First of all, this has been great. As always, you and I just chatting about these things is always fun. I’m always very passionate about this. To me, it’s so exciting when new vendors are coming to the market and people are thinking new ways about putting things together and thinking through their tech stack. And it’s fun to be in a place where you’re just seeing things ever changing and there’s just so much on the horizon right now to bring these things together. But to your point, it’s a lot. You need to surround yourself by a team of experts to help you out in all these areas and building that team and great people that can just help you out, move from where you are to where you need to be.

Jeff Wilk:  Very good. Well, Dan, thanks for today. I think it was a great conversation. We could certainly go on for quite a while on this, and who knows, maybe we’ll pick this up where we left off and dive into some other topics going forward. But again, thanks for your time.

Dan Garrett:  Thank you.

Bob Mooney:  Thank you for listening today.  If you’d like to learn more about our experts and how Oyster can help your firm, visit our website at oysterllc.com. If you like what you heard today, follow us on whatever platform you listen to and give us a review. Reviews make it easier for people to find us. Have a great day.