Dan Moore, cofounder of Vaporware, talks with host Adam Conrad about building software in-house versus buying off-the-shelf software from vendors. Moore explains the benefits, drawbacks, checklists, and frameworks for choosing when to build your own software solutions and when you should reach out to outside vendor solutions, as well as which vendor to choose and why.
Show Notes
Transcript
Transcript brought to you by IEEE Software
Adam Conrad 00:00:17 Dan Moore is CEO and co-founder of vaporware a consultancy delivering custom software to solve challenges or disrupt industries. Recently Dan’s also become co-founder of the Apple waiting a virtual waitlist for brick and mortar stores during the COVID 19 pandemic. Dan brings a decade of software development experience and leadership as a founder and engineer. Dan, thank you for coming on software engineering radio today.
Dan Moore Thanks for having me, Adam.
Adam Conrad I’m really excited to talk about this topic today on build versus buy, because it’s actually very close to home for me. My day job, I worked a lot with software as a director in one of the recent discussion I’ve had was around build versus buy on software. We had to decide between some external service that we wanted to use versus building it ourselves. So I actually really want to start with a scenario to frame this discussion, and then it sort of asks you for advice on how you would approach these things. So yeah, I basically want to just dive right in. I’m not going to reveal any sort of details about the specific implementation we had, cause that’s not really important. What’s important is how you frame things and start to create decisions around this. So, you know, the basic sort of context is you need a tool that does X, Y, and Z. And in our particular case, we had already built X and Y. So a subset of bets, and we found that there was software that built Y and Z. So there was some overlapping pieces, but there were also pieces that we had that the customer or the vendor couldn’t offer. And then the vendor had a lot of things that we just didn’t have time to build. So, you know, what I want to frame this conversation is if you’re a person out there who is making this build versus buy decision, how do you start to think about choosing between these two options?
Dan Moore 00:01:54 Yeah, I think that there’s tons of factors and a lot of it comes natural depending on what we’ve done in the past as individuals. So my background, I’m a software developer by trade a computer science graduate. I’ve been programming since before I can remember. And my natural tendency has always been like, let’s just start building that’s, that’s a problem I can solve it. Let’s do it over the past eight years with our consultancy, I’ve really had to go into this, this mode. What is the business need? What’s what’s the business trade offs? What are all these different things that we have to evaluate? So cost is definitely the first thing that comes to mind. Just what are we financially spending? But there’s also a lot of other types of costs and other types of rewards that we like to evaluate in the work that we do. So even once we decide to build and solve a problem, there’s tons of choices on, well, do we buy or build every single little piece in between? And there’s some other options in there too, of can we partner, can we acquire or can we integrate in some way and all the hybrid options in between, uh, once we get down into the, nitty-gritty really start to become clear as we go through those options. So for this one example that you’re talking about, what’s, what’s kind of that background or that, that history of, of the team that got together to, to make these things.
Adam Conrad00:03:23 Yeah. And I think the important thing here is that cost is a very blanket term, right? Like there’s costs associated with what is the sticker price of the vendor software you’re going to buy, but there’s also the cost of what would it take to implement ourselves. And I’m guessing what you’re talking about with history here is do you know what the capabilities of your development team are? How much are you paying them and what would it cost in terms of, you know, people hours to actually build this stuff over the next and number of months? So what kinds of costs when you, when you’re breaking it down, how are you evaluating costs?
Dan Moore 00:03:54 That’s both in terms of full-time employee equivalents, it’s in terms of not just the initial build costs, but the initial discovery costs of what exactly is it that needs to be built, there’s hosting and longer-term support costs. But I think one, one thing that’s often overlooked in terms of cost is also the opportunity cost of, well, what else could this team be doing? So not just what is the cost of this solution, but what is the cost of the other solutions that they could be building? So those are definitely some of the factors that we consider for actually dedicating a team or even just a single person and a couple of hours understanding what that value that they’re bringing and creating is about.
Adam Conrad00:04:38 Right. So when you talk about opportunity costs, you’re really talking about, are your developers, or are the people on your teams building the most, I guess, IP defensible work that they could possibly do, right? Cause if it’s, if it’s commodity work with commodity software, why would you have them reinvent the wheel when they could do something that is valuable to just your business? Right. Exactly.
Dan Moore 00:05:00 So what is that competitive advantage that you and your organization has and what do you really need to be the experts on compared to, um, you know, are you just reinventing a small piece that someone else is already the expert on that can get you five times the distance and half the time to integrate it? So there’s, there’s definitely pieces there. And let’s say, you know, you’re really saving $500 in sticker price on having your team rebuild this solution. That’s, that’s already out there versus the $5,000 that your organization can be making in terms of profit from them building and working on the next feature that no one else can do.
Adam Conrad 00:05:41 And are there any hidden costs that you consider as well too? Because I imagine it’s not just as simple as this vendor software costs X and my developers costs X per hour amortized over their salaries. There must be other sort of costs that you sort of factor into in terms of, you know, opportunity costs that might, you know, change the dynamics of how you evaluate this decision.
Dan Moore 00:06:02 Absolutely. So there’s a lot of hidden costs when buying solutions off the shelf and we see that in terms of integration costs or cost to other sides of the business. So if you’re not building software that is unique and specifically tailored around your business operations, that you already have set up your buying software off the shelf and have to readjust the business operations to match the software. So sometimes that’s a really good thing when that’s a general industry practice gap, accounting principles, for example, of multiple accounts and being able to recognize books and revenue the proper way that makes sense for outside auditors. That’s a really good thing to push for is industry standards. But if it’s unique to your business and like let’s say you invoice on a completely unique schedule and type of payment process, then that may be something that you need custom, that you don’t want to change your business and change the ultimate and business opportunity for. So it’s not always black and white in terms of like, we buy this thing and it just magically works. It’s okay. Now that we have it inside of our organization and now that we have access to it, how does the organization Morphin change around that?
Adam Conrad 00:07:18 Yeah, that reminds me that the way we kind of evaluated this was through a spreadsheet. We basically made this massive spreadsheet of all of the things we needed, a kind of software to do, whether it was our own or an external vendor or some hybrid approach. And we just looked at all of them, like I said, the vendor had X and Y or we had X and Y and the vendor had Y and Z and we just enamored it through all of the options. And then basically looked at, you know, which ones we had. We had built ourselves already, which ones we were planning on building and which ones we knew we weren’t gonna be able to get to any sort of reasonable future. And one thing that kind of came up that helped us in our decision was well, okay, what’s the 50% of the things are built by the vendor and 50% are built by us.
Adam Conrad 00:07:57 Well, what’s the priority of those things. So, you know, we looked at some of them and we said, well, actually, you know, these things we don’t have, but they’re also on the lower range of importance for us. The things that are really important to us, some of them might be from the vendor, but others might be things we’ve already built because through customer requests, we knew that those were really important to tack them now. So priority and ragging, definitely, I think is another one that was a big decision for us in terms of how we’re going to evaluate a vendor versus what we’re going to build in starting to think about a framework or a checklist for may starting to make this decision. What, what kinds of things do you put in a spreadsheet? Do you even go to a spreadsheet? Like how do you start building out this kind of list of evaluation criteria?
Dan Moore 00:08:37 Yeah, I think, uh, uh, spreadsheet’s a great asset for larger decisions, but we make decisions as I kind of alluded to earlier on, on an individual feature function basis. I think one, one thing that a spreadsheet’s really good for is that you are creating this very dynamic list where you can wait and, and measure these different options accordingly. But I think that it’s also not just a checklist where it’s down a single side of yes or no. Does this function or feature exist? There’s a lot of different variables on, well, how well does it do that or not just the priority, but the importance in terms of are those features exactly related to the business or, you know, are we going to have to adjust and come up with hidden costs for each one of those features? So what I mean by that is, is there are some other techniques.
Dan Moore 00:09:34 Um, we use a technique when actually mapping out what software needs to do called user story mapping. And we do a slicing technique and it’s, it really comes from product management of, you know, you’ve probably heard of like must have or nice to have in terms of priority, but this is in terms of every single story underneath a feature. And I think breaking it down into that specific level where you’re not just evaluating features and does this have the ability to create accounts it’s okay, how specific can we get into accounts? And every single action, we really liked the technique of, of user story mapping to get into all of those details. And at the end of the day, that’s a ton of work and a ton of stuff to manage, especially when you’re dealing with, well, a question of, should we build our own CRM or should we adopt Salesforce or a huge platform like that? It may be too much, but for most of the decisions that we work through, we love that technique.
Adam Conrad 00:10:35 And do you have to do that for every single kind of vendor? Cause I would imagine, like you just mentioned Salesforce and the first thing I thought of was, do you need a framework like this for Slack, for Stripe to get through some of these, they almost seem like no-brainers, but there’s definitely other ones where it’s it’s much fuzzier territory. So do you have prescriptions for certain sort of no-brainers versus ones that require more effort?
Dan Moore 00:10:54 We recreate a lot of stuff over and over again in just the type of work that we do when we build products from scratch. I think the one that came to mind was, was Stripe. That is something that we just returned to that just the cost in general of choosing a different vendor Braintree or something like that. Or, and there’s tons of payment systems out there. Now that handle a lot more than just the API approach. So charge B and billing into a subscription SAS model and how much control and how much refinement do we need over that. So we have that playbook and we don’t return to that in most cases, but at the same time, when we have the opportunity, we are out there evaluating new cases and seeing what those trade-offs are. And so we’re making that investment for our clients so that we don’t have to make it on every single new build.
Adam Conrad 00:11:47 That’s actually a really good point that it’s not just build versus buy. It’s also buy versus buy. You could very much, no. Okay. Totally not going to roll our own payment software, but we don’t know if we’re going to use Stripe or Braintree. So do you have specific kinds of checklists or modifications if you know, it’s not built versus buy, but it’s like deciding between different vendors. Yeah,
Dan Moore 00:12:06 Absolutely. Vendor size is huge. And so this is where, um, it actually gets a lot more complex. Is that for most of these, you know, you have your major players in the market and if it doesn’t matter, if it’s not too crucial, like you’re just starting out in the marketplace and you’re just trying to prove product market fit. So we don’t even need to really care about, are we choosing the best credit card rates that are out there and are we negotiating with all these different vendors? Because our volume is really low. Yeah. Throwing strike, you know, call it a day and move on. If we need to get into some of the very specific details of, you know, there’s a large cost benefit analysis between these vendors. So we’re, uh, we’re a bandwidth partner and bandwidth does communication pipeline. So SeaPass is essentially a Twilio competitor that allows you to do messaging and voice APIs directly to telecom providers.
Dan Moore 00:13:01 And one of their major advantages is that they’re a lot more cost-effective than Twilio because they are a telecom provider themselves. So those benefits and where we see a lot of people choose bandwidth is after they’ve used Twilio for awhile and they need to take advantage of those, those cost benefits because they’re seeing such massive scale, but starting out with bandwidth while you’re just testing a business model, you might not need that scale. And so you might be able to take advantage of Twilio, self-service onboarding as opposed to bandwidth that you need to talk to a salesperson. So it’s not just a one and done it’s all throughout the life cycle. Whenever you integrate with these partners, you need to make those decisions. So other things to consider in there are definitely around what’s the size of the company, who are they owned by? Can you choose AWS if you’re competing with Amazon, can you choose to use get hub if you’re competing with Microsoft now, because they just got acquired there’s tons of options and things to evaluate and things to consider for sure.
Adam Conrad 00:14:04 How much does brand factor into your calculus? Cause you’ve mentioned that sort of made me think, like, how do you convince a company to go with, what was it SeaPass instead of Twilio, right? Because even if it doesn’t completely fit your solution, oftentimes brand is like a big thing that really draws people. Like I just, I remember from many years ago, one of my previous company, I remember trying to convince people to use Mithril JS, which is this really small sort of MVC frameworks that kind of competes with react. But I mean, it’s, it’s a super small brand. It doesn’t have a lot of big backing like react does or something like that. And so, you know, brand is a big factor because what comes with brand is support and maintenance and enterprise offerings. So how do you factor that in when you’re trying to convince someone like, okay, this might actually be the right solution for your size company, even though there’s a bigger sort of stalwart out there that is, you know, arguably has a better brand and better support.
Dan Moore 00:14:59 I mean, I think you hit the nail on the head in terms of what that brand actually means at the end of the day. The thing we hate as developers the most is when someone comes in and says, well, I just, I just read this. And I think the thing we come up with is, uh, an airline magazine before COVID it was always executives traveling on airlines and reading about it and saying, yeah, let’s do this. And let’s change our entire company technology architecture based on what I read in sky magazine or whatever. And what that means at the end of the day is what’s the supportability of it longterm, how’s it going to stay around? What are all these other factors that come from it? I think open source in particular, you brought up Mithril is a really interesting point because we look at things as detailed as how many stars on GitHub or how many issues or when was the last commit and how maintained is this open source?
Dan Moore 00:15:47 Because open source is not just buying it off the shelf because you have the opportunity to fork that repo and change it yourself. And if the licenses allow you to contribute back into that community and be a steward of that. So it’s closer to an acquisition of software than just buying software off the shelf, because you can get into the internals and you have a lot more control over that software. So as opposed to you’re using a close framework from Apple or Microsoft, traditionally, you’re not able to really get into those internals and you just have to wait for them to patch it whenever you have a bug. So that whole partnership conversation changes. So there’s tons of details. But I would say that one of the biggest things is just long-term supportability. How are we going to be able to train people and find other people in the marketplace that know these technologies and can ramp up on them quickly? Or is that a cost that we’re going to have to pay that, Hey, if we invented our own framework and to compete with react, our, that internal framework, are we going to have to train new developers on it? So there’s tons of details in there.
Adam Conrad 00:16:55 I will eat my words. If I ever find a developer who reads sky magazine and finds out about some new JavaScript framework, that would be hilarious. But what it did remind me, did it really happen to you one time because that how you thought of that,
Dan Moore 00:17:08 That was more of an executive that wasn’t a developer. And he was like, ah, you know, Braintree’s doing this awesome stuff. Let’s use them over, over Stripe. And it’s like, well, really like, okay, we can ramp up on new technology, but this is what it’ll mean longterm and yeah, there’s all sorts of stuff.
Adam Conrad 00:17:24 That’s so funny. Well, it did actually remind me of one piece, which is, you know, you mentioned that in open source software, you have some agency to modify or forth the software, but you also kind of do with vendors too. And one of the things I was going to cover in vendor management is this idea of custom integration. So before we get to that part, let’s, let’s start talking about sort of the buying solutions, because I think we’ve with open-source software, it’s a lot easier because you don’t have to pay any money, but for these bigger vendors, especially like Salesforce, where you could be writing really big checks, there’s a really strenuous process to go through when you start thinking about these bigger vendors. So, you know, just from the very beginning, how do you approach a vendor with an intent to buy, especially if you’re, you’re looking at multiple vendors.
Dan Moore 00:18:03 Yeah. I think as a customer getting into the right channel and positioning yourself in the right way, that’s, that’s really attractive to the vendor as a technical team, technical enabled organization. Like if you’re just a buyer of off the shelf software, versus you’re looking to integrate a solution, getting your technical team involved as quickly as possible. So having them evaluate from a user standpoint, what those APIs look like, what the details of those API look like, what’s their support contracts and getting into the nitty gritties is often overlooked. So we were working on a marketing project and an ad project recently in the ad tech space and integrating with the trade desk was really interesting because they’re leading the market in so many ways, but they also have their own proprietary API. That looks good on the surface, but has a lot of problems still because they are innovating so quickly. And so really understanding what that support contract looked like, I think was incredibly important from a vendor management and relationship perspective.
Adam Conrad 00:19:12 So you mentioned the technical folks you want to bring in the conversation. Tell me, tell me what that first convo looks like when you’re sending out the zoom invite and you want to invite people onto that conversation with somebody else, from the other company, who are you bringing in? Are you bringing in all the engineers, the lead engineer, product manager who should come to that conversation prepared?
Dan Moore 00:19:31 So I come at it from the product management perspective. They’re the ones usually leading that conversation. Sometimes it’s led by technical of here’s a technical task that or goal that product management has created and that the technical team needs to fulfill in terms of feasibility. And so they’re doing some research there. Typically a lead engineer has enough context to understand the support, all the development requirements, product management is great. And then just the business side of it. So if product managers can, can handle the usability side, technical people can handle the feasibility side. Then the business managers need to focus on like the viability side and ask those questions. And really that tri force coming together should cover 99% of the work that needs to be understood and really hammer that out.
Adam Conrad 00:20:22 And then in terms of due diligence, how do you incorporate, like when we talked earlier about like a spreadsheet or a checklist, we know what you want to cover in general, but are there any particular items you really want to hammer home on that first conversation
Dan Moore 00:20:34 On the very first one? I’m I’m not so sure of if there’s any like quick wins to get you to a yes or no, maybe sticking points. So after the second time you’ve done this, if you’ve done a deeper dive on one vendor, you know, you really want to check that against somebody else. So for example, a big difference between bandwidth and Twilio is a voicemail detection on outbound calls. Right now that’s a limitation of the bandwidth API. It doesn’t have that functionality. And so we know right away when evaluating vendors, that that’s one thing that’s different between those. And just through past investigation, we know that’s a sticking point and then knowing yourself and your own organization, I think is really important of if you have any differences or ways of operating that you know, that most other buyers of software don’t have. That’s a really good way of saying just, Hey, real quick upfront, we know we signed contracts that look like this and we can’t sign contracts that look like that. So before we waste each other’s time, let’s just put that on the table.
Adam Conrad 00:21:41 Well, that does bring me to a good point back to my previous point about the custom integrations and sort of working software is one lever you could really pull is that if people want your business, just because they can’t do it now, doesn’t mean they can’t do it in the future. So, you know, is it worthwhile to start talking right away about custom integrations or what the company can offer? Because just because it’s not on the features, homepage doesn’t necessarily mean it can’t be done in general.
Dan Moore 00:22:05 Yeah. And a lot of companies, especially the smaller ones are willing to do a whole lot to gain that business. So looking at the size of their organization and what they’re planning on. So totally another example, we work with a small company startup out of, out of YC called courier. And essentially you have all these email providers like SendGrid and MailChimp that can just transactionally send emails, but they live on top of all those systems and allow you to send notifications just data to courier. And then they disperse it over whatever channel you want to use it. So email, text, anything else. And they, as a, as a company are really small just out of Y Combinator. And they’re willing to like say, Hey, you want to integrate with 20 other people have we’ll build them for you. We’ll willing to do that. So understanding what those companies sizes are and what their goals as a company are.
Dan Moore 00:22:59 So like, they’re talking about raising funding and when you raise funds, you care about traction. And so you’re willing to do a whole lot for that traction purpose and making it a mutually beneficial relationship. Like, can this become a case study? Can this feature be used for 10 of their other clients and really putting yourself in the vendor shoes of what they’re looking for? Like, that’s going to be a totally different conversation than going to Microsoft and talking to just an account exec and basically being like, does office support this? Yes or no, like depends on what you can really offer and what you can bring to them.
Adam Conrad 00:23:39 But in general, do you think it’s a good idea to say anything’s possible. I should at least come prepared with the idea that, Hey, things are negotiable. It’s not as black and white as whatever’s listed. Yeah.
Dan Moore 00:23:49 For the majority of companies. Absolutely. Totally depends on the size of, of who you are and what you’re bringing. We operate in a lot more of the startup space. So understanding startup vendors and what their goals are, are very different and, and absolutely have that mindset. But again, if, if that’s all that we are, and we reach out to Twilio and say, Hey, you don’t have this feature or this function, what’s the likelihood of that. Is that gonna, is that even on your roadmap and a lot of companies are starting to, to bring the roadmaps more public and have that information be transparent with their current customers, but that sales conversation is still very different.
Adam Conrad 00:24:29 And so, as it evolved, does that sales conversation evolved? I know you mentioned that in the first conversation, it doesn’t necessarily mean there are certain questions you have to ask Ben, but throughout the timeline of your conversations with a vendor, what questions do you absolutely have to ask? Like the things I’m thinking of are great limiting of the API APIs. If the APS are tiered legal considerations, I think you sort of touched on that public versus private documentation. You know, what things are you trying to ask them to get clear answers on at some point in the conversation,
Dan Moore 00:24:58 Absolutely sharing your requirements and your business perspective should translate into their organization and their sales team. So you mentioned rate-limiting, I’m just sharing here’s, here’s our project requirements from a technical perspective, like this is how many messages we need to send over over this much time. This is the strategy of how we were thinking of implementing your API. Does that make sense? Does that align to your requirements? Are there anything that we should look out for there asking them for that system design, a good salesperson will meet you where you are a bad one will make you translate that into their terms. So understanding those differences and what you’re looking for in that relationship, um, you mentioned just new features, understanding, like what is their professional service offering. And if they’re going to send you to a pro serve team like that to onboard into their system, or are they going to, you know, onboard you and support you as part of that contract for free? I think those questions really depend on a lot of the type of software that you’re looking for, but around support contract lengths and other legal considerations there matter. So the other thing on legal considerations that that comes to mind is for compliance purposes, how they treat your data is becoming so much more important these days with GDPR and CCPA changes that what your legal team needs to be able to support and share publicly about what you do with customer data is definitely part of the sales process for most SAS platforms.
Adam Conrad 00:26:45 Do you have any tips for talking about the sort of secret sauce? Because you know, one of the things I struggled with is if you tell them really everything about your business for the vendor in particular, you might get a clear answer on something, but there’s definitely this hesitation of, well, you know, they are another company. And do I really want to reveal certain secrets? It’s, it’s kind of difficult. It’s really hard. You know, if you say everything in a sense, uh, it could be very helpful in helping you find the right solution. But on the other hand, you don’t want to do anything that would be compromising for the most of your business. So what’s a good way to navigate revealing information when trying to get to the correct solution.
Dan Moore 00:27:24 We’re very opinionated on this. We take a lean startup approach, which has the mindset of be transparent about everything, share everything. An idea is worthless, but the execution is everything. And from that perspective, we tend to overshare. I don’t think it’s ever come back to hurt us in our eight years. It has only helped us. The standpoint that I could see where it would really hurt is if you’re talking to somebody that could be a competitor. At that point, we rely on the legal system of patents and protection from competition when sharing something that’s just very early stage in development. But the majority of the time, what we’re talking to other people about is far enough away from our secret sauce of our business and is more generally understood. There’s probably some other kind of smoke and mirrors that you could do of, you know, if you’re in the healthcare space, but you really want to have some kind of messaging system and you need to reach out to Twilio and get this set up and a vendor relationship. Then you could say, Hey, I’m in this other similar enough industry and not reveal all the details, but we haven’t had to play any of those games, even on behalf of our clients. That’s, that’s been our experience there,
Adam Conrad 00:28:47 Any red flags where you just, you know, regardless of the kind of solution where you just heard something from a vendor, or there was something that the vendor revealed where you said, okay, hit the eject button, them out, anything that you will look for, that other folks should know about when dealing with reliable vendors.
Dan Moore 00:29:03 Yeah. Business practices, how easy it is to get on a development team or how sales talks to a development team. As soon as you start seeing those inner workings of their company, I think is incredibly important. Anytime a sales person like gives you an effort estimate when you’re talking about professional services or something like that. And there’s just a lot that you can glean just thinking about it in terms of, well, if I was in that role, I wouldn’t want my sales team promising that or doing that thing that we haven’t had the opportunity to even like talk about or think about. So there’s tons of like, are they doing the same business practices and operating the same way that our organization or, you know, are they just trying to nickel and dime their vendors or something like that? Those are, those are big red flags for us.
Adam Conrad 00:29:49 That F1 is really interesting. So are you saying that giving an after estimate is a problem it’s that the salesperson is doing it on the fly on behalf of a development team that is concerning?
Dan Moore 00:29:58 Yeah. Yeah. I would definitely say that it’s like, who’s giving the estimate, have they talked about it before we hear a lot like, Oh, that’s really easy. We can just do it this way. And it’s like, well, is that really easy? Have you guys thought through this problem or are you just trying to marginalize the problem itself and don’t really quite understand it yet. And so having that experience of going through these integrations and building them and you know, what those support teams and contracts look like, there’s definitely being around the block and doing it so many times, you pick up on those people’s interest in incentives to say what you want to hear versus give you a realistic response to that.
Adam Conrad 00:30:42 Got it. So how does that factor into demos? Like who can you ask to show a demo? And when does asking for a demo the right time in the, in the sales conversation
Dan Moore 00:30:52 Demo, looking at, are they showing you spreadsheets and screenshots? Are they showing you current state or are they showing you future state is really important to suss out? You can definitely ask for a demo as soon as possible. That’s what most sales processes are. These days are either self service online or schedule a demo, getting behind and into the details of the demo. Asking for a free account is something that we do very often of, well, we just want to try this out, get the tires ourselves, you know, not have a, a salesperson there with us. So just like buying a car, Hey, like, can I give you my license and sign a paperwork or something like that to some degree that lets me take it out for a test drive, all that’s really common these days in SAS offerings, because it costs them next to nothing to do. And it’s only upside for them. So tons of techniques like that, that you can use.
Adam Conrad 00:31:46 Got it. So, you know, I think for certain ones like Slack, it’s really easy to get started. Cause you just download the software and it’s free and you just start playing around with it. I’m actually very curious about in terms of by evaluation. Like let’s say it’s a bigger piece of software, like Salesforce, where there’s an API and there are integrations and there’s a lot of legwork that needs to be done just to get it set up and running. How do you go about evaluating vendor software? Cause I can tell you from the example I had before we had like 80 something items that we had to enumerate through and it was a real slog to go, okay, well, what API connects to this particular feature? Is there a way that you streamline that process, you know, for the developers listening and they know they have to evaluate an API and the API could be massive. How do you actually begin to start looking through this stuff and evaluating it appropriately?
Dan Moore 00:32:33 Yeah. And in terms of quick wins or silver bullets, I don’t know if there is many, one of the techniques that we’ve done that may kind of fall under that category is we go and ask outside help. Hey, if you were to do this for me as a professional service, how much would it cost you to do it? Like you have experts on your team that have implemented Salesforce before, how much would you charge me to implement Salesforce? And so if you then extrapolate those numbers and say, Hey, they’re looking for 20 to 30% margins and they have experts that have done this before. You know, I could roughly think that why is now my costs for doing this? And so from a high level business evaluation that might tell you from a, like getting into every single store and every single detail, you know, that is designing out, creating those requirements and building that solution.
Dan Moore 00:33:26 That is a process of discovery that kind of toes, the line between, Hey, is this just evaluating the software or is this actually going in integrating it? And part of that integration. So doing it from the standpoint of, well, here’s what we need to integrate. What’s kind of abstract that and say, okay, well Stripe fits in here, but Braintree fits in this other way and how they process it, let’s design it for our problem space and our solution inside of our organization and then see how that modularly can swap in and out all these other vendors. And if it can’t be swapped in and out, that might be a code smell essentially of the design that says, Hey, maybe our design isn’t really well thought out in this area and we need to discover those requirements on our own because no vendor is going to necessarily do that for you. It’s really the part that your organization owns as part of the integration or buying of that software.
Adam Conrad 00:34:24 That Salesforce example is really interesting. So if I heard you correctly, are you saying that let’s say Salesforce says, yeah, here’s our software. You want to start evaluating it? Go ahead. Are you saying that you could sort of, I guess like additional calculus to this is you could hire an external firm. Who’s integrated Salesforce before and say, Hey, what’s the cost of you evaluating it for our integration? Is that kind of the idea?
Dan Moore 00:34:48 I wouldn’t say just evaluating it. I would say doing that full integration. Like if you were to hire a separate team to actually come in and do that integration, maybe there is an evaluation stage of that on how that works and what that is. For example, we built our own website. We made this decision when we wanted to buy versus build. We’re not a website development company, please don’t come to us and ask us to build your next website. That’s not what we do. But we went out and built our own website because one of the things that we evaluated was should we use HubSpot and their marketing platform to build our website? And we said, okay, well, how much is this going to cost us to build it? We didn’t know. So we reached out to a professional services, HubSpot company, and they said, it’ll cost us 45 grand to build what you’re looking for.
Dan Moore 00:35:34 And I said, okay, we’ll take out 20%. That’s how much it will cost me to build on top of HubSpot, if I had a team of excellent HubSpot developers and I didn’t. And so we said, okay, well, HubSpot’s probably not the platform for us. Like I don’t want to pay a BMW to build a website. That’s not the level of investment that we’re doing right now. So understanding and using that shortcut of, Hey, what are other organizations doing? What are they spending? They’re finding that experience share at the end of the day, allowed us to make that decision very quickly.
Adam Conrad 00:36:10 It’s an interesting, hidden cost. I didn’t think about which actually might be a savings if you pivot it the right way, which is okay, we know we’re going to buy Salesforce versus building ourselves because CRM software is definitely very standardized, but then there’s that sort of additional cost of, okay, well we could integrate it ourselves, which could have some additional costs or we could have someone else integrated, which is like yet another expense on top. But if the math works out that an external vendor integrating is actually cheaper than trying to integrate it yourself, you not only get the benefits of that purchase software, which does the commodity thing you don’t need to do. But in addition, you don’t even need to integrate it either because you’ve got somebody else who’s got more experience and can probably do it cheaper and faster than, than you could do an internal.
Dan Moore 00:36:52 Yeah, there is a double-edged sword to that. So we are a, uh, bandwidth integrator through our partnership. There were, um, an integrator of segment and a couple of other systems that we just have a lot of experience with through our partnerships. And the other expense is just getting that integrator up to speed on what your requirements are and what your business is. If they’re truly experts and they’ve done that dozens of times, then they should absolutely know that and have the right questions to ask and accelerate that process. But they should also just have a rule of thumb of, Hey, this is how much it costs to do that kind of integration. And this is how much it’s cost us in the past. So relying on that expertise and someone that’s been there. Absolutely.
Adam Conrad 00:37:35 Well, plus it’s probably not just bottom line too, right? Like if you’re hiring an expert, maybe part of what you’re paying for is the convenience, right? It doesn’t necessarily mean the cheapest is the best. It could mean that. Okay. Well, we’re actually going to go with an external vendor and it might cost us slightly more, but we know we’re going to get a higher quality piece of software. And we know we have an expert who can do it in a much faster timeline, even if you know, the actual cost of maybe 10% more of what we could do ourselves.
Dan Moore 00:37:57 And they’re typically willing to support that as well. So it’s not just an, an initial integration it’s okay. Now you’re integrated. Now you’ve got changes coming through. How do we build a longer-term support contract, like an extra warranty on top of the actual manufacturer of the software, if you will,
Adam Conrad 00:38:13 That’s a good point. So if you have made it to this stage and you’re like really ready to commit to buying, you know, what is a good proof of concept look like? How do you know when you have to play around with it enough to know, okay, I think I’m ready to use this. You know, cause one thing I have with my lead developers is if you’re going to dive into some really big software, you’re really concerned of, well, what about the unknown unknowns I don’t know about yet. And a lot of that only comes from actually just using the software. So how do you know when you’ve evaluated enough of it?
Dan Moore 00:38:41 I think you bring up an interesting point. Is, are you putting the right people in front of it? So are you putting the actual users if you’re buying an API, have actual developers looked at it or just your development leads? So those are some of your more expensive processes is actually creating and using that proof of concept to some degree. And all of the point of a proof of concept is saving money from actually going down a route too far and making the mistake. So it’s this, it’s this tight rope balance of have you narrowed down 10 vendors that were initially on your list into the two that you want your development team to look at to help you make that final decision. And from that standpoint, like they need to actually get into it and get into it from a use case and be held accountable from, Hey, you’re on the hook and are making this decision.
Dan Moore 00:39:32 And if you put that accountability behind them in the right way, where they get to make that final decision of Braintree versus Stripe, they’re going to be bought in and they’re going to do their work and not just give it a once over on their marketing page, they’re going to actually go through those, create that proof of concepts, maybe stub out some actual code and see what that looks like. And, you know, see if the proof is there. So getting the right people is what we as leaders can definitely do and rely on those people and hold them accountable and get their buy-in.
Adam Conrad 00:40:06 So it’s always going to be a leap of faith then, right? Like you never going to get perfect to answers before you actually signed the dotted line, but there definitely are. It sounds like there are certain things you can definitely look for before. You know,
Dan Moore 00:40:17 It’s more of what’s the risk level and what’s the confidence level, but yeah, everything is trying to tell the future to somewhat and no developer is going to be perfect at planning out every single case and finding those unknowns unknowns is like they’re unknowns for a reason. And the business might not even have all the requirements down. It’s about reducing that risk and reducing the unknowns and how much investment can you put in upfront before it’s too much before it’s just actually implementing it and would have been cheaper just to build something and fail at it three times before you do anything. So it’s, it’s this balancing line and this levels of commitment kind of thing is, you know, are you just dipping your toe in or did you just jump in head first?
Adam Conrad 00:41:08 All right. So now you know that you’ve done all the due diligence. You can, you have to make a decision. If you decide that you’re going to build instead of buy, how do you close out the conversation amicably? I feel like when you have a lot of intent, especially the further along you get in the sales funnel, there’s a lot of expectations about how things are going to proceed forward. Is there a way that you can ensure that you maintain a strong business relationship, especially if, for, you know, for example, you leave to not work with this vendor, but maybe two years from now might be the right time to work with them. It’s not necessarily a, no, it could be a, sorry, I won’t try a mater. Do you have any tips along those lines?
Dan Moore 00:41:43 So from a sales perspective, all knows that we see are not nows. And that’s how we look at everything is no just means not now in timing’s not right. You know, stars didn’t align. That’s fine. Any mature salesperson will understand that. Uh, especially if you’re in the same industry, the world’s too small, you’re going to run into these people again in the future. So being amicable is, is really important. The thing that I keep coming back to in the personal work that I do is just treat those people how you would want to be treated, give them as much information as you can if they ask for like, okay, well, who did you go with? Why did we lose? Don’t think of it as like, well, they’re trying to keep you on. And they’re trying to keep debating and getting you back in the door.
Dan Moore 00:42:26 You’ve already told them that you’ve gone a different direction, but give them the feedback so that they can improve and like stay on their mailing list and be open for them to reach back out when there’s a better time. I think sharing what you can and being honest and truthful is good, but also, you know, if they just walk away and stop communicating, realize that, you know, that’s part of that relationship as well and it’s business at the end of the day and people can be professional there. So I think it’s really about putting yourself in the other person’s shoes and creating, uh, an amicable relationship that may come back one day.
Adam Conrad 00:43:04 And if you start going through that build process, you know, what kind of signals are you looking for, where you realize, okay, maybe we do need to reach back out or, you know, our internal solution just isn’t cutting it the way we thought it was going to, I made a commitment to start building the software and we ran into some snags or the feature set blew up. And it was more things than we anticipated once we started building certain features that ballooned into a larger project. How do you know when you have to really commit and follow this through all the way, or when are the opportunities to reconnect or reevaluate, if you, if you really feel like maybe this isn’t a permanent decision.
Dan Moore 00:43:45 Yeah, I don’t, I don’t think anything is necessarily a permanent decision. There’s there’s all these factors are constantly moving. I think there’s usually some kind of pressure that says, you know, there’s outside forces to some degree saying, Hey, it’s time to reevaluate. And re-look at it to me, it’s always an opportunity. It’s always something that’s under constant evaluation, but it’s normally some kind of pressure that’s high enough. That’s pushing all the other pressures and all the other decisions out of the way and into priority. I don’t think that there’s a natural cadence, but we as an organization, for example, make it a goal like once a quarter and once a year to relook at different things. So we revisit playbook every single time we go through a single play in that playbook. So every single time we implement Stripe, we say, Hey, is Stripe the best option?
Dan Moore 00:44:39 Or has anyone like, is there anything else on deck that we should definitely check out before we get back into implementing Stripe the next time? But whenever we on a quarterly basis or on a yearly basis, we say, Hey, is our, our subscriptions up for renewal on this contract? You know, is there any other softwares there, anything else that we need to change about it before we get back into it and customer success teams are doing the same thing on the opposite side of those relationships. So they have account managers that look at renewal times and look at the value that you’re getting out of their products and definitely are on that similar cadence.
Adam Conrad 00:45:20 Okay. So on the flip side, then if you now know that you definitely want to buy instead of build, and you know that from the very beginning, how do you start comparing vendors? We definitely talked about that. There’s sometimes situations of five versus buy, but let’s say it’s down to two vendors that are both very close. You know, you want to choose one of them, but you’re having trouble really kind of getting into the nitty-gritty decisions between those two. And you’ve eliminated a lot of other possibilities. So how do you start comparing these vendors to find the solution that works for you?
Dan Moore 00:45:51 You’re at that stage where you’ve already narrowed down 10 into two, and you’re just trying to compare the last two. I mean, you can be honest and straight forward with both of those and even say, Hey, these are the two that I’m it’s between you and this other person. What are some of the differences that I should look at? And they are often much more versed in those particular details and might help you with some of that primer. But you know, most of the time, I think we’re very opinionated as people. And we have a pretty clear understanding that the pros and cons between the two and we’re just waiting on a deciding factor after we’ve laid out all the facts. So it’s pretty rare that we actually end up with two that are very similar in that there’s differences in company size and all these other factors that really go into a lot of our decisions. So I think as we’re a part of larger teams and larger projects, that’s where that decision gets bubbled up higher and higher from someone away from the details. And so it’s about presenting the details in the right way to that person that ultimately needs to make that decision. Okay.
Adam Conrad 00:47:01 Okay. So when you are talking about negotiation, we all know that especially in SAS software, there is no real sticker price. Like there are prices and of course, for the commodity offerings that they offer. But if you’re doing with these more custom integrations, it’s absolutely based on the size of your company, the size of the instances of the servers that are running, all that kind of stuff. So how do you actually start thinking about negotiating on price in terms of the more tangible things like terms, duration, rate limits kind of stuff. Yeah.
Dan Moore 00:47:30 I think that everything’s up for grabs and negotiating from the same place with your salesperson, the person on the other side of the deal, making sure you guys understand the same terms and understand the value of the relationship and what’s coming out there is incredibly important understanding their cycles and their quotas that they go through is incredibly advantageous to getting a better price. So like there are times to buy when they’re trying to meet their quotas on what kind of discounts that they’ve been given access to give and to handle. And so building that relationship and understanding that, and also being time effective with their time and just being like, Hey, I really can’t do that. Is there anything else that you can do? And just being like forthcoming and understanding that a sales person’s time is one of their most valuable assets. So helping them be effective with that is incredibly important. So just straight to the point, but in, in terms of like, what are all those options and levers that they can tweak? We just ask a lot at the times and say, well, what other options can you tweak here? And that’s very different for every single one of those companies, depending on what size that they are.</p
Adam Conrad 00:48:47 And how do you evaluate custom integrations? Cause that’s the one I feel like can balloon your costs the most and is also the most nebulous. Like if, if you price out some software and you say it’s $59 a month, that’s a, there’s a clear reason why they chose that price based on some SAS model. Right. But when they get into the, you know, you always see this on the pricing pages, you’ve got like the basic tier model, the enterprise model. And then they have some sort of like custom model and they never show the price. They just go and talk to us, which is usually language for, Hey, by the way, it’s a super expensive. How do you even go about evaluating whether the custom integration piece is a good value or is fair and reasonable.
Dan Moore 00:49:26 Yeah. I think that’s a lot of an internal perspective on our business. What’s the value of that integration? How fast is it get there? How fast is it compared to all these other opportunities of going out and getting another party to do it or getting theirs or getting our own team? I think one piece that’s hidden. There is okay. If they do this custom integration for us, are they able to go out and resell that custom integration? What’s the longer term value for them? Are they adding these as core features to their product? Or is it really a truly one-off for them and they never want to see or touch this again, kind of thing. So there’s definitely at least three other options are, can you get an outside vendor? That’s a complete third party to do this? Are they doing it? Or are we doing the custom integration or is it a hybrid model and understanding those options and those values and at least those costs is definitely important. So translating it to full-time employee equivalents is one of those factors that you can evaluate that price to see if it’s realistic or not.
Adam Conrad 00:50:34 Now we’re sort of rounding the corner here to the very end and we’ve made it all the way through all these decisions. We know we’re going to buy and we bought, and now we started doing the work. How do you keep track of progress and evaluate SLA is to make sure that the expectations you had from this vendor are match. Cause it’s one thing to go, okay, cool. We know this software is going to work for us. We want to buy, we bought, we started integrating, there’s obviously snags along the road too, because their interest is in getting your business, but not necessarily in following through. I mean, you know, sometimes just custom integrations can take longer than expected or their support team is not as prompt as you would expect them to be. So how do you keep the vendors honest and how do you make sure that you reevaluate appropriately to make sure that on the flip side of I built and now I sort of have second thoughts. What about if you buy, how do you know when you have to accept a certain level of unknown there? I guess
Dan Moore 00:51:31 The approach that we’ve taken is especially on custom integrations, it’s our duty as the end user, as the end buyer of that, to manage that as a project. So just like we would internally stay on top of those people. They might have their own project manager, but we can’t just let them go and not pay attention to those details. So we need to do our due diligence on all of that, along that side. So having our project manager that owns it, an internal champion, a product owner, if you will, if it’s more of an agile process, that’s going to take a long time. And then that person is responsible for your organization of communicating out what’s the status and all managing all the stakeholders on the buyer side, because you really need that clear communication and that clear priority as the bridge between the two organizations, you do not want 10 people giving that project manager different requirements and not having clear expectations.
Dan Moore 00:52:34 So from that perspective, that’s just project management, one-on-one on how we handle and how we evaluate that. If it comes down to like, Hey, this is really not working out and they’re breaking SLS and deciding when to drop them. I mean, there’s, unfortunately this whole problem is much more common in the industry than it should be, but there are, you know, some cost fallacies that you got to watch out for and keeping an eye on, Hey, we’ve already put this much money into it. Should we really chase that money with more money? And is that truly going to solve the problem or is that the underlying problem who’s responsible for that and who needs to fix that? And do we need to adjust contracts and, and come back to it. So, you know, if they’re constantly breaking an SLA, you know, is money going to fix that?
Dan Moore 00:53:26 Are they doing that because they’re trying to cut corners because you’ve negotiated the price too low and you’re no longer an important partner for them, you know, where’s that misalignment coming into play. And, and how do you move? There is a renegotiation.
Adam ConradGot it. Well, Dan, this has been super helpful actually for, you know, for me, just, not just as a host, but as someone who deals with build versus buy a lot in my day-to-day work, this has been a really awesome conversation. I really appreciate you taking the time today to speak with us on software engineering, radio, any final words or advice for people who are getting started in this world of build versus buy for their software vendors?
Dan Moore Yeah, I would say the biggest thing is evaluate buy more often, especially as software developers, our natural tendency is just to build right away and at the end of the day, is that the right business decision to make or not. So push against our natural tendencies and shoot for more. And, you know, if you need help as part of this journey and need help evaluating software, we, we do it a lot. Do it a lot more than I actually understood. We do it just by the nature of what it is. So feel free to reach out and you can find [email protected] and reach out to me personally. I’m just Dan and vaporware.
Adam ConradAwesome. Well again, thank you very much, Dan Moore for coming on software engineering radio.
Dan MooreThanks Adam.
[End of Audio]
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected].
SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)
