Ep. #636 - Choosing the Right Technology

Matt DeCoursey 0:00
And we’re back. Back for another episode of Startup Hustle, Matt DeCoursey, here, with Matt Watson. Hi, Matt.

Matt Watson 0:05
Hey, how’s it going?

Matt DeCoursey 0:07
I’m doing pretty good. You know, I’m having a tough time making a decision. And I just don’t know, you know, there’s technology, it’s everywhere. And I’ve got to pick a tech stack to build this amazing software platform, but I just don’t even know where to start. So I thought I would hit you up and you know, maybe get some of your input, you know, a couple of things about software, right?

Matt Watson 0:28
Absolutely. And there’s a lot of choices to make, and some are good, some are bad, and some are terrible.

Matt DeCoursey 0:34
You know, one, a good choice you can make is letting us know, at FullScale.io If you have technology and software needs, and today’s episode of Startup Hustle is, in fact, brought to you by FullScale.io, where we can help you build a software team quickly and affordably. So, Matt, before we you know, before we get into this, and I wasn’t you know, I was joking in the regards, I’m not starting a new software company anytime soon. But there’s a gazillion programming languages and more coming out all the time. And, you know, some of these, I think that my experience, both as a founder and also working at, as the CEO and co founder with you of Full Scale has led me to believe that people choose their tech stacks, often, for all the wrong reasons. And maybe we can talk about that a little bit. You’re nodding your head, and I know those listening can’t see Watson looking like a bobblehead right now. But he is he does a little bit yeah, boring, boring, boring. And you know, the thing is, is so now? I mean, do you see the same thing?

Matt Watson 1:43
Well, I think you have to two major problems that happen. Usually when you start a startup, regards to this, right? Usually, people will will want to play with some new technology, because they can’t at work. And they’re like, Well, I’m going to start this new company with a friend. And like, if we’re going to do it, why don’t we just also learn to program in closure or Haskell or some other new hipster programming language, because it’ll be fun. And I’ve always wanted to do it. And which sounds great. But if it turns into a real business, who you’re going to hire to do that, because nobody else knows how to write code, and Haskell or closure, and all these other weird programming languages, and quickly becomes a real problem with how do you scale. And it’s a challenge. And then so the other thing that happens is, people pick things they want on their resume. That’s a problem, too. They’re like, Well, I’ve never done programming with view or react before. I know, it’s really popular. So I’m going to use that. And then you spend like weeks and months trying to figure out just how to get the shit to work, because you just don’t have experience with it. Where odds are, if you would have just picked whatever you knew, and just used it, you would get a lot farther, a lot faster. But people tend to use new projects. For that those two issues, like they want to do some new, cool hipster thing, or they want to put something on their resume.

Matt DeCoursey 3:11
You have run into both of those. And then I have a third one that’s really prevalent, especially when talking to the non tech founder. So the when we say a non tech founder, meaning like a founder that isn’t isn’t doesn’t write code, and they now Yeah, me. Yeah, that’s a good example. And you know, that’s you really do that’s about a 5050 mix, you know, like, about half of founders are, are technical and some aren’t now, I mean, I’m, I’m somewhat technical, I just didn’t write code. You know, I mean, 1012 years later, I mean, I’ve learned a whole lot. But one of the things that I that I’ve learned when talking to people is that, especially like I said, with the non tech founders, they often go find the first person that they know, that they believe is technical. And then they get advice from that person, which usually leads to one of the two things, like you had mentioned that person’s like, well, you know, I mean, I’m really an expert in PHP, but you know, what’s really on the on the upswing go, right, you know, and then you know, and so then they build a platform around it, and they’re like, Oh, this is the new thing, or they just don’t know, and then they get X amount into it. And they run into the same issues, like you mentioned. And this is this is why I run into this so much at Full Scale, because people reach out and they’re like, hey, I need this kind of developer and I’m going, Man, if I can’t, if I could find you, one, I don’t think I could, in very good faith, tell you that I could continue to support employing people like that, or I don’t want to hire them because if you churn or leave as a client or fail in some regards, now I still employ this person and I’m struggling trying to find one project for one specific person in a company where we have 220 employees. So you know, there’s a lot to be said with that. And I think a lot of times too, it’s just like, like I said, it’s just there’s just not too much thought consideration now we’re gonna do our best to try to demystify some of that. But I mean, look, there’s I mean that there’s, there’s the top 25 coding languages lists out there, which means you’ve got at least 25 choices. And there’s even more. So, I mean, when it comes to just like, overall, like choosing a platform in general, I mean, I think the first thing you’re even considering is like, where is this going to operate? Like meaning? Like, is it? Are you building a mobile app? Are you building a web app? And that what’s the difference between the two?

Matt Watson 5:33
Well, and I’d say you’ve got three, you’ve got web web applications that you’re going to access in a web browser, right? So you’re gonna Google Chrome or whatever, and go to some website and access it. You’ve got mobile apps. And then the third choice would be actually a desktop application, you can have desktop applications do. So all three of those, and it depends on the problem you’re trying to solve. This day and age, if it’s something that’s very consumer oriented, mobile is the place to be. So many people have mobile and do everything on mobile. So mobile is really important. But if it’s more a b2b kind of app, enterprise application, then probably web based is good. And then sometimes things are desktops if they’re utility kind of things or, like at stack fi. Now, Netro, we have a desktop application. So those exist, too. So you got all three. And you can actually create applications with the web based technology, like no Jas or dotnet, and then actually make it usable in all three. So you can use JavaScript frameworks, like React Native and react and stuff like that, and, or Angular and reuse it, or dotnet has some ways to do some of these things do so. Yeah. And we,

Matt DeCoursey 6:49
by the way, Brett brings up a fourth mistake that we should talk about along the way, too, is like not making things cross compatible.

Matt Watson 7:00
Yeah, and so you. So it’s both right, I mean, you can kill yourself by trying to be so cross compatible, you’re like, well, we need to make it work perfectly for Android and Apple, and the web, where if you were to just focused on say, Apple, like, say, take some a famous like clubhouse, or some of these apps that come out, and they just focus on Apple or whatever they get, they get a big fan base, they get some traction, and then eventually they they spread to the other platforms, right? Where if you’re trying to perfect the experience on all the platforms, you may never get launched, because you’re just spending forever trying to make it work. And all three, or you don’t have the budget to make it work for all three, right? So sometimes you got to pick one and make it and just make it work that you’re absolutely right, longterm, you got to support all of them, or you’re, you know, only going to get a percentage of the market share, because you can’t support the rest of the client base.

Matt DeCoursey 7:51
Yeah, and I think we should delve, spend another minute talking about the cross compatible nature of things. Cuz, you know, for for old guys like us, you know, 1012 years ago, I remember when, oh, well, we only have an app for Apple, you know, and then, like you mentioned, it’s like, so then they would have to develop a separate product, which is usually expensive. Yeah, which is literally like a second company, a second project, the second everything. So as technology advanced, and the world continues to solve problems, there are cross compatible platforms that will, especially in the mobile app world, and right now, the one I hear the most is React Native, which is, you know, code profilers that will, that’ll help you basically, I don’t want to say they spit out a finished version of either, but they come pretty close. And then you have a few things to do past that. So you’re you’re maintaining one codebase. And I’ll let you take the mic and talk about why that matters.

Matt Watson 8:53
Yeah, so if you’re writing an application in Android, and you’re basically writing it in Java, then if you go write an app in for iOS, on the Apple side, you’re writing it in Swift, they’re two completely different programming languages with their own, you know, weird set of problems and things to know about as a developer. So you really are writing it twice. And as you said, you can use JavaScript. And there’s there’s lots of different JavaScript frameworks that will do that React Native is one of them. But basically, they they use JavaScript. So what you’re seeing is all basically like a web browser. And it’s just rendering with JavaScript and HTML and CSS. So it can kind of be the same either way. And then they have some, basically like a shim of API’s that will let you if you need to connect to say the camera or location services, or some of those things, that are more assets on the phone, that’ll bridge that gap. And there’s actually a framework called PhoneGap for that. So that’s a great option and then you can write it once. The the issue still runs into if you’re trying to make the user experience look exact Perfect for iOS exactly perfect for Android. So it looks and feels like an Android app and looks and feels like an iOS app, there’s still some complexity there, if you want to actually make those look really, truly native on both, where if you just want to make one good user experience that works on both, that’s not probably too hard. But if you want to make the calendar and the dropdowns, and all this stuff look exactly the same as the operating system, it’s still a little more work. And then the third app option is Microsoft Xamarin is a good option. And Full Scale, we’ve had a lot of clients that we’ve done work for for Xamarin, then you write all the code and dotnet. And it does do some magic, and it spits it out and compiles for both, and you can deploy both to both app stores. So those are both great options. And like I said, as a developer, and as an owner, like the last thing I’m going to do is have to double my budget to do this crap twice. So either way, I’m a huge fan.

Matt DeCoursey 10:57
Yeah, so that, you know, working from one code base, like Matt said, is one set of things to fix and as your platform over time, it just gets layered upon layer upon layer. And the more you know, the more things that you’re connecting, integrating, and in doing all that if now you have to double everything you do. Yeah, that’s it’s a lot of work, man. It’s and it’s also you’re also doubling your opportunity to mess it up in many regards, but, but you really require a lot. And you know, one of the things that I really do run into, because I talked to so many people, like we’re pretty picky about the clients that we work with, because we want to make sure we can, we can help them. But I really have over the last three years talk to so many people that have made it all there, they’re, you know, we did this with Giga buck at one point. And this was, you know, so many years ago that just the way that the code was written wasn’t conducive for growing it or expanding it. And the one of the technically a co founder with us, there’s said to me one day, he’s like, Hey, Matt, you know, you keep talking about wanting to make this a platform. But what we’re doing right now is certainly not that. And if you want it to do this, this, this, and this, we’re going to need to change our approach, and I had to spend a lot of money, I did spend a lot of money to redo it. And that’s the example of that’s technical debt. And you know, that’s what we’re trying to avoid. And that’s what we should talk about for a second is your, when choosing a technology platform, you need to know what technical debt is, and then try to avoid it, or at least be aware of it and understand it as you accept it. Well, it might not be the right word as you tolerate it.

Matt Watson 12:42
So the biggest key concept there that we want to make sure we hit on has to do with the ability to scale and scale out. And by when I say scale out and scale, I mean go from having, you know, five users to 5000 users to 50,000 to 500,000 to 5 million, right. But the key to that also is what I would call multi tenancy. And so especially if you’re selling like an enterprise software, like b2b product, you know, every customer you sign up, potentially, you don’t want to set up like all new servers for them and all that kind of stuff, right? Because it’s very expensive. So you want to build a product that does what we would call multi tenant. So they can all go to the same app, like Giga book is like this, right? Like people can log into Giga book. And we, you know, we 1000s of clients, and they all log into one place, right? It’s not every one of them has their own server and their own database, all that stuff. Because that’s, that’s very cost intensive. But to scale out, at some point in time, if all of Gigabit is even on one server, it can only handle so much traffic, right? You can only scale it so much to be able to scale out you got to be able to take like the database and things like that and have more than one database. So you can horizontally scale across multiple databases, more than one Redis Cache more than one Q one more than one of everything. What are all the things you are able to scale out. And the one of the other big problems that people run into, though, when they first start up, is they try and solve all of those problems the first day, like you don’t have one user and you’re trying to solve problems for when you have a million. And so that that’s a double edged sword you got to be really careful about and I think the key is as you build things, you make smart choices to say, look, at some point in the future, if we need more than one of these things we can scale out. But today we don’t need to. Right. I think that’s the key decision. We had to do that stack Fie, right, we knew we were going to scale out and eventually we had like 2000 databases. And so as we wrote the code, we took that into account and we could scale out kind of infinitely. But what you don’t want to do is spend too much time trying to perfect all that stuff that you never even launch a product. You don’t want to spend too much time.

Matt DeCoursey 14:53
Yeah, you often hear some we sometimes you have to cross the bridge when you get to it. At the same time if it’s lettered with junk garbage and landmines that can be a little bit more challenging. Yes,

Matt Watson 15:05
it’s one of the technical debt, right? It’s part of the technical debt thing you mentioned earlier were like, well, we didn’t design this part of the system to scale. Or we know this as a performance issue or, or we use some third, like, like a giga book, we’d use some third party integrations, you’re like, No, this thing sort of works. But it’s sort of a piece of crap. But it functions. And when you start out, sometimes you use some of those things, right? And then you look further down the road. And that kind of gets added to the list of what we would call technical debt, you’re like, well, at some point in time, we got to change this thing, we got to fix this thing, we got to improve it. And the scary thing is you don’t want to spend too much time on all the technical debt and not building new things as well, you always have to juggle that. But yeah, there you you incur a certain amount of technical debt as you create software. And one of the things you have to do is manage the debt.

Matt DeCoursey 15:51
Yeah, and in that particular example, with Giga book as it kind of broadened, and I mentioned things being in layers, and you have this feature, this stuff, and all these things connect is you can run into a situation where you go to fix one thing and accidentally break three more. And that’s where that’s where that’s always the challenge. And I think the one thing I’ve learned in the last 12 years is that there’s no such thing as a business without problems. And there’s no such thing as software without bugs. So if you’re going to, if you if you’re going to proceed into the world of building software, know those two things, because it’s never going to be perfect, and it’s never going to be done. And that’s actually what I want to talk about next, Matt? Because, for me, when I get someone on the phone that wants to build something and talk about it at Full Scale, and they’re like when it’s done, and I’m sitting there thinking, Man, this person doesn’t have a clue. Just meaning like what and so Matt, why a sought, why is your software never truly done, like so. There’s so so many reasons, but I’m interested to hear what your top ones

Matt Watson 16:57
are. So one of my favorite quotes is from the movie social network from Mark Zuckerberg. And I don’t know if Mark Zuckerberg said this in real life, I don’t know. But he said, A software’s like fashion, there is no final version. Right. And it’s true, like software is always changing. And, you know, even if it has to do with security patches, and updates and framework updates, and all that stuff, there’s always kind of never ending changes to it. Now, yes, there are some software that you get it to its completion, and it never changes. And in the United States, we’ve got a whole lot of nuclear silos actually here in the Midwest, that can fire nuclear weapons, that the software hasn’t been updated in 40 years. And you know why? They don’t have to worry about security vulnerabilities, and Linux or any of that bullshit, because they’re using proprietary stuff from 50 years ago, they actually are probably very happy with that it’s gonna not hackable because nobody has any clue what it is. So, I mean, there is software that gets to an end of life, and you just kind of maintain it. And it just operates and it works. But most software that’s created also doesn’t have a lifespan of more than three to five years.

Matt DeCoursey 18:09
Yeah, so I’ll give you another kind of layman’s example of that. So if you’re going to build software, you’re choosing your your tech stack, and so much of this stuff, you know, you’re looking at AWS, Amazon Web Services, or wherever your server is, they’re gonna make changes and updates, like, for example, PHP might go from version seven to eight, or something like these little changes and little security patches, and all this stuff like inside your server, there’s just a million bells, whistles, switches, settings that you don’t even realize exists. So what happens is, Amazon goes and they update all their stuff. And unbeknownst to you, it breaks something. And it until well, until you figure it out. It’s broken. And another thing too, is on the browser side. So you’ve got your front end, and you have your back end. So good luck, Google doesn’t email you. Or they do that it’s not, it’s usually not very straightforward that Google will make changes to Chrome, that might break something in your server. And actually, Matt, you built a whole company, stack of phi, which is now part of net trio to help people figure out where their shit was broken. Like it was that big of an issue that you built, and then exited a company that specialized in that. So you’re the expert on that. Like, why does that stuff happens every day all day, right?

Matt Watson 19:37
Well, I mean, software will always say like, if software breaks one and 1000 times it works perfectly. Because it’s true. If it works like 99.9% of the time, it works great. Where if you think about like an airplane, if one of the 1000 Airplanes fell out of the sky be a big problem. But for software, it’s it’s okay. One of the 1,000th time It is okay. And in a lot of it’s because of random issues, right? It’s like, oh, the it couldn’t, it had a timeout connecting across the internet for whatever reason to connect to some other thing, or the database was doing backup at that exact moment in time. And it was running really slow. Like, it can be 1000 different reasons. And it’s just the nature of technology. And, and as a technologist, that’s why we build in things like high availability, and retry logic, and all those things to try and work through that stuff. But it’s just part of what happens is things fail, things break. And you mentioned earlier, security, security is a nightmare, by the way, because you take a tree for an example, you know, there’s, we have PHP five, and then six, and I think it’s skipped to eight, well, at some point in time, they don’t even support five or six anymore. And over time, we find all these security vulnerabilities in it, right? And like, Oh, if you’re still using 5.2, it’s got all these known security vulnerabilities. But going from version five to eight, could be a shit ton of work. It may not be like, Oh, I just install some little patch on my server. No, it could mean your developers have to rewrite a bunch of code, depending on the programming language like this happen happens with like Ruby, it seems like whenever Ruby goes from version one to two to three, like this giant ordeal, it’s not just some little quick server patch. So a lot of security related stuff causes problems, and you have to keep up to date with.

Matt DeCoursey 21:23
Yeah, and then you know, and then back to just the simplicity of it, you know, so with that, if you’re not technical found are capable of fixing that stuff yourself, you’re going to need to have people that are prepared to do it, I think often the inexperienced, you know, like they think that you’re soft, that their software will be done. And then in the event that it breaks that they can just call any old programmer to just pop the hood open and fix it up. And that’s not it with sophisticated, complex software platforms. It’s never quite that easy. I mean, it’s so I’ll give you an example. Matt, when you hire someone to work on, or on the platform you have now How long do you expect it will take them to get quote up to speed on how it works. I

Matt Watson 22:13
mean, I mean, our system is really large, right? We’ve got 50 to 100 different applications. And nobody, including myself is ever going to be an expert on all of them. It’s just impossible. But usually, when somebody comes in, I would say it takes them a couple of weeks to kind of get up to speed on whatever the first thing is they’re going to work on. But it probably takes them several weeks to kind of become a master or expert at what does this thing do and understanding. Like you said earlier, if I mess with this thing, it breaks all these other things downstream. And that’s the biggest problem with software development is like, Well, I’m just going to change this one little thing, you don’t realize that like 10, other things somewhere, also use that same point, same data, or connect to that same server and do some transactions or whatever. So you just broke 10 Things like, and it’s just part of what we do.

Matt DeCoursey 23:01
Well, and that’s what you know, and I was using Giga book as an example. That’s what got progressively more complex, because now you’re collecting the payment, okay? Well, the payment needs to show on an invoice which needs to, you know, then show on an email, which needs to then show on a calendar and like all these different things, and that’s where, you know, so if your expectation is that you’re going to build some software, and then if or when it breaks, you’re just going to call your local dev shop and be like, hey, I need something fixed. Well, I’m not gonna just get in there, and just like, it’s not well, I’m gonna get an oil change later today. That’s pretty straightforward. But that software, in most cases,

Matt Watson 23:41
into your example of giga book, then you’ve got Well, only if it’s during working hours, and only if the group schedule isn’t full, and it’ll allow more people. And then we have to take payment via stripe or Pay Pal. And, you know, just all these different moving pieces, what seems like a simple thing, all of a sudden becomes this rat’s nest of requirements, and you’re the developer comes in, you’re like, Okay, so we accept this, but only if this thing and only if this thing and integrates over here and then integrates over here, and if that part doesn’t work, then I do this instead of that, and it’s a ball rubber bands.

Matt DeCoursey 24:16
So building software as hard as what we’re trying to say,

Matt Watson 24:19
this gets complicated.

Matt DeCoursey 24:22
If you want help building a software development team that is vetted, and experienced and communicative, let us know go to FullScale.io also the sponsor of today’s episode and the company that Matt and I own together So Matt, you know when so, you know, here we are, we’re in part 2452 of our How to Start a tech series. We’ve gone down a bunch of different stuff. I mean, in the end, like I mean, I think the the million dollar question here is I mean, how do you choose a tech stack like what’s like and I think this is on so many like, a kind assemble What an impossible question to answer. Because it we don’t know what you’re trying to build and what you want to build, like, are some programming languages just inherently better than others when it comes to doing certain things? And then they suck at other things?

Matt Watson 25:17
Yeah, absolutely. So there are some programming languages are definitely better for different use cases, right? Some people love scripting languages. So Python, no, Jas and Ruby, some people love them, because you can quickly just make changes. And you can even log right into the server and make changes. And as soon as you save the change, it’s live. Problem is it doesn’t compile. So what I mean by compile is, as an application gets bigger, it can have a million lines of code. You can go in and change one line of code, you have no idea if that one line of code works with the other million, right? Where if you’re, if your code compiles, like dotnet, and Java and some other languages, you have to build it, you have to go through a build process, and it would kick back and say, Nope, that you know, that line of code isn’t you know, it’s missing a semicolon or whatever it is, right? Where would the scripting language, you can just throw that shit out there. And if you’re missing a semicolon, it doesn’t care, it’s just gonna blow up to your users, and you have no idea. And so honestly, I’m not a fan of the scripting languages because of that. So that’s just my take. I’m an old dotnet developer at this point. But there are six, there are six mainstream programming languages. So let’s go through real fast, there’s dotnet, Java, PHP, okay. dotnet and Java are typically used in more enterprise environments in bigger companies. PHP has been around for a long time, it does a lot of things. People love or hate it. It’s gotten more and more modernized over the years, something like Facebook uses PHP, although they had, they’ve had to do a lot of shit to it to make it performance scale. And then you got the scripting languages I mentioned earlier, Python, Ruby, and Node js. To me, Ruby seems to be slowly dying a slow death. Python seems to be the programming language of choice these days for entry level people. And no, Jas is just JavaScript, of course. So it’s really popular because you got to know JavaScript for the client side. So I would definitely recommend Python or Node js, if you’ve got a simple application you’re trying to throw together, if you’ve got a bigger application, I definitely recommend dotnet or Java, I think dotnet tends to be a little easier to work with and more modern, and some people don’t like that. Oracle controls Java and all that crap now. But Microsoft’s usually on the forefront of things with dotnet, I’ve always been a big fan of, of dotnet. And I haven’t found a problem yet, but I couldn’t solve the dotnet. So at Full Scale, we do a shitload of dotnet development, but we do development and other things do so no matter what it is, we can

Matt DeCoursey 27:51
do all of those, we have all of those and, you know, like, like, there’s different, there really is a different approach now, according to GitHub, and we’ll talk about what that even is here in a second, because that’s a beautiful thing that didn’t exist a decade ago, or roughly. So, you know, Python is, in fact, according to GitHub, the fastest growing language because it’s, it’s, it’s pretty easy to learn on the basic side. And then there’s a huge, a huge push with data and data science stuff. And Python is operates very well with that. So there are one of the things that I wanted to add on to your comments which were great, by the way is, there are certain languages that do things in a lighter way, meaning like they don’t, they don’t require a ton of computing capacity. So I’ll give you an example. Our friend, Davey on Ross over at shot tracker, it’s basketball technology, and they have a little chip that’s in the inside of basketball. And that thing is it’s powered. And it there’s, there’s a lot to it, and they need to run a programming language inside that, that is as lightweight as possible, meaning it doesn’t wear the battery out, it doesn’t require and in some cases, like you know, so in that case, that’s C Plus Plus, yep. And that and it runs lighter than Python, they can both do the same thing. On many days, but one requires more power and or it’s a little faster, it’s a little slower. So and these things matter when it comes to a lot of different things. So like computer vision, is all the rage for a lot of things. That’s what makes it basically creates a neural network that allows a computer to operate in the same way as an eyeball. And you’re thinking, well, didn’t they do that anyway? No, because computers looked at things in a two dimensional kind of way. So in order to look at it in a 3d way, they had to had to have depth and shading and all different kinds of stuff. Well, that’s a whole lot. It’s a whole lot to compute. So In some cases, you know, in order to run that, that Platform C Plus Plus was a great way to do it, it did it a lightweight Now, one thing that a lot of people don’t know is C++ was traditionally in many places, kind of like embedded software like inside hardware kind of stuff. So the C++ developer has gone from largely in our world largely being like, very limited software developer to now they’re now they’re rapidly becoming in demand, because open the provision open CV, yeah. And so you see a lot of these things change and shift. And then there’s a lot of like, a lot of what you’ll also hear while you’re choosing the tech stack, and you know, Matt, actually, this is probably be good for us to visit, because we’ve given this advice in the past, like, comparing a swift your need, you need a Swiss army knife, or do you need a sword? Yeah, because they’re both different. And I, I’ve kind of built this example, over the years, if you’re a really early stage company, you’re best to have a well, a flexible tech stack, and also developer or developers that can do a wide variety of things. Because you’re gonna have a lot of different problems, a lot of different things to solve, where the steps the Swiss Army knife will, a sword is the person that’s a true specialist they’re like, and we’ve run into this, like someone that’s, I’ve been doing this for 15 years, this is what I do, this is what I’m an expert at, boom, and they don’t want to just say you want to do front end, or they want to do back end, they rarely want to do both. That is something I think that you need to take into consideration when you choose the technology that you’re going to build your platform around. Now, in this swiss army knife example, you don’t want to be at the frontline of battle, holding the corkscrew or the leather punch out, you know, in fighting, you want the sword up there. But when you get back to camp, you don’t want to be open trying to open your can of beans with a sword, you know, so that the decision of what technology you use, I think is often created by who’s going to who’s going to help you build it now with that I really want you to take heed to what I’m about to say is do not structure your entire technology platform around to be dependent on one person. Like if this one person is not at your company, no, it’s going to be a massive mystery how your tech platform works on many days. And that’s what we refer to as creating a tiny general, you don’t want to give someone too much power and too much stuff. And when I say power, I don’t mean that the wrong way, like retaining people and talent is challenging. And, and, you know, the Wall Street Journal keeps referring to the great resignation, meaning like, the world, the deployment landscape is going to really change over this next year and a half, because some people got a taste of working remote, and they don’t want to come back to the office. So you see where some of this stuff is gonna go. And you know, it’s me now how did we basically became we didn’t basically we did become business partners in one business and realize that the challenge for finding people to work on that’s chosen tech stack we had was not only a problem that we had, but it was a problem that everybody had. And you know that and so you know, right now there’s over 300,000 Open it jobs in the US. And you know, so you got to think about who you’re going to have and who you’re going to have to work on it and what they’re going to be good at because different regions and different parts of the world like our offices in the Philippines, were inherently everyone 10 years ago seemed to be a PHP developer. Why? Because all the things you mentioned Microsoft, Oracle, whatever those required purchasing of licenses, yeah. Which was a barrier to entry for some of these developers to start that like, you know, that was a bigger expense 10 years ago for them. So like when it comes to the people side of choosing your your tech stack, what what kind of comments or input you have there.

Matt Watson 34:08
What so I want to follow up on one thing you mentioned earlier about C++, because C++ is another super common programming language. But you never want to use it unless you have to, or performance really matters because it is a nightmare to create software in it is infinitely more difficult because you have to manage all the memory and all this stuff. So it’s really easy to create lots of problems, where the modern programming languages make all of it dramatically easier. From a productivity perspective. I’ve written a lot of code in C++. I never want to do it again. I mean, it’s a nightmare. But to do what you just said, hiring people is the biggest problem, right? We know there’s not enough people. And we also know there’s a huge skills gap. There’s one of the fundamental things that annoys me is people think that all of our kids should learn to code and they’re all going to become programmers one day, which isn’t true, there’s only a fraction of a percentage of people probably that have the right personality, the right level of intelligence, the right skill sets and all that to actually be software developers, right? Just as only a certain percentage would be a lawyer or a doctor or name some other thing, right? I’m not going to be an Olympic level athlete just because I want to be either, you have to have the right DNA and skill set and personality. And there’s, there’s just only so many people. Now there are some people that could do it that don’t they choose to follow other careers. And if we can get those people in software, that’s great. But there’s a huge gap in in skills. And what you mentioned earlier about technology, programming languages, and geography is absolutely true. Like in Kansas City here. dotnet is super popular, and so is Java. But it’s probably because it’s come out of you know, larger enterprises, larger businesses here in town, that have trained those people giving them jobs, and they leave and go somewhere else, or start their own company. And they continue to use those languages, just like me, I started out in dotnet, and I just everything I’ve done since then, has been dotnet, where you go to Silicon Valley, where there’s startups that might be more, you know, more likely to use other languages and do other things. So different parts of the world, you absolutely see different skill sets. And I think over time, that’s becoming more normalized. But you know, even Matt, like this, about 10 years ago, you were trying to hire a PHP developer, right? And there was like, literally zero in Kansas City, you couldn’t find one.

Matt DeCoursey 36:31
That’s, well, that’s how I ended up hiring my first employee in the Philippines, because, you know, we were trying to build, basically build a website that that generated and built itself. And that required certain functions within a server that just weren’t inherently that easy to build in dotnet. Now, I lived in Indianapolis at the time, and I had hired a dotnet developer who just basically ran into a brick wall. And he said that I don’t, either this isn’t possible, or it’s beyond my skill set. And he said, Well, you need a you’re gonna need a PHP developer. I said, Okay, well, let’s go find one. He said, Okay, good luck. And I said, What do you mean? He said, Well, they don’t really have him here. And I said, What do you mean, they don’t have him here? He said, well, that then basically what Matt just said, everyone here grew up doing this. And so I started doing some research. And I found that at the time that the majority of people that, you know, this is over 10 years ago, the majority of PHP developers existed in either India or the Philippines. And because those had, quote, open source licenses, meaning they didn’t have to buy Microsoft license, or whatever. So I said, shit. Alright, so that’s what I had to figure out. And I had to hire someone from overseas, because I really couldn’t find anybody that had any technical proficiency with that. That said, the guy that I ended up hiring actually solved the problem during his job interview, which was was pretty impressive. But it also made me truly understand what it’s like to have a level of expertise and understanding. And so Okay, so one last thing, and let’s just kind of run through a couple things here. So, you know, there’s, I think, in the end, my, if you’re choosing a tech stack, I think, the best advice that I give people well, so I run into people that will ask a number of different things. So certain types of developers are less expensive as well, yeah, because there’s more of them. It’s a market economy. And so, you know,

Matt Watson 38:35
that’s the key to all this, right? If you’re going to start a company, whatever technology stack you build on, you want to pick one where there’s talent available to do the work. If you pick something that’s really obscure, it’s really difficult to hire people.

Matt DeCoursey 38:48
Yep. And they’re just because no one’s doing it or, and that’s another thing too. And we talked about this a lot of Full Scale, because we build our own system to help find our existing client help our existing clients and future clients find the resources that they need. And so with that, we have about 250 different tags that we can add to a developer, that’s how many different keywords and things could potentially be attached. And then you have to combine them sometimes. So if you have a platform, that’s another thing, too, is if you stack two boutique, technologies on top of each other, God forbid, you’re gonna, you’re gonna probably punch yourself,

Matt Watson 39:30
and people don’t want to work for you. If you’re not using newer technology, right? If you’re using some old technology, people also don’t want to come work for you because they want to keep up on trends, right? They’re thinking about their resume, what’s gonna look on their resume. And so you’re like, Well, we’re looking to hire COBOL programmers or Perl developers or whatever they’re like, I didn’t want to do that because I’m trying to get to the newer stuff, right? And, again, if you’re if you’re not doing if you’re not keeping up with kind of the latest technology, it’s just really hard to hire people. because people want to do the latest technology, because they don’t want to get left behind in their career either.

Matt DeCoursey 40:04
So, three quick things that we can breeze through servers.

Matt Watson 40:12
Well, I think the most important thing here and

Matt DeCoursey 40:14
you’re a bit of an expert on this man, I think you’ve spent millions and millions upon millions, you’ve probably spent over $10 million on servers in your lifetime, haven’t you?

Matt Watson 40:23
I don’t know if I’ve spent that much. But I definitely spent several million, the club I’m getting, I’m getting there. But I think the most important thing here is I highly recommend using Azure or AWS, or Google Cloud or any of those things. Don’t Don’t try and host this shit yourself. Unless, unless you don’t really care about performance and scalability and stuff like that. If you care about high availability, and scale and all those things, and just keeping your life, it’s been so much time jackin wish it instead of just Yeah, might cost a little more on Azure, or AWS, or whatever. But it’s worth it. Because you’ve saved so much time, I would definitely recommend that. And the big thing is containers, everything these days is going to containers. And containers make it easy to deploy your app, it doesn’t matter if it’s on AWS or Azure, or wherever it is, and scale it and move hosting and all that. So containers are a big thing. But the other thing, the other trap here is spending too much time again, on performance and scale, you’re like, Well, I’ve always wanted to learn how to use Kubernetes. So I’m going to set up a seven node Kubernetes cluster and spend the next six weeks becoming an expert on Kubernetes. Screw all that shit. Just login to AWS use fargate, click Deploy done. Save yourself some time again, don’t chase all this complicated shit, because you won’t learn how to do it. Focus on getting work done.

Matt DeCoursey 41:44
Yeah, I think and back to my initial advice is don’t just choose the tech stack. Because the one person you know, that knows anything about it said use this, that this is a decision. This is like dating and marriage like, because once you get into this if you have to change, and that’s another thing I run into a lot, when I do consultation calls for Full Scale services as people are sitting there, and I’m talking to them, and they’re going, Okay, I you know, they’re like, I’ve got to make this transition from something to something. And he said, well, first off, why are you wanting to do that, because it’s impossible for us to find people to work on it. Well, like deprecated technology. And yeah, just the same as all the things we’ve mentioned.

Matt Watson 42:28
And there’s another example of this, I can’t remember who it was that we were working with a client. And it might have been that a Sports Group stuff your local, I won’t name them, but I think they, they were using some kind of weird database. And their developer thought it’d be cool. So use this weird database, and they had all these weird problems with it, and wouldn’t do this and wouldn’t do that, or whatever. And now it was going to take like weeks or months to like, go change all their code base to move from that weird ass database to just a normal, like Postgres or MySQL, or whatever. And again, that’s the thing, developers think I want to use this new cool technology, and they go spend all this time on this new cool technology that then nobody knows how to use, and it doesn’t work, they just use tried and true shit and make it work people. That’s awesome. And sometimes

Matt DeCoursey 43:14
that stuff doesn’t make it, it just doesn’t become mainstream, you know, it’s like, and then it just kind of it doesn’t, it doesn’t evolve, it doesn’t have support updates, all of that the way that other stuff did. So, yeah, I wanted to throw in one other thing. So if you’re a nontechnical founder, and you’re just trying to get things set up, like, there’s also like managed hosting services that will help you with your server, they’re going to now they’re going to be even more expensive. But I gotta say that like early in the days of giga book and stuff like that, when I didn’t have like, it didn’t have the client. Well, we had to improve a lot of things. You know, we use Rackspace. And over time, that ended up being a little too expensive, because we figured it out. But for years, we were in there. And man, there were definitely times like, the thing with a company like Rackspace is it’s a server, and it’s and it’s someone to answer the phone and help you fix your problem like now. And that’s one of the things that some of these, some of the server platforms that are pretty easy to get in there is like, and then you’re like, oh, shit, now I needed like admin and a person that knows how to deal with that. So there were a couple of times when when the Manage hosting service, so I remember I built the first website, I didn’t know any better. So it’s 10 years ago. It’s like in a shared GoDaddy server, or something that got hacked. And it happened like three times in like two weeks. And it was my mother of all people, one of the least technical people I’ve ever known. And I was making the debate about I was like, Yeah, I want to try this other thing, but it’s so more expensive and she was like, Well, what’s more expensive paying for that or having your business not even be able to open its door? Yeah. And I was like, You’re right and that and that You know, that can, that is a nice little stop gap. The scalability of it is a little questionable from a cost perspective over time, but once again, you know, get to those bridges before you, you worry about crossing them. If that bridge is 10 miles down the road, you got a bunch of shit to worry about before you get there, like maybe getting your MVP out. Now, it’s kind of funny. You know, here on another episode of Startup Hustle that was brought to you by FullScale.io, helping you build a software team quickly and affordably. We were worried we wouldn’t have enough to talk about, we had a lot to talk about. And I feel like we could keep going and going and going on this one. In the end. I think it’s just a quick, anything you’d like to summarize on the layout?

Matt Watson 45:42
Yeah, I would say when you’re trying to build a new software product, use the tools, you know, use the common tools, I mean, use common frameworks, popular frameworks, right? It’s a bad time to invent new tools. And use technology, you don’t know it’s just gonna slow you way down. Now understanding like, Oh, I’ve never used AWS before, okay, well, fine, you know, use the cloud or whatever. But beat pick and choose your battles. And what you’re going to spend a lot of time on, it is not a time to just explore weird as programming language, weird as database weird as hosting, like, just keep it simple and focus on getting the product done and use common things. So you’ll get it done faster. And so you can recruit people to help you.

Matt DeCoursey 46:25
Yeah, I think you covered every point that I wanted to make. I mean, stick with that, you know, you mentioned there’s, you know, really that six core languages. I think in summary, in the end, like keep cross compatibility in mind, half of your visitors are likely to be doing it on a mobile device. Yep. That is remarkably easier now than it was 10 years ago. And just think about some of that upfront, like, if you’re building a mobile app, you want it to be cross compatible, or you’re gonna have basically two businesses under one roof, you’re gonna be in the Apple business in the in the Android business, which you are anyway. But having one, one codebase, it’ll get you almost all the way there is something to consider. Also, I think that a reminder that much like fashion, software is never really done. It’s never really complete. So if you’re telling yourself if you’re sitting around and planning your software business, and you’re like, yeah, when it’s done, know that whenever I take that call from a potential client at Full Scale, and I hear that the first thought in my head is man, this person is in for a big surprise. And I try to, because it’s not and if you if you aren’t budgeting and planning for a person to be available to fix the problems that come up, now, mobile apps are made are one thing that I do sometimes refer to as having a chance of being somewhat complete. But what happened when iOS 14 came out? It broke half the App Store.

Matt Watson 48:00
Yep.

Matt DeCoursey 48:00
So there was a ton of people that probably just took their app down because they didn’t have someone to fix or they weren’t dealing with it. You know, hopefully, you found some good advice for what you need if and once again, if you want some advice or help when it comes to building your software team, which is a key component. You know, 10 years ago, I was I was enamored with how cheap I can hire people. And I’ll live on the opposite end of the spectrum now we focus on on the how, how good they are. We want the best people possible because they don’t leave a trail of technical debt behind them the same way that that inexperienced folks do. You can build around a highly experienced CTO, developer a lot of different people they can going to help you avoid a lot of heartache and technical debt. Matt, good episode, man. I’ll see you on the next one.

Matt Watson 48:55
Thank you.