MIKE: Hello, and welcome to the Acima Development Podcast. I'm Mike, and I'm hosting again today. With me today, I have Kyle. I've got Dave.
 
DAVE: Hello.
 
MIKE: We've got Will Archer, and we've got Eddy. And we are going to be talking about something that comes up over and over again in the industry. And I'll just jump right into it [chuckles]. We're going to be talking about how to evaluate a vendor.
 
We talked about build versus buy, I don’t know, a few weeks ago, maybe a couple of months ago. Today, we're going to go specifically into strategies when you do decide to buy. And this also applies even if you're going to go with, like, an open-source project. How do you evaluate the vendor? You know, how do you choose when there's a variety of options?
 
And story time. Years ago...I think I can be a little open about this because the company isn't even in business anymore [laughs]. I worked for a company that did content management for publishers, mostly newspapers-newspapers and magazines, small newspapers. There's a lot of them out there actually. And we did a lot of their websites. And we were evaluating a partner, like, a business website builder. That's a common thing out there. There's lots of ways you can get your content out on the internet [chuckles]. And there are some niche products that allow you to do it in a specific way. We were looking for a partner to do it in this niche way.
 
And I'll get a little bit into the business model because it actually is interesting. With the newspaper industry, sometimes people think it was killed by other media, and that's a little bit true, but not really. Newspaper industry was killed by Craigslist because they made their money off of classified ads. If you're old enough, you remember that when you used to want anything, you'd go get a newspaper.
 
When you needed something like an apartment to go rent, for example, you'd go get the newspaper because everybody in the community knew it was there. All the business in the community knew it was there, and so they published there. And we were trying to come up with a way to kind of preserve that model where businesses could have a permanent presence within the newspaper website. And we were working with a partner to help with that.
 
There was a friend of somebody in the executive suite who had a company to do something that was loosely associated with what we wanted to do, who said, “Hey, we'll just use my buddy's company.” And they sent a tech rep over to get some evaluation. They did most of the stuff without evaluating with the engineering team [chuckles]. They sent one person over to the engineering team.
 
And I talked to this guy. He was their...well, I'll get back to that. But he was great. He talked very clearly. He was able to talk about their software. I talked to him about what you do with security. He answered it very well. He was able to talk about their stack. He knew what he was talking about. I didn't see any real red flags. And really, I was just supposed to be putting a rubber stamp at the end because the business deal was basically already made.
 
Well, when we went to integrate with these folks, we never saw that person again [chuckles]. Turns out he was their best person. And he was trying to keep the company running because nobody else really knew what they were doing. Very quickly, we saw glaring security issues. We had to send a password to them, which they could provide to us in plain text. So, they kept all of their customer passwords in plain text. If you don't know, that is, like, the quintessential security faux pas. You never save a password in plain text [chuckles]. It's just the wrong thing to do.
 
DAVE: That's not in OWASP anymore because we all know not to do it. That's the only reason...it would be top of OWASP if we were all still doing it.
 
MIKE: Exactly. The partner was a disaster. The security issues were just the beginning of it. They were hard to integrate with. They were a difficult partner. And they're not the only company I've worked with that was like that. We brought in a vendor, and then it was a disaster. And none of us want to have that.
 
I just read, earlier this week, there's a new website that allows you to rate your date. It's popular in urban areas where there's guys who will go around and be bad dates, mistreat their dates a lot. It's open only to women, apparently. It allows them to rank the guys and say, “No, this guy's a creep.” And they're happy about it, right? You can identify the creep.
 
There's lots of problems with that business model, by the way. There's some challenges. There's several companies that started it and then failed because it can be abused. But it'd be great if we could have something like that, right? You get some crowd-sourced, semi-objective information to say, “Yeah, this is a bad vendor.” But we don't. You never get that. What you get is more like what I got, like, here's the best person from this company. Try to evaluate whether they're a good vendor or not. You've got 10 minutes. Go. And it's a challenging problem. It's a challenging problem.
 
So, what do we do? How do we evaluate a vendor and determine they're the ones you want? How do you stack them against each other and choose which one to go with? And I've got some thoughts in here. I've got lengthy notes that I can start talking, but I don't want to do all the talking. I shared one horror story. You all probably have some as well. I'll kind of open the floor here. Do you all have any horror stories? And maybe you don't have horror stories. Maybe you've got positive stories. What are your horror stories, and what did you learn from it?
 
DAVE: I have a quick scoping question. When we say buying from a vendor, this can be anything from buying a $100,000 site license for some software, to purchasing, to, like we were talking in the pre-call, to contract houses where we literally...where this is the opposite of buying, that we're literally renting workers. But it's the same idea, right? We’re going to go [crosstalk 06:34] for money instead of for a high-risk [inaudible 06:37]
 
MIKE: Exactly. It's the same principle because our expertise only goes so far. There's only so much that you can build. And [chuckles] you're going to have to buy something, almost certainly, that's a rare company and probably doesn't even exist that can manage everything themselves. So, at some point, you're going to have to work with a vendor.
 
DAVE: So, I wasn't going to tell this story, but you just jiggled it in the back of my brain. And Eddy’s heard this story this week. I built a project 20 years ago that I called Data Monkey. It was all written in Perl, and you gave it a DDL, basically a schema, a DSL of a database schema, and it would go build your database for you. And somebody told me, “Have you seen Rails?” And I'm like, “No. What's that?” And they’re like, “Oh, you need to see this.”
 
And, Data Monkey, I had spent over a year and a half building this. And I was running a content management system for a bunch of online webcomics with it. It made us very happy. But it was clunky, and I was the only maintainer, and developing and adding features was hard. And I couldn't do migrations. I could not understand how to do deltas on a migration. So, you had to throw away the entire schema and then run Data Monkey again and build it all over again. It was a 1.0, right? It was a very early thing. And it only ran on MySQL because that was the only database that I used as a single person.
 
Somebody showed me the DHH's How to Build a Blog in 15 Minutes Using Ruby on Rails, the viral video that kicked Rails off. And I killed the Data Monkey repository, like, 30 minutes after watching that video. I'm just like, there's an entire team building out all the other database adapters. So, you get Postgres; you get SQLite; you get SQL Server. You get all that stuff. And they figured out, like, delta, like the harder problems that were still...like, I scratched the worst of my itches, but it just got harder and harder to reach, and deltas were in there.
 
Being able to pick it up and buy it versus building it yourself there is a huge, huge ego component. And this story has stuck with me because only after the fact did I realize, I really should have had some ego in this. This was a personal passion project that I was making money off of. I had every reason to want to defend Data Monkey, and I didn't because what I wanted was all of the features. And I wanted a full team supporting it and building it up. It helped that the price was free. I mean, total cost of ownership my time involved, like, the next 20 years of my career has been sucked up by Rails, so I can't exactly say it was free.
 
But I would say that, if you are in pain, and you are scoped down, and you're trying to fan out into something, yeah, don't build, buy.
 
MIKE: Well, did anybody have any, you know, I threw out my story of the awful vendor [chuckles]. Any of you worked with particularly awful vendors that you'd like to share that it's not, you know, maybe go back a few years [laughs]?
 
WILL: I myself have been a vendor, right? I myself have been a vendor, but I was, like, a solo freelancer running my own shop vendor. And consider the reliability of the narrator. But I had been successful at it, and people had been really happy about it. And people had been like, you know, generally pleased and happy to refer me, and hire me again, you know, when they had the budget, and they had work that needs to be done.
 
And I've hired vendors, and I've had a very difficult time with it. All the people who have hired vendors and then had a difficult time with it I have been, like, Mr. fix-it, you know, have pinch-hitting for vendors that didn't work out.
 
I was trying to zoom out to, like, and here I'm talking about, like, hiring development shops. And one of the issues that I think I always think about, like, sort of like the macro, right, like, what are the incentives that drive this thing? Like, get it in a messed-up state.
 
And what I'd say, economics of it are weird, or they may be unstable, right? Because, like, you know, I'll be straight up, right? Like, if you are a contractor, right, you're parachuting into some other big enterprise, some big project, some big codebase, some crazy thing. And you're going to drop in like SEAL Team Six, and you're going to get stuff done. That's hard, okay? It's just not everybody on your team that's going to want to do that, going to be able to do that. That is tough.
 
And, you know, to be totally honest with you, most people don't want to do it. Most people are just like, yo, I'm going to get in this codebase. I'm going to get familiar with everything. Like, I'm going to know who the people are, where the people are, what levers to pull, how to get things deployed, how to get things debugged, where the skeletons are buried, so that I can be more effective and be more productive as a developer. And that's a lot less strenuous a way to work.
 
And so, if you want to get some people like that, right, you want those people in, why are they going to do it, right? And so, it could be like, you could pay them a bunch of money, right? Hey, cash talks, flexibility of lifestyle. You know, like, I myself am a freelance gun for hire right now because, like, I'm at the phase of life where, you know, working remotely is pretty attractive to me. And even in our RTO world, there's still a lane for you if you can deliver the goods, and you're willing to work contract, you know? Like, there's a little bit of a loophole there, right?
 
So, where these big sort of, like, software developers as a service come in is there's a lot of incentive, I think, for the business to keep as much of that money as they can and then work the people as hard as they can. And it's very difficult to find a place that can sustainably, you know, hire and retain the kind of developers that they would need to be able to deliver on their promises and achieve them. Because, like, the business wants to make money. So, they make money when the cut is bad, and they don't make money when the cut is good.
 
And so, you know, you have a lot of people coming in doing a very hard job for, like, not a lot of money, and, like, that's not sustainable. Like, people who are good at their job will have other opportunities. So, the business just sort of, like, it just kind of degrades. And I find, like, there's an inevitable life cycle to these places is then, as they get bigger and older, they just all kind of fall apart in the same way.
 
MIKE: That's an insightful take about the challenges of a contract shop.
 
EDDY: I was going to say, I mean, I got to imagine, I mean, I don't have much experience with integrating with vendors or whatever. But I got to imagine that part of the decision factor when you're deciding to integrate or buy a product is how easy is it to request a change or a feature change, right?
 
Because maybe the product that you're buying doesn't fully encompass what your business actually needs, right? So, if you're trying to evaluate the pros and cons, like, you know, one can only assume, you know, is that something that you...is it a request that you, as a vendor, can...or as someone who has purchased it or licensed it, like, can they actively make that change themselves, or can they request a change? You know, what's the turnover on that, right?
 
MIKE: Well, you actually...you're touching on something, Eddy, that actually ties into what Will was saying indirectly, what I was thinking about before we got together. And you talked about them. Will they make the change? Do they have the features you need? There is a scale issue, which means the same vendor may not be the right choice for everybody, and, in fact, almost certainly aren't.
 
If you are a large, big, mature company, your needs are different than a startup. You might need all the features. You might want the enterprise plan and have the deep pockets to pay for it. If you're a startup and you're going with the enterprise plan, you're probably doing it wrong because [laughs] you don't have that money, and they don't care about you. You know [laughs], that big company, they're just trying to get money from other big companies. That's their business model.
 
And you might want to go with a small company that doesn't have very many features because, you know what, you don't need them. If they can give you what you need and it's cheap, that probably meets your needs. And your job is to stay afloat. Your job is not to spend all your money on a product that might work for you 20 years from now. And those needs are very different.
 
And, you know, Will talked about the contract shop, you know, growing and kind of degrading. Well, that can happen at the full enterprise level. But it also happens even within a single organization. You might get a team. They've got a new team, and they're great. Maybe even within your own company, you've got a new team. They're great. They grow to the point where they're not very manageable anymore. Maybe as you grow the pay is becoming more normalized, and some of the best people start leaving. You might have that exact same kind of problem happening within your company, and part of it has to do with that scale. And there's some tricky timing there.
 
The vendor you need today may not be the vendor you need 10 years from now, and you have to make those kinds of evaluations, both when you're hiring a team and when you're buying some software.
 
Think about a team, big companies, the real big companies, Microsoft, Google, they hire contract shops. They'll hire engineers by the thousand, and they have a longstanding relationship with them where they can manage these long-term things. They've figured out the requirements where they can make that work. But if you're mid-size, you're not going to get those precise requirements because you don't have the resources to make that happen, and if you're tiny, even less so. You're going to get what you get.
 
And finding a single really good engineer is probably going to serve you a lot better than going and trying to contract with some huge shop that is nameless to you. And they're just going to rotate through a series of people you don't know and probably don't care. But if you're really big, you can set up a long-term relationship that’s not so much different from your internal employees. There's scale effects that really matter here. And you've got to do some deep soul search here about where am I, and where am I going to be a couple of years from now? What is it that I actually need today?
 
WILL: And one of the things, I mean, you say there's not that much difference in terms of, like, you know, the difference between a long-term contractor and a long-term employee. Well, I'd say one of the big things...so, first off, why would you have a long-term contractor that didn't have a personal relationship with the company or a specialized skill set?
 
A long-term general contractor is like, oh, he's been on contract with us for five years. That's weird, and probably not...difficult to justify. Because one of the important things is if you have an employee, you have an understanding and a say in their working conditions. You know what I mean?
 
One of the problems with a contractor is somebody who...say they’re here with you for five years. So, they go from a junior, maybe not a junior, but, like, a mid-level engineer, all the way up to a senior, maybe even a staff. You can make staff in five years, if you’re a hitter, right?
 
MIKE: Sure.
 
WILL: So, you keep on bumping their salary because they're doing more for you. But are they getting it? Are they getting it? Is that money making it to them? Maybe. Maybe not. Maybe. You know what I mean? But possibly. But it might not be that way. You know, what's their working environment, right? What are the hours worked? You know, there's all kinds of things that are outside of your control. Like, a vendor might just say, “It's not your business. That's my business,” right?
 
I don't think, well, this is...we're going a little bit afield of the topic, but I don't think companies should have long-term core competencies outsourced. Like, you're always going to need QA, right? QA is your business. QA is your job. You have to have QA all the time. It’s like, oh, I'm going to get a QA shop to do my QA. Like, but why? Like, why? You can outsource stuff that isn't part of your core competency. But if you're running a software shop, QA, if it isn't a core competency, you need to make it one. You need to make it one today.
 
It's like, oh, well, we don't have a mobile team, right? I don't have a mobile team, so I'm going to outsource my mobile team. But you have a core part of your business is running this mobile app. You need to have mobile people running a mobile app because this is a direct line of business.
 
Anyway, I mean, there's always a line. But it’s like, I'm going to have these people work for me for five years. Like, just hire somebody. It's a right-to-work state, baby. You could fire people. Trust me. In the year of our Lord, 2025, you can fire a developer.
 
MIKE: Look, I'm not in disagreement because there's a lot of stuff I'm with you on, on what you had there. There are some circumstances where having a close relationship with a long-term contractor might make sense. For example, we've got a partnership with a fairly small contract shop in Eastern Europe. And we've had some engineers from there where it would be challenging for them to have a full-time employee because we don't really have a presence in Europe. But they're able to work with us on a contract basis, and they are just part of the team.
 
The fact that it's a contract is a necessity of the international labor exchange, but they are effectively part of the team. They are treated like part of the team. They have the respect of the team mutually. We respect them. They respect us. They meet with us. They act as an extension of our team that happens to be outside the office. I feel like that is a success story.
 
On the other hand, if you just have some generic person that you don't really know who they are, you give them a task, and then forget about it and come back a few days later, “Hey, did you get it done?” Well, that's a very different sort of relationship, one that you probably  should never have gotten to in the first place. But if you just maybe have the gun-for-hire person who really can get it done, but that becomes a much more challenging relationship to maintain, especially at scale.
 
KYLE: So, I'm sitting here thinking about this and vendors. Right here we're talking about developers and stuff. I'm thinking vendors and software vendors as well. You're talking about the size of a company. You brought that up a couple of times. That, I wouldn't say matures, that transitions, I feel like, as you go up the line.
 
If you're a smaller company, you're picking and choosing. You're going with anybody. You're really kind of nitpicking what you want within your budget. But I feel like that almost narrows in because when you're a small, mid-sized company, you're like, oh, I want this contractor. And you kind of get personal with them. You know them.
 
Where I've seen in larger businesses, it's, hey, vendor that we're using, we need somebody with this expertise. We don't vet them. We don't do anything. They hand us somebody, and then we try and work with them. It's kind of that same thing, but with software vendors that I've seen, too. But instead of the smaller, mid-sized companies, it's, you know, I can go with anybody. It's, okay, you can go with these guys because we have a partnership agreement with them. They scratch our backs. We scratch theirs. And you kind of get that partnership going on. Then your vendors are almost limited, and then you may not even be able to get the best resource for your organization because you have a limited vendor pool, I guess is what I'm saying. And so, like, I’ve ran into that in enterprise locations as well.
 
MIKE: That's interesting.
 
WILL: Yeah. I'd love to hear more from you, Kyle, about sort of like that...We’ve talked about this sort of like software consultant contractor thing. I would like to hear more about, like...the thing that I think is most interesting and critical is, like, okay, I'm going to get a vendor, and I'm going to get a big site license. I'm going to write a big check for a big license for a core piece of my business. It makes sense for me to buy versus build, right?
 
But I don't know these people, and I have two, three, four vendors that I could go with. I don't know them, right? And I'm going to be stuck with them for a year or two at least, even if they dog out. How do you vet people? How do you vet quality of service? How do you vet quality of support? Like, what are the questions that you ask to figure out, okay, this is what I'm getting into, right? Because, you know, they'll promise you the moon. The salespeople will promise you the moon. And, in the meeting, like, they're going to bring out the all-stars. But when rubber hits the road, how do you figure that out? You know, how do you vet?
 
KYLE: That's currently a problem that we're actually dealing with. Like I say, in kind of a [inaudible 24:05], or I'm just saying, in a company's atmosphere, we're more worried about money most of the time, right? And so, we're asking one vendor, “How much will this cost?” We're asking another vendor, “How much will this cost?” They're giving us a price. Well, that one's a little bit higher. These ones are giving us a price. They're not telling us who. We're not really interacting with who might be doing the work. We're not vetting those individuals out. They're just like, “Here, work with this team,” right? And so, there's that atmosphere.
 
And then when it comes to the software world, you know, SaaS products, it's a similar situation. And then it kind of gets even larger because you have engineers that will use the SaaS products, for example, that will have favoritism as well. One team will appreciate a product for the application monitoring. Another team will appreciate a product for their tracing capabilities, right?
 
Well, this SaaS product is really good at that one, and the other SaaS product is really good at this other one. And then, you know, they're not good at the other one. And it's like, we're running into that as well, and, like, how do we mesh that? That's actually one reason why I was excited about this conversation. I’m like, I need to know, too, because those are active problems that we run into day in and day out.
 
Now, I will say, when I've worked in smaller companies, it was much easier to meet face-to-face with the individual that was, like, going to be performing the work if they were a contractor, you know, and discussing because then it was easier to go back to your manager or whomever, the hiring person, whoever's writing the paycheck, and say, “Hey, I do or do not recommend this individual to perform this work.” But that's not been my experience lately. If that answers your questions, Will [laughs].
 
MIKE: Well, you know, you've raised a lot of challenges. And two vendors, they're both decent. They offer somewhat overlapping services, but they're not fully overlapping, right? And how do you go with which one? Which team do you choose [laughs]? And that's a tricky one because you're going to have to evaluate from a business perspective which department's more important to get their needs met. And that's hard.
 
KYLE: Then there's a lot of time where it's like, consolidate to one vendor, right? There's always a push from upper management, “Consolidate to one vendor,” when it's like, well, they both facilitate our needs in different ways. And it's just like, go lesser evil, I guess. I don't know.
 
MIKE: Well, one thing you can do is, sometimes you're going to lose something, right? You can't win every battle. There are some cases where you can legitimately make the case, but you've got to speak with money. You can say, “Well, if we consolidate on a single vendor, this is what we're going to lose, and this is how much it's going to cost us.” And if you can compare costs and say, “This will actually cost us more year over year,” that's a pretty easy argument to make to people who are trying to save money. And if you can't make that argument, then it's uncomfortable.
 
But you might need to look a little bit inward because they have accountants for a reason. They've got a finance team for a reason, or a spend management because things do tend to get out of control. And you're combining departments, you know, buying, doing acquisitions. Sometimes you're going to get redundancies. And going with a good enough solution, you're going to have to give something up. And that's always painful, but it might still be the right answer.
 
WILL: Is there a counterargument to having somebody else bidding against them? I mean, you don't want one vendor for everything, do you? You know what I mean? You know, going at...payment processing, it's nice to have a few payment processors, where they just say, “This is your [inaudible 27:50] I'm like, I don't think...for all the traffic? Maybe not, you know.
 
MIKE: So, single points of failure are very much worth the cost to avoid at scale. Again, startup may be different from enterprise. But as you grow, the more those single points of failure cost you, you know, if something goes down.
 
We certainly had vendors go down before. And recently, we’d mitigate a single point of failure. If a vendor went down, like, hey, well, we've got a backup [chuckles]. And it was fantastic because we had done the work. And we were in a position of much more strength.
 
WILL: Well, I mean, not for nothing, but, like, you know, business organizations can fail, too, and they fail in different ways. But it’s like oh, well, you know, founder decided he wanted to cash out, get that private equity money, buy a boat. God bless you, you know, I'd love that for you, but I might not love it for me so much.
 
MIKE: And then changes in ownership can have a big impact on what that company is doing for you. A number of times, we've gone with a vendor because we preferred their product, and then they got acquired by their competitor [laughs]. And there you go. You didn’t really [crosstalk 29:10]
 
WILL: That's a for real thing. It's a big thing to think about in the software space just because, okay, so let's say if you're going out and your vendor is a venture capital funded company, right? You know a couple of things, you know, with a high degree of confidence, never 100% confidence, but a high degree of confidence. They're on a burn rate, right? They're funding. They're funded, and they are spending more money than they take in for growth because that's what venture is like. Otherwise, you're just a private company that has some investors, right?
 
And the venture model, 90% of those companies fail, right? You know that, right? Those are just the rules. Those are the cards you're betting on. So, fold or acquire. Or, you know, maybe they get a lot bigger, you know, and they get a lot bigger. And they go from, like, a series A kind of a thing to a publicly traded kind of a thing.
 
That's a brand new company. That's an entirely different organization, and it's going to happen fast. Two years, they're either a completely different company because they won or a very different company because they lost. But, like, they will not be the same company two years down the road. It won't happen structurally.
 
KYLE: That goes into, you know, acquiring companies, which is, I think, what you’re saying there. Where we’re at, we have Acima. We have RaC, and we have Brigit under our Upbound umbrella. And all of these have different ecosystems that were already in place. And then, how do you consolidate those to the specific vendors, right?
 
Like, so, when you're acquiring these companies, big or small, how do you make that transition and decide, you know, well, you've got a large group of people over here that they prefer this vendor? However, the core organization uses another vendor. How do you consolidate? And that's a hurdle, too.
 
MIKE: And somebody's going to not get what they want. Somebody's not going to get what they want. And, sometimes, those decisions do come down to money. Sometimes they come down to size. Well, more people want this vendor than want this vendor. Or the costs to transition are going to be huge.
 
A very specific one that I think I can share...You talked about RaC and Acima. RaC used Microsoft, and Acima used Google Docs, and we had to choose, right? And, in the end, the tech company who was able to, you know, navigate tech are the ones who had to change because they could [laughs]. They didn't get what they wanted because it was a core competency. They were good at dealing with tech changes. And so, they didn't get what they want because they were good at it [laughs].
 
And it's a little painful, but it's probably still the right decision because the cost to go the other direction would have been really high and really painful for the company. And that's a difficult choice and not one that made us, on the tech side, very happy because we had to change. But it's still probably the right decision.
 
KYLE: I had an older engineer that I worked with when I was at NCR, and he made a comment to me one day. I grew up in a mentality...I was very fanboyish. I liked what I liked, and I didn't want to go outside of it. And we were a C# shop at the time, and we were transitioning to being a Java shop. And so, I was kind of teasing him, and I was just like, “Hey, you know, are you going to hate this? Are you going to stick around?” And he's just like, “I'm absolutely going to stick around. I'm a software engineer.”
 
And I was just like, “I don't quite understand what you're saying there.” He goes, “I'm not a developer. I am not a software developer. I am not tied to a language. I am an engineer. I will use whatever tool the company provides me with, and I will get my job done.” And I feel like that's kind of stuck with me, in the sense of, like, that should be everywhere. It's just, you may not get what you want. You may not get what you've always wanted to work with. But they're all tools. Figure out how to use them for your job.
 
MIKE: Nailed it, right [laughter]? One thing I wanted to bring up here that we haven't talked very much about are red flags. Because we talked about sometimes you're not going to get what you want. And we've talked a lot about going with contract vendors, you know, with the contract shop you go with, and how scale matters, how there's some challenges with that relationship altogether that you need to be really watchful of. But just in general, and this probably applies more to buying software that you're going to use, I think that there are a lot of red flags. I compiled a list coming [chuckles] into this call because there's a bunch of things that I've seen.
 
And I mentioned the first one in the intro, security issues. If you do a security, in fact, we recently...unnamed vendor. We evaluated a new vendor. They looked like they had the product we needed. The security team looked at it, and they got an almost failing score. Like, oh, actually, never mind. We're not going to go with them. I feel like any security issues are an indicator of something deeper. If a company doesn't care enough to take care of something as fundamental as security, then what else are they not taking care of? Every time. So, I started listing companies that I've seen security issues on, and it was just a debacle [chuckles].
 
Way back to right at the beginning of my career, company security issues, total disaster, maybe even sunk our company I was working with at the time. I mentioned the one earlier. I've seen, more recently in my career, partners where they were real fast and loose. They were really willing to share sensitive credentials over insecure channels. As soon as you see that, like, wow, that's not a partner I want to do business with because it's a symptom of an organization that doesn't care.
 
And it's led me to think, well, there's a strategy. If you can somehow, like, ask them, like, “Could you send us some credentials?” You know, ask them in a sideways kind of manner. Give them an opportunity to do something wrong and see what they do with it. You could probably learn a lot.
 
So, there's my first one. Security issues are a huge red flag. And if you can somehow find a way to allow them to reveal their nature there...and you can't always. But if you've already got a contract with them and you learn that they have those, it's time to start looking for somebody else because, in my experience, it never works out well. Like, they're not going to fix it. Thoughts?
 
WILL: I love it, man, just the idea. Like, maybe more broadly is, like, are they minding their Ps and Qs, right? So, not, like, the salespeople, right? But, like, is the contract, like, is the contract right? Are there, like, just goofy things? Like, you know, like, they messed up the contract. They messed up...there are typos in their stuff, like, not in what they say, but, like, in that.
 
You're looking for, like, I think the quality, the personality quality, is called conscientiousness, right? Conscientiousness. Are the Is dotted? Are the Ts crossed? Because you can see...if you're doing enterprise stuff, right, like, big enterprise things, there's work product, the kind of work product that isn't a good sales guy doing a good job, right? Like, the guy just, like, boring, gritty, pick-and-shovel, get-it-done stuff that is, unfortunately, enterprise software development. You can see that. That will leak out if you're looking for it.
 
MIKE: And, you know, taking that a little further, next red flag I was thinking about, is there legal action against the company? Now, if they get big enough, pretty much any company has probably had some sort of legal action, which may have more or less credibility. But some stuff has very obvious credibility [laughs], right? And, you know, if there are multiple attorneys general signing on multiple times, it's a red flag, at least, that maybe there is something not going right. And it goes back to the care. If somebody is careless about their customers in that way, they may not be treating you very well either.
 
WILL: I mean, I'll say, as a small shop, like, I'll say two things, right, like, here I am generally showing my ass a little bit. I'm not a voyeur, and I'm small, and I don't have, like, you know, all that stuff. But I have definitely...when you are a little fish in the pond, there are a disturbingly large set of people that will bully you through the legal system. I have been involved in more than one or two legal actions, all of which, every single last one of which was somebody trying to rob me and then saying, “Do something about it.” So, you know, beware, but I would say that, like, a bigger company would have learned their lesson the first time, right?
 
MIKE: [laughs] Well, that's why I try and preface that. Well, pretty much every organization is going to have spurious legal action, or at least in a gray area, where, well, yeah, maybe, you know. There's somebody who doesn't want to pay you, and then there's Enron [laughs].
 
WILL: I get patent-trolled. Like, do you get patent-trolled? I got patent-trolled, you know, and it's just, like, bro, what?
 
MIKE: [laughs]
 
WILL: Taking a credit card, like, that's the patent you're going to come and get me on? Like, if you could really afford that patent, you wouldn't need my money [laughter].
 
MIKE: Yeah. So, at the end, there's a tricky one. It's not that there will be no legal action, but you should at least look. You should at least look. And it's not like companies I've worked with have not been involved in legal questions before. But I've left a company before because they were doing some legally questionable stuff, and I'm glad I did. You know, there's a line, and a great deal of it from reliable sources often means something.
 
WILL: Absolutely. Yeah. Yeah. And I'll say this, especially legally, you know what I mean, highly regulated industries, you know, minding your Ps and Qs. Acima has always been scrupulous in following the law to the letter. Other big companies that I have worked with they've all been on their game. But Acima is definitely the leader of the pack in that regard. The current gig is a close second, but, like, yeah. This is the financial stuff, right? You've got to have it together.
 
And, like, living in Utah, I will say that Utah...there is some business in Utah. We do some stuff in Utah [laughs]. I'm not familiar enough to pursue that one. I’ll let that go. That sounds interesting.
 
DAVE: I am, and I'm also not going to pursue that one, at least not on the call [laughter]. We’ll talk afterwards.
 
WILL: You can just do a quick Google. And this has nothing to do with me. But how many Utah attorneys general have gotten indicted in the last 20 years? A lot more than you think. I think we're batting over 500. I sincerely, hand to God, I think we're batting over 500. This isn't Mississippi, man [laughter]. What are we doing?
 
MIKE: Illinois has had a streak with governors [laughs], so I can relate a bit, and other political entities. Moving on.
 
WILL: You also have a reputation. Yeah, moving on [laughter].
 
MIKE: Impossible promises. If they're promising you the moon, walk away. Just walk away. It gets to some of our biases, to wanting what they have to offer.
 
Relevant story here. So, this isn't a vendor, but I'd say it was an employee I hired once who was doing some sales, or business sales, like, relationships. And he made some big promises, and they all turned out to be hollow. And we listened because I'd actually done work with the guy before, and he'd brought me business before. He seemed credible enough. But I got that bias, like, oh, this sounds like the ideal work for me and my shop. And so, I overlooked some of the red flags there. It was too good. It was too good. And got to watch out for it.
 
So, on the flip side, I've got a list of green flags as well. A vendor should be boring. If they're boring, that is the biggest green flag ever. If they're boring, that means they do their job and it's not all marketing. There's nothing better than a vendor who is just, like, watching paint dry, right [chuckles]? You know, there is nothing interesting about them at all. That is your first choice. Because --
 
EDDY: So, I'm halfway there. Is that what you're saying?
 
MIKE: [laughs] So, boring, great sign. That means that they know what they're doing, and they're probably doing it really well.
 
So, going back to the...well, I'll give an example of impossible promises. And I'm going to make a positive shout-out to Google here. They were pitching us on some tools, some AI tools, and they told us what we'd get from it. And it was honest [laughs], and it was not a huge, dramatic change, but it was something that could make a meaningful business difference.
 
And it's hard to argue, you know, that was such a good sign. It was such a positive sign to see somebody who would give you honest assessment that was not going to make everybody jump up and cheer, but was something that would be enough to make it worth it. You know, it's always possible that the numbers weren't perfect, and they probably weren't. They weren't for many vendors, you know, from any...it's hard to get a perfect number. There's maybe no such thing, but it was believable.
 
A couple of other red flags I thought of: possible conflict of interest with internal leaders. I mentioned that with the vendor at the beginning of the call. You know, if somebody might be getting a cut, or somebody has a long-term relationship there, you know, you want to tend to trust that, like, oh, so they know them, so it’s good. Well, maybe, but give it some scrutiny.
 
If there's a conflict of interest there, you should be really careful. Now, especially if you're going with a smaller vendor where you don't know much about them [chuckles], but, yay, this is my friend; he knows exactly what he's doing, give it a little scrutiny; often a good way to get a contractor. Maybe not such the best way when it's not...again, we're talking tech. The non-tech executive who brings in somebody and says, “Oh, yeah, we're going to go with them because they're my friend,” that's a red flag.
 
Another red flag: they have one person who talks to you, and they're great. It's easy to have one person who can talk well, and they may even be really good. They might be their only real good person [chuckles]. If you can get a team of people who can all speak confidently, that says something about their culture. Wow, I’ve got a group of people who know what they’re doing. In a really large organization, well, maybe again that’s easier to fake, sending their best, and they’ve got a lot of people who aren’t the best. But at least for a smaller vendor, [crosstalk 45:02].
 
WILL: Is it possible to say, like, “No, I want to talk to the person who's my account guy?” Is that a reasonable ask? Because, I mean, on one hand, like, I...how do I put it? Like, if I'm busy doing support, right? Like, I don't have time to do sales. Sales isn't my job. I'm busy supporting the customers I have, and I understand that. I understand that. But, like, if they don't have time to talk to me before I write the check, what are they doing after?
 
MIKE: [laughs]
 
WILL: Like, I understand that, like, you know, you don't want to burn up their entire time. But, like, I want to talk to the guy, not, like, your best guy. Don't give me the all-star. I just want to...I want to talk to the person that I'm going to be dealing with now.
 
And I also, like, maybe as an aside, you know, you guys have...you guys have bigger, like, all the software that I've bought, like, I buy, you know, off the shelf, you know, these are just SaaS, like, you know, because I'm not...I'm not big and bad and all that. Like, you can negotiate sort of quality of service in these big enterprise contracts, can't you? Where it's just, like, if I send you an email, I want an email back, you know, in this time frame [inaudible 46:10].
 
MIKE: Absolutely. You can set up all those quality of service items in the contract. And I think they're fairly typical. You know, I wish...you said, “Hey, can you go talk to that person?” I wish I'd done that several times. And maybe something that I'm going to ask next time, “Can I talk to my actual account representative? Not your best person you sent to me, but, you know, who's the person who's actually going to be working with us? Can I talk to them?” I think that is a fantastic question. And if they'll make it happen, it says something about the vendor as well.
 
I threw out a big list there. And I haven't gotten a lot more than, like, nods and mm-hmm.
 
DAVE: You're covering it well. Yep.
 
MIKE: [laughs]. Yeah, I thought it through. Anything you'd add to the list of red flags?
 
DAVE: I would add a thing on there. You mentioned, like, SLAs and, like, quality of service. The thing where it has hurt me recently is people saying, “Oh, I want this. I want this, I want this.” And then, they come in, and then here is the third party we're going to use. And then, you hand this out to all your employees. And then you never hear back on...you know, the only SLA report you get is from the vendor, not from your people. And so, yeah, you can run into some fun things there.
 
Joel Spolsky, the guy who originally...he ran FogBugz. I think Stack Overflow, I think, was his baby way back in the day. He talked about selling software in the 2000s, and he called it steak and stripper-based software sales, which is where you take somebody from the C-suite out to dinner. You buy them steak. You show them a good time, and you sell them the software. And then they go home, and they tell everyone at work, “This is what you get to use because it's great.” No, they had a great steak, and they had a fun after-dinner entertainment. They never even looked at the recs, right?
 
And you used to be able to make really good money selling software that way, and then come to find out that once it actually hits the ground, the service you're getting, yeah. Make sure you've got transparency into, like, how the QoS is working, how the SLA is being honored.
 
MIKE: That's an interesting one. And it says something about being willing to push back if you can. If you've got some capital to spend there, social capital use it to do real evaluation because there's a lot of things that slip through when you don't scrutinize. Go ahead.
 
KYLE: Another one that I've got is maturity. At least to me, it's a red flag. If it's a B1, if it's a beta, I'm sorry. I'll probably pass until you're a little bit more mature. I don't want to take that gamble.
 
MIKE: That goes back to the scale. If you're a startup and they have exactly what you need, nothing more, that might be the right choice if they're in beta. If you have gotten any scale and you actually need that thing to stay running, you should probably walk away.
 
WILL: I mean, a big piece of it, too, is what kind of software are you buying, right? If it's ops-type software, I don't know, man. Maybe not. Maybe not. You know, there's a lot of people where it's just, like, just write Oracle their check. It's fine, you know? [laughter] Maybe not that kind of a check. But, like, you know what I mean? Like, somebody with some gray in the beard, you know, like, there are things you can mess around with, and there's things you can't. Some software, it's just like, yeah, I want it. I want it battle-tested.
 
KYLE: Even there, you know, and I'm saying maturity within their product line, too, because there are features specifically, you know, I'll throw out AWS. I don't think that's bad to throw out. We have done evaluations from time to time, and it is generally better to wait for V2 [laughter]. We have run into that recently and have had to backtrack our implementations, and we're waiting for V2 of a product.
 
MIKE: That's interesting. You could think about AWS as a bunch of little companies [chuckles].
 
KYLE: Yeah, you really can.
 
MIKE: Or a bunch of little vendors, yeah, because they operate so independently.
 
KYLE: Yeah, if you want to see that, just go to the different services page for each of their products. It's designed by a different team, every single one of them [laughter].
 
WILL: I can't keep up, man. AWS is coming out with a new, like, something every week. I remember when AWS came out. I was an early adopter, right, because, like, it was brand new, and, like, we were just getting going. We had just moved off of the data center model. And, like, our team, our stack was, like, just brand fresh out of the oven, and we didn't have a lot of dough.
 
And so, we just got right on AWS, like, right off the jump, I mean, nearly at launch, and whoa, it's stunning. They’ve come out with so many things where I'm just like, I sort of start to question, like, who needs all this? This is crazy.
 
MIKE: The interesting thing is a lot of their products came from internal, at least originally, came from stuff they were doing internally.
 
WILL: Yeah, absolutely.
 
MIKE: If there's a niche [laughs], there's, you know, there will be product to fill it.
 
WILL: Yeah, absolutely. Well, anyway, a little bit of a tangent, you know. I liked AWS over the other maybe things because they did, like, less, you know, and now they're very much doing more.
 
KYLE: They are doing more, but I will give them the benefit of the doubt in this scenario. AWS is the more. If you want less, you do, what is it, AWS Lightsail? That's kind of your small individual one, you know.
 
MIKE: So, we’ve talked about some red flags, some positive things, right? They should be boring. They should be mature, have some longevity, used by other companies in your industry. They have multiple competent people who come and talk to you, you know, they'll let you talk to your rep, and they leave a good impression. There are some positive things. We’ve talked about a lot of red flags.
 
WILL: I have a red flag for you.
 
MIKE: Okay.
 
WILL: So, I won’t be too specific, although, you know, if you know the space at all, you'll probably know who I'm talking about. So, there was, early in my career, I worked on the corporate side of a multi-level marketing company, which don't get me started. I was young, and poor, and hungry, and I needed to eat.
 
DAVE: Needed the money.
 
WILL: Hey, I needed the money, you know, whatever. So, there was a vendor for their sort of, like, downline payment processing payout for their tree. Tree was upside down, but it was a tree. Not a different geometrical shape, but they were nightmares to work with. Absolutely horrible. They were expensive. They were slow. The SLA was more of a middle finger. It was pretty intense. It was pretty bad.
 
And the red flag...but it was also, right, it was also textbook case of, like, buy it; don't build it, right? Because it was this very specific, very niche financial product. You wanted it to be right. Like, I'm here to be the pharaoh on top of the pyramid, not, you know what I mean, this sort of, like, esoteric, arcane financial billing thing. Like, that's not my job. I'm here to do whatever it was that company did. You know, it didn't have anything to do with software.
 
But the red flag is, like, they were the sole player in this space. They did not have competitors, like, meaningful competitors, right? Because it was the 800-pound gorilla in this very niche space, and, like, there wasn't a negotiation, right, where we're, like, we're getting our enterprise contract. They were, like, this is it. That's what it is, right? Nobody was coming behind them. They ran things, and they set terms.
 
And so, like, you know, like, the old, like, Ma Bell monopoly. When you deal with people like that, you're going to get a...they're established. They're very big. You're going to get what you get, and you don't get upset. And I don't know if there was a number two, but I feel like the number two would have cared. They would have pretended to care at least a little, I think.
 
MIKE: [chuckles] Well, there's times when you may not actually have choice. But the small choice might be the right one, the disruption.
 
WILL: Maybe if we were a bigger account things would have been different. You know, I think fly-by-night, multi-level marketing, like, startups, are not [laughs] afforded the respect that you feel they might be deserved to. I know what I thought about the place, and I worked there. They were my only client. And I was just like [laughter], make the check out to cash.
 
MIKE: [laughs] One thing I wanted to touch on before we close is you've got the relationship. You've got the vendor. What do you do in your first year, I'll say? It may not be your first year. You've got a contract for a year, and you’ve got a contract for two years. How do you establish that in a way that makes sense going forward?
 
And I've got one thing that I wanted to touch on. Try to build your code. Try to build your integration to be vendor-agnostic. Build an integration service that you go through before it goes to the vendor. And this isn't always possible if they're running your infrastructure. And, Kyle, you know [laughs], sometimes the infrastructure can't be agnostic.
 
Well, that's a lot more...infrastructure is a lot easier to move now, right, to be multi-cloud than it was in times past. If you can make it vendor-independent, then you save yourself a lot of pain going through a year from now and changing the name of that vendor everywhere in your code where you're stripping it out and completely changing to call somebody else's API.
 
If you build a generic integration service that just abstracts that idea, you've got to change it in one place, or more or less. You know, you can minimize the damage. And maybe they're a great vendor, and they were a venture-funded startup that goes out of business. There's all kinds of reasons where maybe they were even a great partner at the time, but it's not going to work out in the long term. And having the ability to pivot is good. I think that building that in is worth it almost every time. What do you all think?
 
KYLE: Yeah, whenever we're evaluating new infrastructure components, that is something we take into consideration. I'm thinking specifically AWS. But, you know, we try not to run anything that only AWS provides, for instance, for that reason. You know, we're using Postgres. We're using OpenSearch, you know, stuff that the other cloud providers will also offer. That way, if we do need to pivot, those type of things will historically bite you, and those are large migrations.
 
Even monitoring tools, you try and make it a drop-in. So, kind of like you're saying there, Mike, you write a layer or something to where you can drop those in, and they're not hard integrated into your environments. That way, you can pivot.
 
MIKE: We do this audio only, but we record with video [chuckles]. I see nods all around the room [laughs]. All around. Well received. Any final words?
 
DAVE: I would say be careful to pay attention to what's important. If you listen to a recruiter's ad, they will tell you that we solve the problem of how hard it is to find the right people. If you're hiring people through a contracting agency, that shouldn't be their primary sell. I mean, it should be. They should absolutely be finding the people for you. But if the only thing they're doing for you is finding the people, are they managing the people? What work are you outsourcing? And especially if the only reason you're doing contract-to-hire through an agency is because you're bad at hiring or bad at recruiting, you're probably paying through the nose for not having somebody good at recruiting. Focus on what's important.
 
EDDY: I think at one point or another, all of us who have used a service or software have said to ourselves, man, I can build this product so much better [laughs]. And if you can, maybe that says more about the software you're using [laughs].
 
KYLE: It's also a chance to reflect, though: are you using the software correctly? Is your practice correct? Is something I would warn against there.
 
MIKE: Well, and it goes back to being willing to evaluate. If you don't do some evaluation and say, “Is this still the right vendor?” Then you may find yourself in a long-term bad relationship, and it's worth it to do some introspection. There's no shame in reevaluating that choice because times change, and maybe it was a bad choice to begin with, or maybe it's an even better choice, right? There's cost to moving. And if it's okay, that's good enough, right? But be willing to reevaluate. It's not quite presence of mind here, right? Have the business willingness to revisit your choices.
 
Great discussion. One of our --
 
DAVE: This was good.
 
MIKE: There was a lot of stuff to cover here, and we covered a lot of it. Hope that you get something from this and can make some better and better decisions when you're picking your next vendor. Until next time on the Acima Development Podcast.