Episode Summary

If you’re a service firm looking to productize expertise, automate delivery, or build a client-facing app, you’ll eventually run into the question: What should we build this in? In this episode, Justin and Greg demystify the “tech stack” conversation and give you a decision framework that keeps you out of the weeds. Their core point: for most business software, performance differences between common languages are negligible. The real risk isn’t choosing something that’s “a little slower,” it’s choosing something you can’t support, hire for, or extend without paying a premium later.

They also offer a simple approach for non-technical founders: get the proposed language/framework in writing, then sanity-check it for popularity, support, and whether it’s overkill. For mobile apps, the choice is often even simpler: default to cross-platform (React Native or Flutter) unless you have a strong reason to go fully native. The goal is a stack that you can grow with, staff for, and maintain as your software becomes more central to the business.

Episode notes

  • A “tech stack” is the layered set of tech choices from infrastructure up to the application layer
  • The episode focuses on the top layer: languages and frameworks people choose to build products/apps
  • Java vs JavaScript: totally different, and JavaScript’s name causes endless confusion
  • JavaScript became ubiquitous because it ran in the browser and the browser was everywhere
  • Performance talk is often overblown for typical business apps
    • Example mindset: small millisecond differences rarely matter for invoicing, intake, internal tools, etc.
    • If one piece needs to be fast later, you can offload that part to a faster language/module
  • Better selection criteria than “fastest language”:
    • Can you hire for it easily (check job boards like LinkedIn/Indeed)
    • Is it well-supported with a strong community and ecosystem (libraries, tooling, docs)
    • Is it overkill for your use case (ask ChatGPT directly)
    • What’s the future of the software: quick internal tool vs product you’ll build a business around
  • Don’t blindly pick “#1 most popular language”
    • Anything mainstream (top ~10–20) is generally fine if it matches team expertise
    • If someone suggests something uncommon, ask them to justify it clearly
  • Mobile apps are often simpler:
    • Native: Swift (iOS), Kotlin (Android)
    • Cross-platform: React Native or Flutter typically reduces cost and complexity
    • For most service firms building an app, cross-platform is the default choice
  • One major exception: client ecosystems can matter (ex: deeply Microsoft/SharePoint/Dynamics environments)

Episode Transcript

Justin Davis: Hey, welcome in here to Leap 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 co-host, Greg Ross-Munro. Hey Greg, how you doing? Happy Friday.

Greg: Happy Friday, Justin. Glad to see you are full of pep, as usual.

Justin Davis: You know, I like to live life at full speed if I can.

Greg: You definitely do. You bring the energy, and I have to raise myself up.

Justin Davis: I like it. Well, here we are. It’s Friday afternoon. How’s the week been for you?

Greg: Good. Busy. A lot got done. I think there’s a birthday waiting for me at the end of this weekend.

Justin Davis: Aha, yes there is a birthday waiting for you in just about 48 hours. Productive week.

You know what I discovered this week? I’ve discovered this multiple times and kind of came back to it. I really don’t like electronic to-do lists. I’ve struggled with this for years and years. And finally I just went back to my old friend, which is the steno pad. Writing down my things and marking them off. I’ve been way more productive this week as a result.

Greg: Do you see what I’m holding up? This is how I run my life. Pen and paper for to-do lists.

Justin Davis: Ah yeah, pen and paper. Even for we technology folks, there’s still a little dinosaur in there. But that’s okay.

So here’s what we’re talking about today. You’re running a service business. You’re looking into technology. You’re thinking about building something. You might be thinking about productizing your service, turning it into a SaaS company. You might be thinking about using automation or building an internal platform.

And as you start to go through that due diligence, you start to wonder what you should do. A question about platform comes up. Language. What should I build this thing in? Should it be built in this language or that language, this platform or that platform?

And if you’re not in the space, if you’re not building software every day like we are, it can be intimidating. There are numerous platforms, all kinds of words that don’t mean anything.

So today we thought we’d break down how to make that choice better. How to think about it, and some things to keep in mind. This is going to change all the time. We’ll use some recent examples from fall 2025 of what’s popular, but if you listen to this in five years, obviously some things will have changed. Hopefully the principles still hold.

What do you think?

Greg: Cool. Yeah, I like tech stacks as we can.

Justin Davis: Yeah. So let’s start there. You said “tech stack.” What’s a tech stack? For people who don’t know, what is that?

Greg: Think about technologists thinking about technology vertically. That’s why it’s called a stack.

At the very bottom, you’ve got the metal, the machine that the technology is running on. Then the next layer up might be the operating system. Windows, iOS, those kinds of things.

Then there’s what your server is running on, what’s serving information to your app or website. And then finally the application infrastructure at the top.

Each one of those is a choice that has to be made. And when you get to the very top of the stack, that’s when you have to make the choice people ask about most: what programming language.

You’ll hear things like Flutter, React Native, PHP, C++, Java, .NET. And that’s what we’re talking about today. I think we’ll focus only on that top sliver because that’s what most people ask.

I had a phone call the other day from a client of ours who’s building a managed service company. It’s a healthcare company. She wants an app for patients and caregivers that will interact with the system we built.

And she said, “I’ve been reading about my choices and I think we’re thinking of going with Flutter.” And I was like, okay. Maybe you should just ask me instead of doing your own research.

So when you start to hear Flutter, React Native, PHP, C++, Java, .NET and all these things, that’s the world we’re in.

Justin Davis: Yeah, great explanation. And we’ll leave all the servers and the longer-beard pieces of the tech stack to other episodes.

So when we talk about language, you might have heard things like Vue, React, React Native. These aren’t languages. They’re libraries or frameworks, and they use languages underneath.

You might have heard of languages like JavaScript, PHP, Python, Java, C. There are lots of different languages.

Greg: Can we do a quick aside and nerd out for one second? Can we just talk about JavaScript?

Justin Davis: Yes, please. I would love to talk about it. I love JavaScript.

Greg: First, Java is a language. Big, bulky. I was a professional Java programmer for a long time. Java has positives and negatives.

JavaScript has nothing to do with Java. Netscape needed something to run in the browser in the 90s to make things happen, like text blink and other annoying stuff. They made a script language for the browser and named it JavaScript, probably to capitalize on Java’s popularity.

They cursed all of us by creating confusion. And JavaScript evolved from a language designed to make text blink into something that runs almost everything now.

Anyway, rant over.

Justin Davis: It’s true.

And I think JavaScript is like natural selection. It balanced performance and accessibility. Accessibility wasn’t just the language. It was because it was the language in the browser and the browser was everywhere. Everyone could tinker.

And that’s why it became what it is, along with some challenges.

And this connects to the broader point. The answer to “what language should I use” is not always “what’s fastest.” It depends on what you’re doing, and on factors beyond the code. It’s how the code gets into a product and how that product gets into the world.

Greg: Don’t get me started on what I don’t like about JavaScript. I could write a book.

Justin Davis: We can have that episode later.

But JavaScript’s ubiquity is an advantage. Like spoken languages, there’s no objectively best language, and the same is true for programming languages.

Greg: I think we’ve solved one question already. If you’re building something for a business, and you’re wondering about JavaScript, it’s unavoidable. Whatever you do, there’s going to be some JavaScript somewhere. If somebody says JavaScript, just say “okay” and move on.

Justin Davis: Totally fair.

So let’s move to the other factors in choosing a language that are bigger than performance stats.

Greg: Back up one second. What do you mean by performance of the language?

Justin Davis: When we talk performance, we mean: does it run fast, is it stable, is it secure.

Greg: Rule of thumb: the easier a language is to use, the slower it is. Gross oversimplification, but the idea is the closer you get to the metal and the less abstraction there is, the more you can optimize for speed.

But for most people listening, speed is not going to be an issue. Patient intake, invoices, business applications. Even the fluffier languages are fine. Hardware is so fast now there’s almost no bad choice for typical business apps.

Justin Davis: Exactly. And to be clear: for training large models, 4K gaming, high-performance stuff, yes, it can matter. But for most business applications, the differences are splitting hairs.

It might be 50 milliseconds in one language versus 45 milliseconds in another. In most cases, that five milliseconds doesn’t matter.

Greg: And if your application does require a part to run really fast, you can write that part in a different language. You can have a module in C, Rust, Go, something like that, and have your main application call it.

So you can stay in your safe, warm language for most things.

Justin Davis: Exactly.

Greg: So what are the most common languages out there? JavaScript, Python, PHP, then it starts to fall off. You get the Microsoft stack, .NET and C#, Ruby, and others.

So if I’m a business owner and I’m talking to a developer who says, “I’m a Python programmer,” what questions can I ask to know if that’s going to be a good choice?

Justin Davis: First, can the language do what you want? In almost all circumstances, yes.

Second, think about the future of the technology. How long will you have it? Are you building a tool you’ll use internally for three months, or are you building a whole business around it?

Because when you build software, there’s an ecosystem around it: people to work on it, servers to run it, documentation, tools. You want to make sure you can build and sustain that support over time.

So ask: how popular is what you’re building in? What framework are you using? Do a little research. Is it well supported? Can you hire people for it?

Drop the language or framework into a job site like Indeed or LinkedIn and see how many people come up. If it’s 20 in your local city, maybe not great. If it’s 2,000, you’re probably okay.

And you can also ask ChatGPT: how popular is this thing, how well supported is it, and is it overkill.

If it’s some esoteric weird thing, you might have a developer who loves tinkering with new stuff but isn’t thinking about long-term value and support.

Greg: Because even if you hire an agency today and you’re not trying to become a software company, it might grow. One day your software might eat your business.

And if you become a SaaS business, you’ll probably want to bring development in-house. When clients leave us and hire their own devs, we call that graduating. We miss them, but we love it.

Justin Davis: Exactly.

Greg: So we could almost list them out. If you search “most popular programming language 2025,” you’ll see Python near the top, then JavaScript and TypeScript, then Java, C++, and so on.

But you shouldn’t pick the number one language just because it’s number one. Anything in the top 20 is probably okay.

The combination is the expertise of the person doing the work and the language choice. You just need to check the box that it’s reasonably mainstream.

If someone says, “I want to use Clojure,” you should ask why. They need a really good reason.

And those lists can be misleading. C++ might be high because lots of software is built in it, but it’s unlikely to be the best choice for typical business applications.

Justin Davis: I’ve been on projects where people suggested C++ and I didn’t understand why. Often it’s because it’s all the person knows.

Here’s what I’d do if you’re non-technical and you’re interviewing a developer.

Ask them what they plan to build it in, and ask them to send it in an email so you can copy the text.

Then paste it into ChatGPT and ask:

  • How popular is this language or framework?
  • How well supported is it?
  • Is it overkill for what I’m trying to do?

That’ll give you a good idea.

Greg: Add “Is this overkill?” to your prompt. Some stacks are great for aerospace or game development but would be a terrible idea for an invoicing system.

You could build an invoice system in Unity. You could. But it would be a terrible idea.

Justin Davis: You could. It would be funky and weird.

Greg: So this world is vast and nebulous. But if it’s in the top 10 or top 20, you can hire people, and ChatGPT says it’s not overkill, you’re probably dealing with someone reasonably sane.

But it’s easier in the mobile world. If you want to build a mobile app, the conversation is simpler.

Justin Davis: Yeah. Mobile primarily means two platforms: Android and iPhone.

With mobile apps you install, you’re building for specific environments. Practically speaking, there are native languages: Swift for iOS and Kotlin for Android, and historically Objective-C and Java.

If you’re connecting the dots, you might think that means two apps, two teams, two codebases. And you’d be right, except there are cross-platform mobile frameworks.

You might hear Flutter or React Native. These let you write in one language and then translate to each platform.

You write once, hit go, and you get an iOS app and an Android app.

Greg: And it’s not just managing two apps. It’s paying for two apps.

With native, you need one person who knows both, or two people. With cross-platform, one team can do both. That usually saves money.

If you’re a service company listening to this, you almost certainly want cross-platform.

There are good reasons to build in Kotlin or Swift, especially for big enterprise or large B2C, but for most cases React Native or Flutter is fine.

Airbnb’s app is written in React Native. You and I worked on the Viking Cruises app in React Native. It’s good enough for big brands, and it’s good enough for you.

Justin Davis: Exactly.

And the key is the questions you ask. This stuff changes. But the decision framework holds.

First: will it do what I need, performantly? For almost all cases, yes. If someone says no, they need to prove it.

Second: will it be easy to find other people to work on this? Look at hiring markets.

Third: community support.

A lot of frameworks are open source. That means many people contribute tools and libraries.

If you need to process photos, for example, and you choose something obscure, it might be hard to find libraries to do common tasks.

But if you choose something mainstream with a huge open source community, chances are many people have already solved the problems you’ll run into.

That means less custom code and less cost.

Greg: But if you can hire people for it and it’s in that top list, you’ve probably checked that box.

One last point: your clients and industry might influence your platform.

The biggest example is Microsoft versus everything else.

If your customers are embedded in SharePoint, Dynamics, and the Microsoft ecosystem, it might make sense to stay there.

But that’s going to affect relatively few people.

Most of the time, Ruby, PHP, Node, Python, JavaScript, whatever, you’re fine.

Justin Davis: Yeah. Mostly JavaScript, PHP, and Python for 95% of you.

Greg: Okay, let’s wrap up.

JavaScript is unavoidable.

Justin Davis: And I would say it’s the best language on average in the world for building things on the web.

Greg: Fine.

Anything in the top 10 or top 20 for your backend is fine. Ask ChatGPT if it’s overkill.

If anybody suggests something funky, ask them to prove why.

If you’re building an app, you should probably be using React Native or Flutter.

And make sure it’s well supported: community support, hiring market, and mainstream adoption.

Did we hit all the boxes?

Justin Davis: I think we did.

I was going to say you could visit sourcetoad.com slash… I don’t know. I was going to make up a funny URL. But I was going to say we have an app where you can take a picture of the person who said they would write code for you and upload it, and we’ll give you a pie chart of the probabilities of languages they’re going to recommend. And whether they can write it in Brainfuck.

Greg: I’m sure you can write that by the time this episode comes out.

All right, Justin. Enjoy your weekend. It’s good to chat with you.

Justin Davis: Great as always. Until next time, we’ll see you guys soon.

Greg: Thank you everyone for listening.

Comments are closed.