Leap to Scale
Leap to Scale is for technology curious leaders of service firms who want higher margins without adding headcount. Each week, Justin Davis and Greg Ross-Munro show how to turn firm expertise into repeatable, sellable technology products: SaaS, packaged workflows, and AI-powered tools clients can buy again and again. With AI, more of your know-how can be captured, standardized, and protected as IP instead of being rebuilt in every engagement.
We focus on practical decisions: what to productize, how to price it, when to build vs. buy, and how to use AI responsibly without risking delivery quality or margin. Clear steps, real tradeoffs, usable examples.
Leap to Scale
Tech Stack Triage: Choose Languages Without Losing Your Mind
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Choosing a tech stack can feel like walking into a storm of buzzwords: languages, frameworks, and “best practices” that change every year. Justin and Greg break down a practical way for service-business leaders to choose technologies without getting paralyzed. They explain what a “tech stack” actually is, why performance usually isn’t the deciding factor, and what matters more: hiring market, community support, and long-term maintainability. Plus, a clear rule of thumb for mobile apps: when to go cross-platform with React Native or Flutter.
Hey, welcome in here to Lead to Scale. This is the podcast that helps service companies create breakout growth using technology. My name is Justin Davis. I'm one of your co-hosts here with my other other other other co-host, Greg Rossmanroe. Hey Greg, how you doing? Happy Friday, Justin. Glad to see you here. Full of pep as usual. You know, there's you I I just I like to live life at uh at full speed if I can.
SPEAKER_00Um you definitely have to you definitely bring the energy in. I have to raise myself up.
SPEAKER_01I like it.
SPEAKER_00Well, here we are. It's Friday afternoon. How's the week been for you? Good? Good, yeah, busy. Um uh you know, a lot to a lot got done. Lot got done, and um uh I think there's uh a a birthday waiting for me at the end of this weekend.
SPEAKER_03So uh-huh. Yes, there is a birthday waiting for you in just about 48 hours.
SPEAKER_00Yeah, how about you?
SPEAKER_03Good, good, good week. You ready? Good week, productive end the week with podcasting. You know what's something that I discovered this week? I discovered this week, um, and I and I've discovered this multiple times, and I kind of came back to it. I really don't like electronic to-do lists. I have I have really struggled with this for years and years and years, and finally I just I went back to my old friend, which is the stenopad, writing down my things and marking them off, and I've been way more productive this week as a result.
SPEAKER_00So do you um I know this is an audio medium, but do you see what I'm holding it up? This is how I run my life.
SPEAKER_03Uh, yeah. Pen and paper for to-do lists, even for we uh technology folks, there's still a little dinosaur in there. Uh something tactile about to make it. What are we talking about today? Um, so here's the thing that we're gonna talk about today. So you're running a service business, you are looking at a technology, you're thinking about building something, you might be thinking about building, you know, you might be thinking about productizing your service, turning it into a SaaS company, software as a service company, you might be thinking about using automation or building an internal platform or something like this. And as you start to go through that due diligence, you start to wonder like about what you should do there, a question about platform comes up, language. What should I build this thing in? Should it be built in this language or that language or this platform and that platform? And there is, if you're not in the space, if you're not, you know, building software every day like we are, um, it can be pretty, I mean, it can be very intimidating, I think, because there are numerous platforms, all kinds of words that don't mean anything. And uh so today we thought we would break down how to make that choice better, um, how to think about that, and uh, and some things to keep in mind as you go forward. And and remember that this is something that's gonna change all the time, right? So we're gonna give some guidelines, some ways to to make this decision, if you will. Uh, we'll use some recent examples here in the what is it, fall of 2025 as to what the popular things are. But if you're listening to this in five years, then obviously some of the things have changed. But hopefully the the principles by which we uh make these decisions still hold true. So that's what we're gonna chat about uh today. What do you think? Cool. Yeah, I'm I'm I like tech stacks. Yeah, so let's get let's let's start there, actually. Like you said, tech stack. So let's start there. What's a tech stack? You know, for those people who don't know or listen to go tech stack, what in the world is that? What what is that?
SPEAKER_00I mean, it I it's we think about technologists think about technology in vertically. That's why it's called a stack, right? Um you at the very bottom, you've probably got the actual metal, the machine that the computer that the technology is running on. That's like the bottom. And then the next layer up might be, you know, we're not going to get too detailed here, but like the operating system is part of the stack, right? And it's like what Windows or or iOS, these are the kind of things that you'll be familiar with. And then there's what your server is running on, on top of that, right? So like what's serving the information to your app or to the website. Um, or it could even be the application itself. And so that that's when we talk about the technology stack, we talk about the from the very bottom of the metal all the way up to the operating system to maybe the server infrastructure of those layers, and then finally the application uh infrastructure uh technology at the top. And each one of those is a choice that has to be made. And hopefully it's a choice you don't have to make. The the other kind of part of this is what kind of as you get to the top of the stack, to the application, that's when you have to make the choice of like you'll have heard people have will heard of like what programming language uh has to be used. Because you can use multiple programming languages uh in in in many stacks, uh, but when you get to the very top of that stack, like your choices start to get limited based on all of these things. So I think maybe we're today we're gonna focus really only on that very top sliver because that's what most people come and ask me. They say, like, hey, you know, I had a phone call uh the other day from uh a client of ours who is building a managed service company, and she called me up and she said, Oh, I'm thinking of we're building a mobile app. You know, we already have built all the application software around her her managed um uh it's a healthcare company that does um uh managed services for healthcare. And she's like, Well, I want an app for patients and caregivers that's gonna interact with our system. And I was like, Cool, great, awesome. Like, we can help you with that. She said, Oh, I've been reading a lot about my choices, and I think I think we're thinking of going with Flutter. And I'm like, okay, yeah, okay. Well, maybe you should just ask me instead of doing your own research. Like, so so the when we that's when you start to hear things like Flutter, React Native, PHP, C, Java, .NET, all these things, not .NET's not really a language, but with the sorry, but um, all these kind of things that you start to hear about. That's what we're talking about, and I think we should probably start there.
SPEAKER_03Yeah, I think that's a great, great explanation, great breakdown. And I think that's right, like the language side. Uh, we we'll we'll leave all the servers and the other other uh deep um longer beard pieces of the snack uh stack to to other episodes. Um, so when we talk about the language, right, and we start to say, you know, I want to build this thing on Flutter, I want to build this thing with React. Somebody, you might have heard of that, or you might have heard of something called Vue, or you might have heard of something called um React Native, for example. These are examples of kind of front-end, they're not languages, so really they're they're they're those are actually libraries, frameworks, we call them. Um, but they use specific languages underneath of it. You might have heard of languages called like JavaScript, um, PHP, uh Python, things like this, Java C. There's lots of different languages out there.
SPEAKER_00And so can we just have a quick aside here, just to nerd out for one second about yeah, can we just talk about JavaScript? Yeah, just for just please. I would love to do that. You you you like JavaScript, but I love JavaScript. If you if people don't know this, first of all, Java is a language, it's a big, bulky language. I was a Java programmer, professional Java programmer for a long time, and it has all sorts of positives and negatives. It has nothing to do with JavaScript. JavaScript is not a light version of Java, it was just the folks at like Netscape needed something. They they they wanted a language to be able to make things mainly like text blink and annoying things like this in your browser in the 90s, and they needed a language, so they made this, they wrote a language and they named it JavaScript for I don't know what reason. I think maybe to capitalize on the fact that people knew what Java was, and this is going to be a script language that was gonna run inside your browser rather than on like its own thing, and so they did that and they have cursed all of us for eternity by doing this. But it is creating confusion. And second of all, JavaScript has evolved from a language that was designed to make text blink in your browser to the thing that runs almost everything now.
SPEAKER_01Yes, yes, anyway.
SPEAKER_00There's my random.
SPEAKER_03I think JavaScript is like sort of it it proves out like natural selection, right? Because the thing that made JavaScript work was not because it was necessarily the most performant at everything, it was that it balanced the perfect blend of performance, performant and accessible. And the accessibility part isn't because of how the language was written necessarily, it's because it was the logic language in the browser, and the browser all of a sudden ended up on everyone's computers, and everybody had that environment within which they could tinker, right? And that that's the reason why it became kind of what it is and inherited some of the some people would say faults challenges, some like the async nature of it.
SPEAKER_00Don't get me started about what I don't like about it. I could write a book about what I don't like about Joester.
SPEAKER_03I think one of the things about it's almost like, and and look, I'm not gonna say the English language is the best language in the world, it's not the best, there's no objectively best spoken language, right? At all, just like there's no best programming language, right? But the English language, even despite the fact that it's really, really difficult to learn, well, we could talk about like it's it has a level of ubiquity that makes it useful because of its ubiquity. We can talk about how the ubiquity may have happened. There's a different podcast, but um, that is an advantage of the language, and that gets to sort of, I think, a little a broader discussion that we want to talk about in this when you're choosing a tech stack and how you think about that. The answer to the question is not always what's the fastest thing, what's the whatever thing. It really depends on what you're doing, and it depends on a lot of other factors that aren't directly about the code itself, but are about how the code gets into a product and how that product gets out into the world.
SPEAKER_00I think we've at least solved, we've answered one question, because I think we came to this conversation with the idea that somebody has a business, they have probably a service business, and that service business has decided that they're going to productize some piece of their business or automate some part of their business to become more profitable. And they're asking the question, what programming language should I use to build this thing, or who should I hire to do this? And one of the questions might be something about JavaScript, and the answer is it's unavoidable. Whatever you do, it's gonna have some JavaScript somewhere, so you don't have to worry about JavaScript. If somebody says JavaScript, just be like, oh, okay, yeah, and move on. And then we can move on to the rest of this conversation. Yes. Is that fair?
SPEAKER_03Yes, that's totally fair. Okay, so let's talk then about let's move on to the other part of the conversation, which is there are these other factors. Like JavaScript can be criticized, of course, for lots of reasons, um, and fairly so, as a lifetime JavaScript dev. Um, but there are a lot of factors that go into choosing a language that are bigger than just the strict performance stats of it of the language itself, right? So hang on, I think you back up back up one second. What what do you mean by the performance of the language? Oh, yeah, sure, sure, sure. When we talk about the performance of language, what we're really just talking about is does it run real fast? Is it real stable? Is it real secure? And that's really what we're talking about when we talk about performance. Is it fast and stable and secure? Yeah.
SPEAKER_00Um and the rule of thumb, generally, is that the easier a language is to use, the slower it is. And that is that is a gross oversimplification. But the reason is that the harder a language is, the closer, the like the less abstract it is, the more you have to know about programming to be able to use it. And that's how you get things to run really quickly. And then as you as you get like more fluffy languages that like do things do more things for you, they kind of have abstracted out lots of these things, and as a result, they run a little bit slower. But I think I would argue that in most situations of people listening to us talking about this conversation, that speed is probably not gonna be a problem. No, and if you're if you're building a patient intake system or you're building a uh an a mobile app that even even using JavaScript, even using the most like some of the fluffiest of the like languages, speed is mostly not gonna be an issue. So you don't have to worry about it. Hardware is good and so good, hardware is so fast these days that there's almost no bad choice of language for most kind of like business style applications. Correct.
SPEAKER_03And and and and the thing to know about that is that for most applications, we're not talking, don't go light us up with the comments about like how it's not this for super and for training LLMs, and it's not like this for super intense high 4K gaming. I I get like, yes, we understand that there are times when these performance things really do matter, but for the most part, like you said, a patient intake thing or a um a thing that automates your invoices or whatever it is. Um the difference in speed, and and I think that's important to talk about because sometimes people will be like, oh, oh, you know, that language is really slow. You sure you want to use that? Let's talk about relatively what we're talking about here, because you have to think about what we mean when somebody says this is slow versus something that's fast. Let's talk about what we're actually talking about here, and I'll give you an example of it. It might be that like it takes 50 milliseconds for a computer to run a function in JavaScript, and it can run the same equivalent type of function in another language in 45 milliseconds, right? And in some in some applications, that five milliseconds matters. In almost all applications, that five milliseconds doesn't matter. And so it's it's important to understand, like you're you're all like you said, the hardware is so good, the languages aren't all so good that you're still talking about splitting hairs on the upper tenth like percentile of the whole speed continuum, if you will.
SPEAKER_00And the other thing to point out there is if your application does require some part of it to run really, really quickly, you can actually write that piece in a different language. You don't have to have one application that is just built in one language. If you are going with if you're building a PHP system that runs your whole back-end office thing and it's running in PHP, and there's one part of it that five years from now you realize, well, this one thing is costing you a lot more lot of money because PHP is a bit slower to do that, and PHP gets a bad rap for lots of reasons. PHP is a perfectly fine and good choice for 90% of things in the world. You can go and write a module in C or Rust or Go or something like that, and then have the PHP ask that application to do that piece for it, and then go back to your like safe form little language. Right. Yes, exactly. All right, so I mean uh we cover performance, I think. Yeah, I think so. But when we met we I mentioned PHP, um I guess the question is the what are the most common languages out there? Uh I looked this up and uh JavaScript, which by the way can be a front-end language now and a back-end language, which is bizarre. We don't have to get into the details of that. Um Python, still super popular. PHP is massively popular. After that starts to kind of fall off a little bit, you get the uh the Microsoft stack, the the dotnets of the the dot net things of the world mainly um uh uh C their version of um uh C Sharp, uh which is a lot like Java actually. Yep. And um uh you've got the Ruby's, you've got the these are all the things that you people will hear. If I came to you um and I'm a business owner, and you are a developer or uh somebody, and and you are I don't know, you're a Python programmer. Yeah, you mainly do Python. Yeah, how do I know if what questions could I ask you to know if like that's gonna be good enough? If like if really I should go with you as the choice.
SPEAKER_03Yeah, great question. So there's a few things that I think think about there, right? If I'm in that position, one of the things I'm thinking about is of course I'm thinking, is the language going to be able to do what I want to do with it? The answer to that question in almost all circumstances is yes. And it doesn't really matter what language you choose, unless you choose some weird esoteric language, um, which you're not going to. And so um it's probably going to be able to do everything you want to do. So check. That's good. The second thing I need to think about as a business owner is I need to think like I'm gonna have a piece of software built. This guy I met at a party, he said, Oh, yeah, I can help you build that thing for sure. I can definitely help you do that. I'm a Python guy. Let's go. Okay, the next thing we need to think about is what like step back. What is the future of this piece of technology? Like, how long are you gonna have it? It is are you gonna grow it? Is it just a tool that you need to use internally and this guy can work on it forever and it doesn't matter? You're gonna use it for three months and it doesn't matter, or is it something that you're planning on building an entire business around? Okay, and so like we start to ask those questions. This is about the light, this is about the support and ecosystem around software. Remember, when you have a product, you have a thing you're building that is made of code, there's a whole support ecosystem around that of people to work on it. There are servers that run it, there are documents that help to describe it, there's lots of support around that product. And so you want to make sure that you are getting into a situation where it's likely you can build that support easily over time. So if this guy says I'm building it in Python, I'm a good Python dev, I think some questions to ask are okay, that sounds good. Um, how popular is what you're building in? What framework are you using? Do a little research on that. How many people are using this thing? Does it seem like something people say, like, I wouldn't use that? Ask ChatGPT, how popular is this thing that they said? Is it really popular? A lot of people use it, or is it some esoteric weird thing? If they say it's an esoteric weird thing, you have an engineer or developer who loves to tinker with new stuff, but isn't thinking about long-term enterprise value and support of this thing, right? There's nothing wrong with tinkering. I love doing that too. But these things happen in different times. And so um, that's one way to start to think about it, uh, is to start asking the questions about like what are you building it in, and then go do your research on how well is that supported, how hard is it gonna be to hire people for that, right?
SPEAKER_00Um because even if even if you are going to go hire an agency to build your product or to do your to write your software or whatever, as a services company, maybe you're like day one, you're not going, you're not thinking about becoming a fully fledged software company. You might be thinking of automating a process or or taking something off your employees. But if that grows one day and continues to get bigger and bigger, and like actually your software eats your business, which kind of you know, like you turn from a like a professional services company into a SaaS business one day, which is possible. That happens all the time. You will probably want to bring that development in-house because that will actually then become your core competency will go from being the thing that you're an expert in in your in your service delivery to actually being a software company. Yep. So to I think to put up um a point on that is maybe not now, maybe not in 10 years, maybe in 10 years, you will you will become a software company and you will need to find people who can maintain the system that you've built from that agency. It's still like when when clients leave us, we call and they they get going on their own and they hire devs and we even help them with that. We call that graduating because we feel so good about it. We do miss them though. We do, we do. Okay, so uh that makes sense. So if you if if it's well supported and other people can work on it, what else what else would you want?
SPEAKER_03So I think that like being like well supported. And the other thing that I think you have to think about, because you have to think like, are a lot of people using this? Could I find someone to help me if I need help? You've got to be able to be able to that question. And you have to say yes. You have to be able to find somebody. It can't be hard to hire this person. I would even say take the language and the platform that this person mentions, go drop it in Indeed or something like that, and look and see, like, or LinkedIn and see how many people come up who can help you with this. Like in your local city. If there's like 20, probably not good. If there's 2,000, great, you're probably okay. Right? So that's also a good litmus test for this.
SPEAKER_00The other I mean, we could actually just almost list them out now, right? Like, so you know, yeah. We can look with with a little bit of with with some maybe some caveats here. So like by far, when you look up, if you look at like most popular programming language 2025, Python's gonna come top of the list. Almost always, I think Python is gonna be there, right?
SPEAKER_03Uh for AIML purposes, yes, but not for web apps.
SPEAKER_00But this is this is my point, right? So anything you can build a web app in Python, and it's really and I would say go for it. Like you there are tons of agencies and tons of people who do this every single day. Sure. Perfectly fine language to do that. Um and then you'll see probably next is gonna be Java, TypeScript, sorry, JavaScript, TypeScript, they're kind of the same thing, doesn't really matter. Yeah, like the JavaScript family of things, node, all that. Those will be in the top, top kind of two. Maybe then Java, C. You'll you'll you'll see like a list of these things. Yeah, the one thing you have to keep in mind is you might see like a drastic drop off from like Python to I don't know, Ruby on Rails. Yep. Right? And so you might think, well, I should go with Python because it's the number one thing. But that is not the right way to think about this. Anything in the top like 20 on that list is probably okay. The the combination is the expertise of the person who's doing it and the language of their choice. It just you just have to check the box that it's in that top, top 20, whatever. So if someone comes to you and says, Oh, I want to use uh closure to build this thing out, build the build the your dream application out. You go and you see, oh, closure's not in the top like 15, then you need to ask them why. Right. Damn good reason. And they're really good, and if you could defend it, fine. And I but like I love Clojure, by the way. If anybody's interested, it's a Lisp derivative and it's like really cool for like a whole bunch of stuff. And um, the way it's structured is like beautiful, and but it's like it's gonna be really hard to find closure programs.
SPEAKER_03You would never if somebody said I want to automate my invoices or like clients like paying their bills, you would never use closure to do it. You would use React and JavaScript and or view.
SPEAKER_00I don't know, whatever. But the the point is so, and then when you also look at that list of of programming languages, the other thing to keep in mind is that it might not necessarily be w representative of the things you want to do. You might see like C up there on this list, and that is probably a popular programming language because lots of software is built in C. But it is unlikely, I'm just saying, it's unlikely that if you want to build a business application, that C is the best choice. And so you're probably not gonna hear anyone at an agency or developer that you talk to suggest C as an option, but it will still be on that list.
SPEAKER_03Yeah, it is still on that list. I have been on projects where people suggested that, and I was like, I don't understand why we're doing this. And the reason is because the person that suggested it's all they knew, and they've been doing stuff for 40 years and then done it in that. Uh, and so that's fine, but that is not I would just take, you know what I would do if I you know what I would do? I would say if you don't know what any of this stuff means, we have the like the the privilege and pleasure of uh of knowing when we hear these words if if things sound weird or if they don't, but like you know, like you all listening to this, if you don't have if you're not technical, you have no idea. So here's what I would do I would say, can you if you have a developer that wants to help you build something, you're interviewing somebody, they've helped you build something. What I would say is ask them, what do you plan on building this in? And and ask that in an email so that you can get the text and you can copy it. You can copy that in the chat GPT, and you can ask a few questions. How popular is insert thing they said.
SPEAKER_00This is a good idea.
SPEAKER_03How well supported is, insert thing they said. How like all of that? Ask these questions, and that is going to give you a really good idea about where you stand.
SPEAKER_00Yeah, and I would I would suggest adding to your prompt. Do you think this is overkill? Yeah, it's a great one. A hundred percent. Yeah, because some technology stacks and some languages are great, but they're for like the aerospace industry or game development or something. Could you build your invoice application system in Unity? Absolutely, of course you can. It would be funky and weird, but you could be the worst idea ever.
SPEAKER_02Okay. It might not be. You're plugging them off a shelter. I don't know, sending them out to get the account receivable.
SPEAKER_00All right, so the the the kind of world that we've talked about there that is is vast and um nebulous, and we kind of as long as it's in the top 10 and like you can hire people for it, and you and Chat GPT says it's not overkill, do you know that you're dealing with somebody who's like reasonably sane? Um, but it's a little bit, I think, easier in the mobile world. Like if you are wanting to build a mobile app, I think there's a much simpler conversation we can have here. Do you would you agree?
SPEAKER_03Yeah, I think I think with a mobile app, it's a much more simple discussion because with a mobile app, what you're dealing with you right, we have two primary platforms, Android and iPhone. Okay, and and you might say, well, the web is just one platform, but the web isn't one platform, the web is a lot different than mobile, because with mobile, what we're dealing with is are apps that we install on these particular environments, and so they have to be written for those particular environments, that being Android or iPhone. What that means is is that practically speaking, there are two languages, one for Android and one for iPhone. Now that's not 100% true. iPhone has a couple different dialects, but in general, you can think of it that way. Um, there are also some frames. From Kotlin and Swift, to be specific.
SPEAKER_00Kotlin and Swift, yes.
SPEAKER_03Thank you.
SPEAKER_00Swift for S and Kotlin for Android.
SPEAKER_03Yes, exactly. Exactly. And the Objective C, we used to write things in Objective C uh natively, and then now we write things in Swift. Or Java for Android, yeah. Or Java just doesn't matter. Right. Doesn't matter. Right, but either way, there are two languages to choose from. There are we would call these native languages. Native, thank you. Native languages, which means they they run on the native device. It's they under they speak the same language as the device. Okay. Yep. So the other way that the other way that you can build things is you can you could say, well, I don't what that means, and if you're if you're connecting the dots here, you can think, well, that means I have to build my app for uh for Apple, iOS, and for Android, and I have two apps that I have to build, which means I have to have two teams and I have to have two code bases. And you would be correct, except there are some uh there's some platforms, some languages, uh or pl or frameworks that are known as cross-platform mobile frameworks, whatever. And some of those are like you might hear of Flutter or React Native. And what this allows you to do is write in a different language with React Native, it's JavaScript. With Flutter, it is go. Is Flutter go? Um, I can't remember. It's g, yeah, or it's C. Uh or something like that. But either way, um, you write in one language and it does what's called transpiling, and all that means is it basically puts a translator in front of it.
SPEAKER_00That's right, sorry.
SPEAKER_03And it see so many different programs, and it doesn't even matter because remember, like as we're talking about this, you realize we don't even know. We build things in these in these languages, and we even forget what the native language is, right? Because that's how little it kind of matters in reality a lot of times. Um, but you have these cross-platform frameworks like React Native and Flutter, and what they allow you to do, React Native, you write, yeah, it allows you to write it in a different language, and then it essentially translates it into the language of each one of those platforms. So you you write it in one language and hit go, and it gives you an iOS app and it gives you an Android app, and you put each of those on the devices, and then that works. Uh, and that way you don't have to manage two different apps.
SPEAKER_00Um, the thing to point out there is not just to manage the two different apps, it is to pay for two different apps. If you are, if you if you want to if you want to build a native app for Android and a native app for iOS, you need either one person who's very good and knows both languages, or you need at least two people, one to do each. Whereas with the cross-platform stuff like React Native or Flutter, you need one person or one team, whatever, that just knows one system and they can do both jobs. Yep. And at the end of the day, that will probably have cost saving. And I would go so far to say that if you're listening to this podcast and you are interested and you're like a service company and you're looking to build an app, you almost certainly want to go that route, the cross-platform route. Yes. There are many, many good reasons to build an app in Kotlin or Swift. Many good reasons. Especially many good reasons. There are a handful of reasons. There's there's big enterprise companies and like something that's going to be a like a really strong big B2C thing. And but like uh Airbnb, their app is written in React Native.
SPEAKER_03And I yeah, I know a bunch of Fortune 500 retailers. There's a company in town here that builds mobile apps for uh Fortune 500 retailers, uh, like Pier 1. Well, Pier 1, one Fortune 500, but anyway, they like Lowe's, Home Depot, that kind of thing. And um, it's all built in React Native.
SPEAKER_00Yeah, you and I work on Viking Cruises app and we built it in React Native. So it's fine. If it's good enough for Viking Cruises and Sony and people we use most years, almost all circumstances, it's fine. So we've at least settled two things. You can't avoid JavaScript, and you probably should just pick React Native and or maybe Flutter. If like you find a developer, Flutter is also a fine it's fine. The ecosystem is fine, yeah. Right, there's enough people to say Flutter. So yeah. Okay. Well, that's easy then. We solved that.
SPEAKER_03That's it. I think I yeah, I think what it really comes down to is that like at what you are trying to think about, and this is what will help protect you against future different languages, different frameworks, because this stuff changes all the time, guys. We would have had different answers to this question like uh several years ago, and so it always I mean, well, maybe not me.
SPEAKER_00It is consolidating in like the last like four years, five years, it's been pretty solid.
SPEAKER_03Yeah, it has been. It used to be a lot more volatile than it is now. But the key is is that what you're really the questions to ask yourself are will it do what I need it to do performantly? And the answer to that for almost all of your cases is yes. And if somebody tells you no, then they need to prove it to you. Second question is is it going to be easy for me to find other people to work on this? Yeah, you can look at that. Right. Yes. Because that's all you always need to think about succession planning, right? And so go look at job listings, go see, get an idea for how many people write in that language or that framework, right? Um, and then the third thing is is how much support out there is there in the world for this thing. Remember that a lot of these are what we call open source, which means that they are written by just Joe Schmoes. And I don't mean Joe Schmoes to say that they don't know what they're doing. These are some of the most expert engineers in the world, but they decide to build software and offer it up to the world for free. And they say anybody else can help collaborate on it, right? And it actually is extra, I mean, anyway, I won't go into the whole open source thing. But the point is in saying that is that as like open source and thinking about the number of people that are available to deal with that and the number of different things, packages people can write different libraries, they can write different other pieces of software to solve problems. So, if for example, your service company needs to process photos, well, if you choose a language or a platform that is not super popular, it might be really hard to find that a way to convert a photo from a JPEG to something else, for example, or whatever. But if you use something like React Native or use something like Flutter or use something like React or Vue, where there are millions of people engaged in this open source community, then there's probably 10 people who have actually solved that problem for you, which means that's less money that you have to spend to write code to solve that specific problem. So community support is a really, really big factor in language and platform selection that not a lot of people talk about.
SPEAKER_00But it it kind of goes back to um the fact that if you can find lots of people who can write it on Indeed, and it's in that top 10 list anyway, then you're then there's gonna be a lot of community support. You probably already checked that box. And we we can say that for 100% for a fact for Flutter and for React React Nive. Yep, I think that's true. I I would say I'd like to make one last point before we kind of like wrap up here, which is there is one type of decision that might be different, that might alter the what you're doing, and that is if you work in certain fields and certain customers, there is a chance that they will have some impact on the technology you choose. And the only thing I can really think of there is Microsoft versus anything else. There are situations I've run into where like your clients are like using SharePoint or or I don't know, Microsoft Dynamics or one of these things, and as a result, it would make more sense if you're in the Microsoft ecosystem. Yep. Which by the way is all also open source now and um great and super powerful, and um Microsoft has done a lot of great things and some things that we're not always happy about, but uh that is another question that you might want to ask yourself, and it's gonna it's not gonna affect, it's gonna affect very few people. Like most people who are building something are not going to need a Microsoft product. Um if you're like a service company and you're moving into this, it's unlikely you need to be in that ecosystem. But yeah, there are people who like you have if you're a consultant and every single one of your clients is deeply embedded in some sort of like Microsoft SharePoint tool or something, you may want to consider that to be the your platform of choice. Yep, yep, absolutely. Everything else, Ruby, PHP, Node, Nix, whatever.
SPEAKER_03Mostly JavaScript, you're fine. For 95% of you, that's gonna be all you need.
SPEAKER_00Okay. So let's wrap up. We JavaScript is unavo unavoidable.
SPEAKER_03Unavoidable, and I would say the best language um for on average in the world for building things on the web.
SPEAKER_00Okay. Um uh anything in the top 10 for your backend language is fine. Um, but make sure you uh if it's uh ask ChatGPT if it's overkill. Um uh if anybody suggests anything funky to you, ask them to prove why. Yeah, if somebody says I want to write it in brain fuck, be like No one's gonna say that. That's a joke language.
SPEAKER_02I mean, I think you can write real things in it.
SPEAKER_00You can write real things in it, but like nobody does. Nobody does. So it's a joke language. But like if somebody says, Oh, I want to write it in like Delphi or something like that. I mean, I don't know. I want to write it in C. I want to write it straight in C. Like then you should be like, what? Okay, let's um uh if you're building an app and you're listening to this podcast, you should probably be using uh React Native or Flutter. Yes, just trust us on that one. Um, and then make sure something's well supported. That's the community. That's if you can find people um on Indeed who are hiring it. And uh yeah, I think that's it. Did we hit all the boxes? Check all the boxes?
SPEAKER_03Yeah, I think we did. I just wanted to mention you could visit sorcer.com slash um I don't know. I was gonna make up a funny joke. I can't think of a good URL, but I was gonna say we have a an app where you can take a picture of the person who said that they would write code for you and uh upload it, and we will give you a pie chart on the probabilities of languages that they are probably gonna recommend.
SPEAKER_00I'm sure you can write that by the time this episode comes out. It definitely can. All right, Justin.
SPEAKER_02Yeah, good for it.
SPEAKER_00Well, thank you, man.
SPEAKER_03Enjoy your weekend. It's good seeing you. It's great as always. Enjoyed it, and uh, until next time, we'll see you guys soon.
SPEAKER_00Thank you everyone for listening.