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
Building Smarter: Leveraging Frameworks for Your Software Development Project
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
In this episode, Sara Altenhoff is joined by Justin Davis and Greg Ross-Munro. The three discuss the various approaches to building software, and the important considerations in choosing the right foundation for your application.
Key Points Discussed:
- Frameworks: Exploring the flexibility and control offered by frameworks, along with their customization and performance benefits.
- Content Management Systems (CMS): Understanding the ease of use, rapid deployment, and potential limitations in customization.
- Backend as a Service (BaaS): Examining the scalability and reduced backend overhead, as well as considerations around vendor lock-in.
- Customer Relationship Management (CRM) Systems: Highlighting the benefits of enhanced customer interaction, automation, and data analytics, alongside complexity and cost factors.
Listen today to gain insights into when to use these platforms and when it might be best to build from scratch. Don't forget to subscribe and follow the Decoder Podcast for more valuable insights into the world of software development!
Hello and welcome to another episode of Decoder Podcast, where we demystify the world of software development for our listeners. So we take you behind the scenes of a software development agency to explore how digital products are created from concept to completion. I'm Sarah Altenhoff, and I'm joined by a couple guests today.
SPEAKER_02I'm Greg Ross Monroe. Hey there, I'm Justin Davis.
SPEAKER_00And today we're gonna have a really fun conversation about the different approaches you can take when building software and apps. So I'm looking to build an app. Really exciting. But there's so many options out there to build your software or apps. So I know that like you can start from scratch and build something in a programming language. You can start with like something out of the box and build on top of that. I've also heard you can build things on top of your CRM. So with all these different options out there, today Greg and Justin are going to teach us about the four most popular options and when they will be the best fit for the project you're looking to build. So to start us off, I've heard about all these different frameworks that you can use to build applications on top of. So I'm hoping you two can explain to me the differences in all these frameworks and the best case, uh, the best use cases for each of these. Um, Justin, do you want to start us off by sort of explaining like a big picture what we mean when we say framework?
SPEAKER_02Yeah, absolutely. So a lot of the there's a lot of frameworks, there's a lot of different types of frameworks out there in the web development world, right? In the software development world. But the kind of frameworks that we'll talk about, that we'll start by talking about, are language frameworks, things like Larable for PHP, Angular for um for JavaScript, or React for JavaScript, which is um which is another type of framework. And essentially what they are are they're just collections of pre-built code that sort of build like the boilerplate bits of an app, or allow you to build the boilerplate bits of an app easily out of the box without needing to write it all yourself, right? And this is really useful because a lot of times when we build products, right? When we build something for the world, we are trying to solve a problem. We're trying to get to the core of how we're solving a problem with a product, a unique way of solving the problem in the world, right? Well, there's a lot of different parts of an app that we also have to do just kind of like as kind of like price of entry. You have to be able to log in, authentication, you have to have security, you have to have a database, you have to have a server, all of these different parts that like make a thing go, sort of like a car has to have wheels, it has to have a hood, it has to have uh steering wheel, those kind of things, right? And so what a framework does is it gives you those kind of things out of the box so you can work on the problem that you're solving, not work on like the bits that that surround it and and stand it all up. So it lets you get started faster and take advantage of best practices that other people have built on so that you don't have to build all that from scratch every time.
SPEAKER_01And the other cool thing about it is that like most of the time the frameworks themselves are free. It's it's not like it's not like you have to like pay anyone for these frameworks, they're kind of like developed by a community. And so you're never like ready, you might be locked into a kind of an ecosystem. Like I'm gonna, if I'm using Laravel for PHP, or I'm using Rails for Ruby, or you know, uh.NET for C Shop, whatever, I'm like in I'm in those environment, I'm in those environments, but those are like broad, very broad environments, right? And like they're not like you're not like being stuck with one vendor. It's not like you're stuck with um Salesforce forever, or you're not like at the mercy with of Amazon or something like that. So you have some portability behind that. And the trade-off is um kind of complexity, right? So um there's it's it's a it's a little bit you need to be a lot more technical to be able to work with these things. You need to be a software engineer to be able to do them. But the nice thing is that like you own everything, right? You can like take it and you can move it. And if you have an argument with Amazon, or if like Google shuts down some service, you can take all your toys and go home and you own everything like in that IP bundle. So if you sell your company, you're home free, home free.
SPEAKER_02I and I think one of the things you're you're hinting on as well here that I think is so interesting about frameworks and why they're so useful, A, because a ton of them are open source and free, right? And for those of you who aren't familiar with kind of what open source software means and why that's important and interesting, is open source software is software that was made by the community. Just a bunch of randos in the world who are like, we're gonna write some software together randomly, and we're gonna let other people just use it for free. And then they just keep writing on it. Why do people do this? I don't know. There's sickles out there, but those of us who build software and like build things that contribute it to the world, right? And so the cool thing is that we get to take advantage of that, use that framework for free. And not only that, it's like you get to basically tap into the hive mind of hundreds or thousands of developers around the world who all have eyes on it, who are working on making it as good as possible all the time. So you kind of get like an engineering team for free when you use one of these.
SPEAKER_00That's really cool. Um, so you're building a lot of it some s from scratch when you're using a framework, but there's also like pre-built modules, is what you're saying, that you can kind of like plug in. It's like, okay, I don't need to build the login screen from scratch. I can just like plug that in. Is that is that what you're saying?
SPEAKER_02Spot on.
SPEAKER_00Cool.
SPEAKER_02Yep, exactly.
SPEAKER_00So would you say this is sort of the the best place to start? Um, is this like would you recommend starting with the framework over anything else? Um or what are some of the like other than having to be have a technical team basically knowing this programming language, are there any other like reasons I wouldn't go with a framework?
SPEAKER_01I mean, it I I think I really like the choices of what you use to build on as a platform or like where you start, it really depends on like what you're trying to do and who you are. And I know that's like the worst kind of answer that anybody has, right? It's like, well, it depends. Like, yeah, but you know, below frameworks are just bare bones programming languages. And there are lots of use cases where you just want to just use a programming language, you don't even want the framework. We've had to build things for clients that needed to be so fast that the framework got in the way. Like it's set between because it sat between us and a database where we had to access stuff quickly from the database, and it like did that translation layer for us to make it easy to get data back and forth. It there were things that we built that were that required enough speed that we had to ditch a framework, which we don't even like to do. And then there are situations where like speed might might not matter, or the data might be kind of just like customer data or something like pretty basic. And then like maybe the thing you want to build on is your you want to build on top of your like your Salesforce or HubSpot CRM, because that's closer to the like the source of truth, right? And and you don't care about being locked into an environment. Like you're gonna be with Salesforce till the day you die. That is what your company has chosen. You're a publicly traded company, every single one of them uses Salesforce. Um and that's just the way it is. Or like you are a Microsoft company, and everything in your company runs on top of um Microsoft Dynamics, uh, and so you should build your stuff your product on top of Microsoft Dynamics. But if like if you were like a startup or you're a company that has to do something like reasonably complex, I would say a framework has a like starting with a programming language with a plus framework is a pretty good place to start, especially if you want to own the IP and you don't want to and you don't want to be locked in by a vendor. I don't know if Justin, you agree with that.
SPEAKER_02Yeah, I absolutely agree. And and you it's funny you mentioned the speed thing. I have a great example of this from like, I don't know, almost a decade ago, building something that uh was generating e-commerce um websites at scale. And and I've like this thing that we built was generating hundred thousand page e-commerce sites like all at once of static static pages. Sounds totally legit. Okay, very good. Of course, of course it is. And uh and we were using a framework, a front-end uh rendering framework that was there to essentially render out the front-end pages, um, one called handlebars, um, that is pretty pretty common. And we ran into the exact same problem where the rendering speed in the framework was too slow for what we were doing, and we had to build our own renderer from code, and it like dropped the speed by like 90% or something like that, right? Like it was just an incredible savings. Um, so it's I think it's a great call-out that the great thing about a framework is you get a lot of stuff, but like you also get a lot of stuff. And if you put a lot of stuff into a wheelbarrow, it's slower to push, right? And so that's the same thing about a framework. Um, it can slow things down in some cases. For the most part, for the most part, when you're building an app or something like that, you probably do want to start with a framework. It's just the best way to get going. But there are some other examples that you don't, if you're building just a little technical proof of concept, you want to wire up this thing to send data to this other thing that then processes it and da-da-da-da-da. You may not need a framework. You may just need to write some code to do it, right? Um, so there are definitely times, and like if you're if you're building little simple static marketing websites, right, or something like that. You may not need a framework, it might be too much to use uh for that. It just depends on the use case. It is a pretty highly dependent thing. I'd say most of the time the answer is yes, but there are definitely some of those cases where it's not appropriate.
SPEAKER_01Yeah, and then the other thing to think about is like where are your customers? That's another thing, right? So, so um if you are like it would make no sense to build outside of like, I don't want to keep going back to the Salesforce example, but like your business model might be that you sell a pro uh a product inside the Salesforce marketplace. Like that might actually be your entire business, and so you have to then use their ecosystem and infrastructure and their platform to build those applications rather than like some off-the-shelf free um framework, right? Uh because while you can theoretically um integrate with Salesforce using like a framework and like not building it inside that entire ecosystem, if you're if all your customers are in that ecosystem, there's now maybe maybe you're just making like your life difficult. HubSpot, you know, is the same way, or like maybe you want to build like WordPress plugins. Like you're gonna have to go follow the WordPress way of life.
SPEAKER_02Right.
SPEAKER_01Yeah.
SPEAKER_02You have to play in that pool.
SPEAKER_00So what about? So I've heard of using like a CMS, a content management system, um, to build an application on top of. Can you explain what situation that would be appropriate in? And uh I I've heard of these things called headless CMSs. I just picture like the headless horseman. Uh I don't know what that is, but can you explain what that is?
SPEAKER_02Very similar.
SPEAKER_00Very similar.
SPEAKER_02Almost as frightening.
SPEAKER_00In what case would I want to build on top of a CMS?
SPEAKER_02Yeah. I, you know, using a CMS is the the reason you'd use a CMS is when you want to manage the content of a website. That is the text, the pictures, the web pagey stuff, right? Um, you want to manage all of that stuff yourself. You don't want to have to call a developer to like update the about page on your website, right? Or like wait on somebody to correct a typo. You want to be able to just log in and go fix the typo, hit save, and have it done, right? And so CMS's content management systems give kind of non-technical people the ability to go in and make changes to web content and it publishes it out um to the website on their behalf. Really, really popular, especially with marketing departments and stuff like that, where you don't necessarily have that technical um um expertise in-house or at hand, or not at least something you can just get on Beck and Call, right? Um so CMS is very popular, WordPress being one of the the leaders of it. I think the last time I saw it, like I think it now powers like 60% of the internet.
SPEAKER_01I I'd guess more, man.
SPEAKER_02It's something insane. Um, yeah, very, very uh, very, very popular.
SPEAKER_01The I mean, I think the another another way of looking at that problem is what does the application do? Like if it is a behind the scenes tool that reads, that pulls information, like I don't know, like all your financial everything that has happened in your bank account, every all your purchases, and then it runs some algorithm on it, and then it like runs that through an AI thing, and then it sends you an email report once a month. Like none of that needs, none of that should be anywhere near a CMS, right? Um, that's all like in between like connective tissue code. Um But like let's say for example your application was your you had a mobile app, and that mobile app was for your um teachers union. And mainly what you needed to do is the teachers union needed to like see the news and the update and new newsletters, and so like you would probably write the app as just like a front end to your CMS because the people creating all the code and all the sorry, the people creating all the content like are the most important user in the application. They're like what's being produced. It's not like robots going and getting your bank account information. The thing that's important is the content. So building the application to interface with the content management system is like really why you would make that choice. And there's you know, like a reservation booking system. Like you want your marketing people to go in and put in all the cool stuff about the like to describe the walking tour of Venice in like this wonderful, beautiful detail and upload all the images. And the booking engine then should like pull that information directly out of the CMS. So that's when they're integrated. But you could actually theoretically build a booking engine right on top of the CMS as well. And then that would be custom code that lives on top. And so you can kind of have these blended models as well. Does it does that make sense?
SPEAKER_00Yeah, I think so. Um so like this seems like kind of an a no-brainer. Um, but what are some of the like cons of building on top of a CMS?
SPEAKER_02Well, I think you know, some of the some of the downsides is kind of like building on any other framework or any other platform, right? One is that with a CMS, a lot of CMSs, especially one that is not headless. We'll talk about headless CMS in just a moment, because that's kind of yeah, we still need to. Yeah, which is um that you do get sort of a little bit of vendor lock-in. Um, and when we say vendor lock-in, what we mean is you start using a platform or piece of software, and like it's not easy to just move to another one very easy. Like you, you, you're there's a lot of stuff that you build and do that's specific to that platform that means if you want to move to a new one, you gotta like build and do all those things again. You can't just sort of like tote it over there, right? So that's a downside. It's a probably a relatively small downside most of the time for most people, but it is still a thing. If you build a WordPress site, you are locked into how WordPress builds that website, right? And you can't just pick it up and put it somewhere else if you want to. Now, a headless CMS actually helps to solve that problem in some ways, which is that what a headless CMS does, the headless uh definitely doesn't mean like uh like like the um the pumpkin in the hand on the back of the horse, right? But um but but what it means is that when we talk about the head of a website, we talk about the thing that you see, the UI, the part that you interact with, the little drop-downs and the links and the stuff, right? All the things in your browser is the head of the website. Well, a headless CMS, so like, well, let me back up. WordPress or something like that sort of comes with that layer out of the box, right? It renders the pages for you. It puts all the code out there so you can click on all the things. A headless CMS just decapitates it, right? And what it does is it says you could put all your content in and then we'll just hand you back your content as data instead of web pages. What that means is that you can then wire that into your application specifically. This is how you actually avoid vendor lock-in to some degree because now it's a little bit more standardized. There's still a little bit of lock-in because all your content is in one platform, but you're not building like the the WordPress way. You're now building your application and then using that CMS's data to inject the content into it, which is a really great way to do it in custom software applications and other things like that, where an out-of-the-box CMS doesn't really fit all of the uh requirements.
SPEAKER_01Yeah, you're it's kind of in in some ways, it's I don't want to say it's the best of both worlds. Or you'll you'll make some make two parties happy, right? So the marketing team or the content development team is gonna get this pretty slick, very polished professional product that they get to interact with on the back end where they go and put all their data in. And then the developers get the data output that they can then manipulate into like the app or the website themselves. So they can they just get the information out. Normally, what you would see is uh well, not normally, but I mean a lot of the time what you'll see is the developers will say, Okay, I understand the problem, I'll go and build the app, and then they'll go and build some janky ass like CMS on their own, as opposed to like, I'm gonna buy like Contentful out of the box or something like that, and which is expensive, but it comes with like a billion tools that are super useful, and like data structures and uh analytics tools and re-engagement tools and all sorts of stuff that comes out of the box that you'd expect from a big powerful CMS. It just doesn't have any front end, so you can give the output to the developers and then they can present that to the customer or the user in any particular way. So um you you you kind of you kind of get to bike mo you get to make both the marketing people happy and the developers happy.
SPEAKER_02Yeah, and I think one thing that you said that I'll just reiterate there too, is that like when you when you buy a thing like Contentful, which by the way is a reasonably generous free layer and then the or level and then the paid level is is quite a bit more expensive. Um, but whether or not you use Contentful or use another headless CMS or something like that, the point is that you're using a piece of software that is probably worth millions of dollars in terms of development cost.
SPEAKER_01Yeah, yeah.
SPEAKER_02You probably do not want to build that yourself unless you have an extremely special circumstance. You probably don't want to go build a several million dollar piece of software that's already out there and that you can use for a few hundred bucks a month. You probably don't want to go build it yourself, right? Um, and that's where we are in the state of web development now, and that's why it's a really exciting time to be building stuff is because we've had such a maturity, these frameworks and these platforms that we like back in the day when we were banging in the early 2000s and late 90s. I mean, you didn't have a choice but to write this stuff from scratch. Like you had to, right? And we are in such a different era now. You can build products so much faster and in a much more flexible way using these kind of things. It's it's a great time to be a developer, quite frankly.
SPEAKER_01Yeah, it used to actually like be one of the reasons you would go to a sp particular development shop or agency is that they had the code, they owned the code for their own CRM or their own CMS. And they would, that's how they would sell you. They would say, Hey, look at us. We you don't need to use all this other stuff. We've got this out of the box. And then they were all code in this. Yeah, and there was like their whole thing, the reason for existence. And uh we're we're kind of actually coming back around to that a little bit with the AI stuff. It's like we've got our own AI framework, and ours is better than everyone else's, whatever. But um, and then I'm sure someone will come and like wipe that all out. But uh yeah, so these these were reasons to buy things. And in some situations, there are still arguments why you should build them yourself. Like you don't if you don't need if if you're if you don't need contentful, there's no reason to buy contentful because you can probably build it for you know a couple thousand dollars. And then that's fine. Like you you you build the tiny little piece that you need. But if you need all of it, that million of doll millions of dollars, there is no reason to do that to Justin's back to Justin Sport.
SPEAKER_00I'm hoping you can now explain to me about I've heard of everyone is familiar with software as a service, but I've recently learned about backend as a service, bass.
SPEAKER_02Um Yeah. Not the kind you're catching in the pollen with your not crawler.
SPEAKER_01I am not from Tennessee. I don't know what you're talking about.
SPEAKER_00Well, we have bass in Florida too, Greg.
SPEAKER_01Oh, okay. I'm sorry. Um Florida's actually one of the best I'm not from Florida either, though, so that's this is not a fake bad British accent.
SPEAKER_00This is actually my Well, you've lived here for like twenty
SPEAKER_01I know, but I haven't done like a lot of base fishing. I'm sorry, back end as a service, yeah, yeah.
SPEAKER_00So what is this? Why would I consider this for my app?
SPEAKER_01Justin, do you want me do you want me to take this? Because I think you're kind of like you've used a lot of back end as a service like successfully, right? I love them. Okay, and I've got the horror stories.
SPEAKER_00So we can this will be good.
SPEAKER_01Yeah, okay. So why don't you go first? You tell you tell your love story. Sure, absolutely.
SPEAKER_02So backends of the service is um it's like a framework for your back end, if you will, that somebody else is hosting and running for you, right? And what's the back end? What we're talking about is like the server, the functions that run on the server, the database, the authentication, all the stuff that has to happen on the server, basically. It's getting all of that stuff out of the box. So you have things like Firebase, which is a really popular back end as a service. Is another one that is really popular right now among the Next.js community and Node.js community. Um, and so there's a number of different ones. Amazon has um, what is their big back end as a service? I can't remember the name of it now. Um whatever it is. Superbase. What's that? Superbase. Oh, yeah, and superbase, which is essentially like a database as a service, right? Um, so you don't have to manage like installing it on a server. And that what you get from this is what you get to avoid in sidestep is setting up a server, securing a server, installing a database on the server, making sure the database is always running in case your server goes down, making sure that it fails over correctly. All of these problems that, quite frankly, almost everybody does not want to deal with unless you like are like thick neckbeard. You probably don't want to deal with these problems. Um, and that's all respect in the world to my dear neckbeard friends, because I have a lot of respect for you. Uh but but the point is that these are a lot of things that distract you from the job of getting the business done, and it lets you sidestep that and get to delivering value faster. I'm a huge fan. I've used them for years. Um, but I'm looking forward to hearing the horror stories.
SPEAKER_00Yeah, Greg.
SPEAKER_01Yeah, so I mean, like like Justin said, these are these are services out there. They are kind of like a framework. They do your they have your database uh in the cloud somewhere, so you never have to touch database. They have like the user authentication stuff, like, oh, you just send, you just like have one line of code that says like authenticate the user and you give it a form and it just handles it for you. And they have user management, and you don't have to build any of that stuff. And it's great. Uh in theory. I have gone through two backend of a service projects where um the back end as a service company shut down. Oh one company had millions of users. Uh, they were running on a system called Parse, which was super popular in like, I don't know, 2018, 2019, something like that. And I don't know if Parse went bankrupt, or I can't remember the details, but Parse went out of business. And so we had to lift and shift the entire infrastructure uh and the entire system to a framework-based development platform. Now, they were able to move really quickly and do a whole lot of cool stuff because these backend as a services offer a lot of functionality. You know, you don't and they some could argue that they don't know that some frameworks will give you almost as much whatever. It's that's not true. You'll get more out of a backend as a service, it's just the case. But um, what you are guaranteed is vendor lock-in. I personally like to use Google Firebase. I use it for my own personal, personal projects, right? But now I am relatively locked into the Google uh uh app service ecosystem. And uh for me, that's fine, because I don't care because I'm just some dude, right? But if I was like a publicly traded company, I would maybe think twice about that. Because uh Google might acquire a competitor of yours, or you might go head-to-head against them. And if you're in and I'm not just talking about like their hosting services, right? Because like if your servers and your databases and whatever, those are hosted at Google's um in their cloud, that's fine. It's a little bit of work. You pick them up and move them to Amazon or to Microsoft. It's not going to kill you. But what will kill you is if they decide that they're gonna jack up your Firebase price 10,000 times because they're doing you're doing something that they don't like or is they're kind of anti-competitive. And that means that everything, including your entire database structure, your schema, the way it like works, is is is is gone. And you have to rebuild it somewhere else. That doesn't mean it's impossible. We have literally done it before for people. Um, you know, like I'm I don't know if you like that meme where there's the guy and the girl, and like he's like checking out some of the girl. Like, I'm right now that way with AWS Amplify. Yep. Amplify, amplify. I've like been playing a little bit with it because I like the AWS infrastructure uh like ecosystem quite a lot and like that mix they've got some stuff that's starting to compete with uh with with um Firebase, but like we still use Firebase for app analytics, even when we built the app ourselves. Like if we didn't use anything in Firebase, the analytics is so good that we still use that. I love backend as a service, but I'm terrified of it.
SPEAKER_02Yeah, I mean, the thing is, I mean, definitely a horror story. Parse, I do remember parse. Um, and definitely like that is a thing. You do have vendor lock-in uh there, and you are making a lot of assumptions and you are buying into a way of doing things when you do that. I mean, I use Firebase for years, and I can tell you I Firebase and I had some fistfights over how their database querying works.
SPEAKER_01That's the other thing. When it they can because they're so because they are designed to be kind of like a certain way, they can be very inflexible.
SPEAKER_00Okay.
SPEAKER_01And if you need to do something like complicated or big, yeah, like this a certain point where you're like, why did I do this? I should have just built this.
SPEAKER_02Yeah, we were running a fintech app on it that in retrospect was not the best choice because of the kind of mathematical work that we had to do in the database. And like Firebase is not really set up to do that well. So um, but but that is, I mean, that's the thing is that these are decisions that you have to consider risk in. And what is the risk that I mean? Look, Parse went away. I do remember Parse. Um, you know, it's it's rare if you go with one of the big guys, if you go with Amazon, Google, what you know, one of the big guys.
SPEAKER_01It is unlikely, yeah. I agree.
SPEAKER_02It's unlikely they're going away. And the trade-off being that you can run a lot faster and you can get to market a lot faster, but it definitely is situation-dependent. You do have to manage that risk.
SPEAKER_00So uh earlier we mentioned building on top of your CRM. Um, so I'd like to now move on to that. Uh so at SourceD we use HubSpot. I'm in there every day, love it. So, in what situation would I want to build my app just on top of a CRM? Um like, is like how is that possible and why would I want to do that?
SPEAKER_01Yeah, so I mean, all of these systems, um all like CMSs and CRMs will offer what's called an API or an application programming interface, which is basically a way that you can talk to your data and your systems. Um, so you can send them stuff and you can get stuff out of them using any language. Doesn't matter what the language is, you can communicate with them. Like you can use PHP or .NET or um Ruby, whatever it is you want. Sorry, .NET, some language, but whatever. Um and so you can so that is an option. So you can have your application that lives like yeah, I don't know, you can have HubSpot living over where HubSpot ever lives, and then your app can live in like Amazon, AWS, and they can talk to each other, and you can like pull the data in, and like that can be your data store of like where your customers are, and um, and that's a really good idea, right? So, because if you're gonna send them emails, your customers are gonna send them emails, you want to keep track of who your customers are, your CRM is a really good place to do that. So, why not make it the source of truth for that as well? Well, there might be some reasons why you don't want to do that, but maybe you're purely a marketing company and you want to build something, having your CRM be your source of truth makes a ton of sense. Why have to why do you would you want to build a custom newsletter sending system if like HubSpot or Salesforce has already got that built in? There is a second, so that's one way, right? Where like the two things are separated. There are, however, like with Salesforce, Salesforce is like kind of weird, they have their own ecosystem as well, with their own like programming language that you can deploy in their cloud, which lives close to their stuff for a number of reasons that um are mainly around making lots of money, which Salesforce is very good at doing. But you can actually build the apps inside of their systems, and some of those are now becoming kind of more toward the low-code, no-code environments. So you don't have to be um a hardcore techie to be able to do this. You have to just be like a Salesforce or HubSpot expert, and you can like set up workflows, and you can probably get like a ton done. You can like build a portal where a customer comes and logs in and fills out a form, and that form then um you know creates an order, and that order is then sent to somebody, and then like they have to pay for it online. And like you have built an application. Like 100% you've built an application doing it that way. And there's a lot of really good reasons to doing things that way. It's it's it's the same thing. Once you the same problem with kind of a back end as a service, but like magnified a thousand times, which is if you want to do anything complicated, you will you will have worked yourself in to this magical place where you have like this amazing thing that's probably worth that. If like a custom developer looked at it, they'd be like, Wow, that's super impressive. You've done like a million dollars worth of work here. And they're like, and you're like, what? Like, oh no, and you feel all great about yourself. I said, Well, I want to do this like one extra thing. And they're like, Well, that's not possible in that framework. Like, okay, can you add that? It's like, no, we have to take it all out and rebuild it, and that will cost a million dollars now. So, yeah, there's tons of reason, reasons for building something on top of those platforms, lots of reasons to building them next to those platforms, I think, even better. And like they integr integrate with each other rather rather than build completely on top. Um as long as you know the risks. And sometimes you've just made your bed, like like you know you're not gonna get off HubSpot. It's just I'm gonna be too payable. I will pay them whatever they want every year, and Salesforce the same way.
SPEAKER_02Yeah, but it is similar. I mean, I think like thinking about the decision similarly to a back end as a service decision, it's like a backend as a service that just focuses on people as the main thing that it deals with.
SPEAKER_01Although I I was I was in a meeting um a couple months ago, and I heard something that did stick out in my head, which is uh I it was uh as a guy from an invent a PE firm um who had just invested in a company that had moved like out of the startup phase, and we're into kind of like early stages of like medium-sized business but in high growth mode. And um we had built the application for the guy, uh for this company as from I think when they were a startup, we took over, and like we took them all the way to and then like 20, 30 million dollar company, something like that. And the one guy said, uh, why didn't you build it on Salesforce on top of Salesforce? And I we were like, What? Why? Because they didn't, first of all, they didn't have sales, like why that's a weird question. And he said, This guy, this P guy claimed, Oh, the valuation of your company would have been 2x had you built it on Salesforce. And I was like, What? Why on earth would that make any sense? And his argument was that in their industry, in their particular field, everyone knew what Salesforce was, and as a result, it would have more name recognition. And I explained to him that I thought this was ridiculous. And being the poorest person in the room, explaining like maybe I'm totally wrong, but like there might be some strategic long-term reasons to pick something, like, especially if you're looking to be acquired by somebody in that ecosystem, whatever, then maybe building on top of maybe there's a strategic reason to do that. I find that to be a very tricky argument because it really, if you're looking for later down the road acquisitions, what you want is people to compete for your acquisition. And if you're locked into some ecosystem, that is probably the last thing you want. But then again, what do I know? I've only been doing this for like 20 years.
SPEAKER_00Uh Justin, by the way, I just noticed you have on our code naked shirt.
SPEAKER_02I do, I do.
SPEAKER_00And you were talking about neckbeards earlier.
SPEAKER_02Yes, I mean, speaking of the original neckbeard here.
SPEAKER_00Okay, well, wow, that's a lot of people.
SPEAKER_01That's why a way that's quite a way to end for a vision for an audio for an audio medium.
SPEAKER_00Well, if you see the beautiful neckbeard in question, then you'll have to find this episode on YouTube. Um, it should be easily findable.
SPEAKER_01I'm sure I'm gonna show it to your kids, Justin.
SPEAKER_00So uh this was a lot of information. There's a lot to consider for me as I'm planning out my app that I'm gonna build.
SPEAKER_01Yeah, let me know what you want to build. I'm curious.
SPEAKER_00Yeah, so uh which cat is matches your personality.
SPEAKER_01Okay, perfect. Yeah, done. Salesforce. Salesforce is the answer. Ooh, I like it.
SPEAKER_02Salesforce.
SPEAKER_00So match a cat to your personality and then maybe even connect you with ways to adopt that. Cat little shelters.
SPEAKER_02I like that. I like that.
SPEAKER_00How about that? How about that? Okay, so Salesforce. I'm building on.
SPEAKER_01Yeah, Salesforce. I think a mule soft middleware um giant AWS serverless uh backend system to like augment all this. Yeah, it's gonna be it's gonna be a couple million dollars, Sarah.
SPEAKER_00We got you so and I wanted to do really cute like Duolingo, you know?
SPEAKER_01Yeah, yeah. We gotcha.
unknownOkay.
SPEAKER_00Well, this was very educational for me. Um, I hope our listeners have learned a lot too. So just a quick recap. We talked through um when to use a framework, we talked through when to use a CMS. Um, Greg and Justin explained what a headless CMS is. Um, we talked about backend as a service, we talked about bass phishing, we talked about when to use a CRM to build your application on top of. And I'm guessing that's my that's what I'm gonna go with for my cat app. Um so uh listeners, we'd love to hear your thoughts and experiences if you've uh built software or an app and um you've made one of these decisions. We'd like to hear how that how that worked out for you. Um and thank you all so much for joining us. If you would like to cons continue getting insight into the world of software development and digital product development, then just go ahead and like and subscribe to Coder Podcast. And that's it. Until next time. Thanks, guys.
SPEAKER_01Thank you, Sarah. Thanks, Sarah.