Speaker 1: 0:00

But it's also protecting yourself in the contract If you actually just take a step back. Most of it is just logic-based it's not hard. It's actually, it's all common sense. This is what your developer's doing.

Speaker 2: 0:15

On this episode of Sell Me this Podcast, we're joined by Paisley, the founder of the Tech Translator. With over a decade of experience in tech startups and ecosystem building, paisley has seen firsthand the costly mistakes that businesses make when developing software. She's on a mission to bridge the gap between entrepreneurs and developers, helping businesses make smarter and more informed decisions when it comes to building custom technology. Today, she shares her insights on avoiding common pitfalls, choosing the right development partners and why understanding tech is just as important as understanding finance and business. Let's dive in, paisley. Thank you so much for joining us today. I'm going to dive right into things. I would love to hear a little bit about your journey and what led you to launching Tech Translator.

Speaker 1: 0:59

Thank you so much for having me. I'm super excited. I feel like I'm on Call Her Daddy, which I already told you.

Speaker 2: 1:05

Oh my goodness, I feel like this. As I mentioned, I'm not a very good Alex Cooper but I will try my best here.

Speaker 1: 1:15

So I started the Tech Translator after working in tech for about 10 years tech and ecosystem building and startups.

Speaker 1: 1:18

So my whole career I've been in that realm and I moved from Calgary Economic Development into custom software development where I got to see a different lens of how businesses grow. And I realized that even when they were my clients and I was doing everything in my power to make the whole process easier for them, they were still losing so much money and there was so much frustration and it was nothing that I could mitigate on my end, despite trying to ask them all the questions and see around the corners on their behalf. It was really hard because they just wouldn't tell you one thing. And then, six months down the line, when they get their product and their MVP and they're doing their testing like a real life scenario that happened was somebody was like why doesn't it work offline? And you're like, oh my goodness, the amount of time it would take me to explain why offline functionality is a complete rebuild. It isn't. You know more than I'm capable of right now, and so basically they had to do a whole rebuild.

Speaker 2: 2:16

Amazing. So what does? It sounds like you learned quite a bit to get you to this point. So what exactly is the work that Tech Translator is embarking on?

Speaker 1: 2:24

Yeah. So it's a course and I also do consulting around this as well, but I realized that to have scalable impact, you want something that can run in the background and bring people up to speed. So it's a course that really starts from the basics of software, from a non-technical perspective. So we use lots of metaphors like a house, we relate things to Facebook and we start from the most simple terms. You've got your front end, your back end, your server, and we're explaining what that is, and then we continue to evolve and go into some of the deeper concepts. But everything's related back to why an entrepreneur needs to know that and it's made really tangible so they understand. Okay, when I'm explaining my business to my software developer. This is why it's important that I say this, or I mentioned that this is what I want.

Speaker 2: 3:06

So do you feel that a lot of entrepreneurs, or even, like technology, people that embark on building out some of these custom applications or bringing their ideas to life, do they have a strong foundation, or do they do you think they have a pretty flawed view of what actual development processes look like?

Speaker 1: 3:22

Absolutely so, and I'm sure you see this a lot in your realm as well. But everyone walks around with these apps that they just think should work, and they there's not a lot of grace when your Facebook goes down or you can't log into something. People don't really have that understanding, and those are billion dollar companies. So then when you're building them something with a $200,000 budget, they just don't understand why it can't work or why you can't do this. And so in my course I really try to break down the man hours that it takes to build some of these things, all the different roles it takes and how that is all represented in salaries, and that's why it's so expensive. But even more than that is they have no understanding around software concepts and business logic, and I find that they defer way too much to their tech team. So they're like, oh, just do what you think makes sense. It doesn't actually matter what your project manager thinks about your horse racing app.

Speaker 2: 4:15

You know what I mean.

Speaker 1: 4:16

It doesn't matter what his opinion is. But they think everything is technical question. So you say do you want a pop-up here to confirm? Oh, I don't know.

Speaker 2: 4:25

You let me know.

Speaker 1: 4:25

We'll leave it to the technical people, yeah that's not a technical question, but they just defer so much and then it winds up biting them in the butt at the end because they've deferred all of these things. That are really business questions no-transcript.

Speaker 2: 4:48

It sounds like it has permeated over and sounds like even amplified when people are building some of these custom applications.

Speaker 1: 4:55

Yes, and I always say the number one thing.

Speaker 1: 4:58

another number one reason your developer hates you is because you say vague things or you ask vague questions. Can we integrate with Zo questions? Can we integrate with Zoho? Can we integrate with Facebook? What does that mean? Of course we can. If there's an open API, we absolutely can do it. Do you have the budget for it? What do you want it to do is the real question. So my course actually even walks you through a framework of understanding APIs, understanding the limitations, because what I think some people don't realize when they ask these vague questions, it's just like lobbing something over the fence. You're wasting like sometimes 10 hours on the tech team where they're all spinning their wheels trying to figure out what you want, and then you get a bill for a thousand dollars because and nothing's even been coded, because it's like that was like 10 hours of developers trying to figure out what you wanted, and then at the end you're like, oh, I don't actually have any budget for that. Anyways, I was just asking.

Speaker 2: 5:50

I agree completely. There's so much things, so many things that the people think are far simpler than they are and they don't understand the fundamental concepts behind them. This is probably going to be the most Canadian reference ever, but I don't know if you've seen the show Shits Creek. Oh, yeah, and there's that famous scene where it's a write-off. It's the write-off.

Speaker 1: 6:07

People will take care of it. You're stealing my meme. That was my meme.

Speaker 2: 6:10

And it's kind of like that it's just connect them. Connect to the API.

Speaker 1: 6:21

We'll link that video to the podcast Cause. Yeah, exactly, okay, that's so funny.

Speaker 2: 6:24

You've subverted me. I don't even remember seeing that.

Speaker 1: 6:26

I know that's perfect Subliminal messaging, so I'll make sure you get the credit on that front.

Speaker 2: 6:30

So when you so is most of the work that you're doing with entrepreneurs, then? Or is it with business? Is it with both? Like, where are you focused this?

Speaker 1: 6:38

that is working with a technical team. So oftentimes they are entrepreneurs trying to do something completely new, but it might be a business that's just adopting a new technology. Some of my clients are actually most of my clients are very established professionals in their trade or whatever subject matter expertise they have. They're very good at business, but then they just think all they need to do is find a software partner and their vision will come to life, and they don't realize all the work that they need to put in to understanding how their business works, how they want the software to work, instead of just outlining a few vague high-level features. So it really is a spectrum, but I would say it's mostly people who have strong subject matter expertise already.

Speaker 2: 7:21

So I'd like to break this into a couple of different pieces. So to start off with, no-transcript back a step further.

Speaker 1: 7:49

You can't even begin to search for a team and you shouldn't even start reaching out or looking for teams until you're so crystal clear on what you want. So you need to spend hours and hours with your team. You need to be doing so much validation to understand all your features, all the flows. You want all the fields. You want all the different user roles and the different edge cases If you want to close those or not, what a minimum viable product of that feature could look like, and then what your end vision is. Because once you understand that full scope, then you can decide what kind of software team is right for you.

Speaker 1: 8:22

Because if you're not understanding the scope of your own project, how do you know if you need to go to somebody a little bit more advanced or somebody that's more specialized in prototyping, somebody that does agile versus waterfall, somebody who has a more technical team or somebody that specializes in working with startups? It's just, there's so many things and oftentimes even you don't even need custom software. Sometimes, once you do that whole process of understanding your requirements, sometimes the answer is in order to move the needle, it's going to cost a million dollars. Or, now that I'm actually writing this out. This is a way bigger project than just that little app that I had in my mind and maybe it's not in my budget and you don't need to waste anyone's time. So it is a really valuable question to say how do I pick the right one? But you can't even do that until you have completely understood your scope.

Speaker 2: 9:12

There's so much work and we come across this with some of our clients as well where organizations will spend so much time and effort to make technology fit their process, technology fit their process, and sometimes if you have a really proprietary process, that's really valid. But sometimes a small tweak of the process can put you into that custom software box or out of the custom software box into something that's more off the shelf or into something that you're talking about, and it can just alleviate that all together. What are some of the other mistakes that you see organizations or leaders making as they're going through that initial evaluation? Because you've already shared like a hundred different things that are really important to consider. What are some of the other pitfalls you see some of these leaders taking as they're embarking on this initial step of the journey?

Speaker 1: 9:55

Yeah, I think so. Like I said, it's not understanding the scope of their project, but then it's also not understanding anything to do with technology. So I think there is. I think we need to put the responsibility back on the entrepreneur or the person that's seeking these services, because there's so much frustration and so much.

Speaker 1: 10:12

This software developer screwed me over or they're out to get you or they just want to make money, and so I think there is a responsibility to learn a little bit about the whole realm as well, and you can do that just through YouTube and listening to podcasts and Googling things. But I can't even tell you how many people, when I worked in custom software development, would sit in the first meeting and you'd say something like database and they'd be like what's that?

Speaker 2: 10:36

You see them frantically writing down the notes you just gave me $200,000.

Speaker 1: 10:40

Well, not me, but spent $200,000 and you don't know what a database is. That sounds like a recipe for disaster and not having the context. So I would say, understanding the process more generally, understanding your project and how that person, that technical person, is internal or you're outsourcing it, that level of communication still needs to be there Because even if you bring in a technical person, if they're not as intimate with the business as you are, you're still going to have to transfer all of that knowledge to them.

Speaker 2: 11:21

It's a real shame and I'm curious on your opinion on this is that there's such a focus on financial literacy for business leaders. There's such a focus on understanding HR policy and laws and regulations, and I feel like there's a big mess in terms of this other language that's becoming more and more important around being a business leader, which is the language of technology. Are you seeing the same things in the same way, or is this addressed? Some other avenue?

Speaker 1: 11:46

I think this is a huge gap and so, even looking at the amazing innovation ecosystem we have in Alberta, we have so much programming around startups helping you understand your client, your ICP, building out your validation techniques and how you're going to get that feedback. And then all of a sudden you've done this market research and you have a pitch deck and then you're like lobbed over the fence to either get grants to build this product but you're not equipped to actually work with the team, or you're lobbed over into kind of a gross mindset, but at no point did anyone really tell you how to work with the software development. And our innovation ecosystem is also set up to really bring people along the technology readiness levels, which I think is a really helpful framework. But I think the MVP is dying, and the reason I say the MVP is dying, which is.

Speaker 2: 12:37

I'm really excited about this because I feel like this is some fresh content here.

Speaker 1: 12:41

And it's nuanced. But I think the MVP is dying because the M has moved so far. With the tools that we have. Now there's technology for everything. Now there's platforms for everything. A lot of the big companies offer great free packages as well, so it's really hard to be competitive.

Speaker 1: 12:59

To create that next level of value and to fill that ecosystem gap is usually around better workflows or better connectivity. So now what I'm seeing is the M in minimum viable product requires single sign-on. It requires all these integrations. Gone are the days where you can prototype for a few days and be like this is my messaging app, go, use a SaaS, use Facebook like, use different things to validate the concept. But the majority of entrepreneurs that I see and work with nowadays are becoming less and less of a fit for some of the innovation funding programs in Alberta because they're not making true technological advancements. They're doing great work, but they're optimizing different off-the-shelf things like messaging and community building and the way that they're optimizing data flows, but none of that is a technical leap forward. That's optimizing it for a new environment. So that's why I say the M is now do you have single sign-on? Do you have this? Because companies won't even pilot or adopt it until it will fit into their existing kind of ecosystem.

Speaker 2: 14:02

And is that from a security standpoint? Is that from a risk standpoint, a maturity standpoint? What do you believe is driving that?

Speaker 1: 14:07

It's from, I think, a fragmentation of technology standpoint, where you see those memes sometimes it's I'm going to log into my Frogger and see my jobber, and then you have to go to Kudos and it's all these buzzwords and you have 90 different systems to manage your daily workforce.

Speaker 1: 14:23

And so I think companies have hit that inflection point where there was a rush to adopt all these cool things and then they started realizing that none of them were getting used because they didn't talk to each other. And now they're trying to streamline and the companies that are coming out on top have more integrations, and that's where we're seeing AI is really able to leverage these data points, and then, but AI can't do its thing unless everything's connected right. So I just think that people don't want a hundred fragmented systems. So even with my own startup, or the startup that I'm heavily involved with, team care pal, it's been hard to get certain users even to pilot us because we don't connect with their electronic medical record system. So the M in that situation is way out of left field now because you have to integrate with an EMR.

Speaker 2: 15:13

And once you're talking to the EMR language and you're connecting to some of the security, the regulatory compliance, like all of those it opens up, like those are not $10,000 investments to get to that point, exactly as you probably know.

Speaker 1: 15:25

Thankfully, the EMR that's more common in our ecosystem is a private one.

Speaker 2: 15:29

Okay.

Speaker 1: 15:30

It's very hard to get into. But yeah, it's like how do you create that minimum viable product when their benchmark for minimum is? Do you have all of these things?

Speaker 2: 15:46

all of these things. So, on the topic of MVPs, then, what is your take on a lot of these different AI platforms and tools that are essentially creating these fantastic front ends? And I'm sure you've seen some of those demos where someone plugs in a paragraph long prompt and all of a sudden they have a functioning application. How is that impacting the development cycle? Is it helpful? Is it hindering things? What's your perspective on some of the evolution of these platforms and how they're driving the creation of some of these front ends? I'll call them.

Speaker 1: 16:09

Yeah, that's such a good question. It's something I've been giving a lot of thought lately. I've played around with a few of them and they are not as simple as they seem in the videos ever. For the most part, those are more technical people. I've even looked at Bubbleio as one of the best and most. It's like the WordPress of no code.

Speaker 2: 16:27

Right.

Speaker 1: 16:27

And you still have to understand database structures. You still need to store the information somewhere and then call it back in different fields and different front ends. Like you still have to have a fundamental understanding of how databases are structured. If-else logic, there's no way around that ever, because you need to generate the prompts in the way that speaks that language. So I think that those tools are amazing, but it's like the advent of WordPress, where we could all now build a website pretty easily, but you're still probably going to hire somebody to do it and it might be faster for them and cheaper than hard coding it.

Speaker 1: 17:03

But I still think for most of those low code tools and those prompting tools, we're still quite far away from a true layman's person using them, and the only way to actually get to a point where we can use them is to understand all of those things. But I did play around with Bubble and I was trying to build an MVP for something and just see if I could. Just to see if I could do it. I was like this is a lot of work. I actually don't. I don't care enough. I'm going to hire somebody to do this.

Speaker 2: 17:26

I've tried the same thing myself, so with bubble, and it's a great platform and I would consider myself in the bucket of like technical enough to be dangerous. So I understand some of the logic, I understand some of the frameworks. If you hire me to develop your application, you would ran into the exact same feeling where I was like, okay, I played around with this for an hour onto the next thing. I had nowhere near a functioning anything and it was fun. It was. I learned some things, but it's not quite as designed where you see the person on the keynote plug in the sentence in a very curated environment, very curated, there's still a process you'll have to do.

Speaker 1: 17:59

Ai will never, ever get to a point where you don't have to prompt it, Like there's something in your head Somehow. You have to tell the computer that. But I'm also a product manager and I just I'm working with a client right now and it's funny because I haven't done this type of documentation in a few years and I was like really coming back to me all the if-else statements and the if-thens and all of these things. But if you don't understand how to build out those decision trees, user roles and those types of things, how would you prompt a computer to do that? And I think that's something that I really focus on in my course is the really little details that you miss.

Speaker 1: 18:38

So even something like build me a newsfeed there's a thousand variations of that Even something as simple as why doesn't the image? When I hard press the image, why doesn't it pop up and have a native control to save to device? You had to have said that at a certain point. Whether it's you're telling the computer in the mystical future, where you can just build an app by saying those things, or you're telling your developer, there's a way that's built and that's not going to be standard unless you flag those things.

Speaker 2: 19:05

I don't think people put enough importance on the non-sexy cool stuff in the background all of the data layer, all of these things in the background, and it's not just an application development. I think the same thing comes when you start to have that broader AI conversation, where they want all these super interesting results at the end but they don't want to put in that legwork up front. That says, okay, I'm going to do X, y and Z to map out our environment. I'm going to do these things to map out decision trees and logic and where things are and how we want to communicate.

Speaker 1: 19:36

And things still need to be structured in a way that you can feed it to the AI, and I think that's what people miss. Oh, ai can do anything it can, but what in your business has been structured to collect the data and attach it to the right entities? And, as we're talking, people listening are probably already opting out If else databases, structure, roles that probably just seems so hard.

Speaker 1: 20:00

They're fast forwarding to this part. It's not hard, it's actually. It's all common sense, and I have no formal tech training at all. I learned it all through osmosis and learning on the job. But if you actually just take a step back, most of it is just logic based. How would you ever report on something if you haven't asked for it somewhere else? And it's just little things like that. Okay, you want to understand the gender breakdown of your users? You need to ask gender breakdown in the field there.

Speaker 1: 20:26

Okay, a topic that I talk about with my clients and when I'm talking to entrepreneurs is CRUD, and that's the basic of everything, and I think that knowledge goes so far. So CRUD create, read, update and delete and you need to think about that all the time. So even yesterday, I'm sitting in a meeting with a client and it's a complete system I know nothing about. It's a new client, I'm just starting with them, and so I'm blindly trying to lead this scoping meeting. But all systems are basically the same, right, and you're able to ask probing questions. So they said they wanted to add a field here. Okay, so we're creating it here. Now, where are all the places it needs to be read? Does it need to be read in the reports feature? Does it need to be read in what you're sending to the client, to their report? Does it need to be updated? Does it need to be deleted or archived?

Speaker 1: 21:18

And even that framework is so important because so many times, developers will build things and they don't give you the ability to update them or delete them, which is fair, because, unless you asked for it, building that out for every single thing would be. You know, that's an enterprise level solution. So I would say, typically, entrepreneurs, if you have a $200,000 budget, you're going to get about 25%, right, but then they're like what? I should just be able to edit this? Well, yeah, but that's a whole nother screen, that's a whole nother pop-up, that's a whole nother API to actually update the database and then update the place that it's being shown over here and all the different things. I just think some of those fundamental pieces. It's logic, but once you have a framework, anyone that's not technical can use that now and just be like okay, I've created it. Where do I need to read it? Do I need to update it? What would that impact? What screens do I need to delete it?

Speaker 2: 22:12

So you bring up a really good point. Even, I think, around people not really understanding what goes into everything, not understanding the effort required to actually deliver certain components, and so if they're starting to take you know they let's say that they've gone through that exercise. They've asked some of those questions you identified at the very beginning. They found the right partner. They're starting with building out something. How do they get a sense of even what that destination is? I love to use the analogy no one ever wants to go on a road trip if you don't know where you're going.

Speaker 1: 22:39

Right.

Speaker 2: 22:41

But how do they start to visualize the destination, knowing that so many decisions have to be made along the way? It is an iterative process, but what advice would you have for them at that stage of their journey?

Speaker 1: 22:51

Like how do they understand what their product? Needs to look like kind of thing.

Speaker 2: 22:54

Exactly.

Speaker 1: 22:55

Yeah, I would say it really. I do my best work in spreadsheets, so I just put a tab for every feature to start with and then I just map out exactly what I think that will look like and for every feature. So, for example, in Team Care Pal, it's a very featurerich app. I think we have nine key features that are all interconnected, so it's quite a big app. But when we're first building that out, we have a tab for each one of those features and then, when we're looking at newsfeed, I went and I looked at 10 different newsfeeds. What do I need? You need to define everything, right down to the looking between Facebook and LinkedIn. The way you even something is different. One has an option of five different emojis. Linkedin has now adopted that, but Instagram you just like. Do you want it to show just the number of people who have liked? Do you want it to show two names and then others? Do you want it? What should those two names be? Are those the last two that liked it? Are those?

Speaker 2: 23:51

the highest follower count.

Speaker 1: 23:52

There's all this logic that you need to keep digging into.

Speaker 2: 23:55

And sorry I was getting deep here. No, but there's a level. That's the kind of thing you need to define.

Speaker 1: 23:58

And so if you can start doing that, and then, once you have your ideal, then scale back and be like, okay, we don't need five like options in the beginning, do you know what? And then it will slowly build Once you have your very end and I keep hitting my mic, it's going to sound weird.

Speaker 1: 24:14

It's okay, we've got a damage deposit Once you have the whole app built out, then you can start breaking that down and chunking it into version one, version two, version three, because you're never going to get it all at once. But then you can start to say what is like maybe I don't need hard press to save at the beginning, or I don't need some of those native controls, and then, once you have that, then you take it to an app developer and then you can get really good quotes because they'll be comparing apples to apples. If you just take your 10 features with a list, you're going to be getting the most high level quotes and none of them are going to be accurate and you're probably, just due to psychology, going to go with the middle one, but it's probably going to be way underscoped.

Speaker 2: 24:52

And is that where you get into kind of change request, purgatory and all of that kind of fun stuff or not so fun stuff?

Speaker 1: 24:57

Yes, because it goes back to thinking about create, read, update, delete when you're building out that process map, and a lot of times they'll say okay, so this is where the number one bit of frustration comes from. I just paid $200,000 for this app and you're telling me you're going to charge me $5,000 more if I want to be able to go in and edit the headings in the back end to show new ones on the front end. Yeah, because you never said you needed to update those, so they were hard-coded and now we need to have a mechanism to update that, or it's those types of things that they think should just be obvious. But it's not obvious because developers work on cards and I even explain stuff like this in my course. Peek behind the curtain with me. This is what your developer's doing. He's assigned a card. It says put in these headings and this report, and it doesn't say anything about edit it. So he's just-.

Speaker 1: 25:52

He follows the instructions, does the instructions, and so if you didn't say it, how would they know? But the more depth you add, the more man hours it takes and the more the cost is.

Speaker 2: 26:02

Yeah, and so I can see how, even from a if you don't understand it how it could be frustrating. Like 200 grand is a lot of money, especially you're going out, you're venturing and if you feel like you're getting something, it just comes down to communication or gaps in expectation there.

Speaker 2: 26:15

The question that I keep coming back to is, as you, you went through your spreadsheet, example, and all the different things, the likes, the comments, et cetera, et cetera. How on earth does someone even know the right questions to ask, to be? And maybe the answer is your course. But like there's so many questions and so many variables that it sounds like are really important to consider in advance of approaching these vendors. How do, how does someone even possibly get that list to know? Where do I have the right questions?

Speaker 1: 26:44

We are living in the future.

Speaker 2: 26:46

We have chat GPT in our pockets.

Speaker 1: 26:48

I think there's a couple of things you can do. Is there's some good prompts you can do on ChatGPT? If you're saying I want to build a newsfeed, give me so. Once you've looked at all the different variables and you've tried to define as much as you can for logic, then ask ChatGPT. Give me 10 edge cases around how users might use. And an edge case for those who don't know is something that doesn't follow the desired user path.

Speaker 1: 27:14

And an example of on Facebook that might be somebody uploading a video that's too big. They would have kind of parameters of how big the video can be and the edge case would be somebody tries to upload a 19-hour video and it throws an error, or maybe the site crashes because it doesn't even know how to handle it. You want to understand edge cases and see if you want to close them, like, maybe in that case it just does a pop-up Sorry, your video's too big. But you might also just want to. There's different ways that you could address those. Basically, I would say go into ChatGPT, tell them a little bit about your feature and then ask it for edge cases. Ask ChatGPT. What are some considerations I should have on the UI? What are some considerations I should have in different pieces of this and it'll just start to give you some ideas and I've used that pretty successfully.

Speaker 2: 28:00

And I didn't even think about that, but the availability of a lot of these AI tools can be an ally on your side as you're working through these different processes.

Speaker 1: 28:08

Yeah.

Speaker 2: 28:09

So then when you start to actually work with some of these developers, you hear so many horror stories of the first couple of weeks were great, it seemed like we were on the same page. Then all of a sudden things start to go downhill really quickly. What are some of the common mistakes founders or business folks or IT folks make as they start to work through these projects and kind of start to bring them to fruition?

Speaker 1: 28:32

projects and kind of start to bring them to fruition.

Speaker 1: 28:33

Yeah, they're not providing enough clarity, which I think I'd beat to death, but it's just again not saying what do you think Do what you think makes sense, because it'll never make sense.

Speaker 1: 28:39

They do not know your business and I have so many funny examples of that.

Speaker 1: 28:42

But, yeah, it's the clarity, but it's also protecting yourself in the contract and it is having somebody, I would say, on your roster and even introducing this at a very early stage to tell the software company, when you're doing that contract is I want the right to have somebody to come in and audit this and also understand the level of documentation that they're going to do and have some of that written in the contract, because documentation is not standard and I think more people think it is standard but it takes a lot of time to document, time that they need to charge you for.

Speaker 1: 29:14

So you want to have in your contract level of documentation that will be provided and sometimes it's none because you don't have the budget for it and you're just moving fast and agile. But you also want to have things like where the code needs to be stored and what language needs to be used and what framework needs to be used and what language needs to be used. And what framework needs to be used Because sometimes software development companies will recycle old projects and you'll end up starting a project with a lot of technical debt and you'll start seeing bugs right away.

Speaker 2: 29:42

I didn't even know that was a possibility. People would steal someone's code from someone else or an old project and just to get a head start. Is that kind of a?

Speaker 1: 29:48

It's a pretty common practice to use libraries. So let's say you're either using a publicly available library to build a chat feature or you've built so many chat features that you have this framework that you're using constantly. But if you have two kind of similar projects, you might say, hey, we could reuse a lot of that old structure and slap new UI on it, which is actually totally fine as long as the code base has been updated. It's when they're trying to resell something that was built two years ago on a lower framework and now you're going to be adopting a lot of that technical debt. So have framework numbers in there, have the language that needs to be coded, have that you're allowed to do spot checks. Because the other thing is oftentimes companies won't allow you into your AWS for a good reason because if you mess anything up, they have to pay for it, or they have to fix it and you'll need to pay for it, and that just creates a difficult relationship, some of that friction?

Speaker 2: 30:40

I've been asked this question before and I do not know the answer to it. Do the languages, like I know they have, use cases, but how do they matter as a technical founder or a IT person? Does it matter to them what language they use? Or how does someone even make that choice?

Speaker 1: 30:51

It shouldn't really matter what language is being used, as long as it's a popular language that you can find somebody to take it over. So they're in custom development. There's some more prominent languages and there's gonna be some really obscure or older languages, and they're pretty much all fine unless your system is like a mega system. Some are gonna be a little bit more efficient for certain things. I'm not the most technical person in the world, but there's certain things that are just the way you write. That code is a little bit more efficient and it's faster, but it's so nominal it doesn't really matter unless you're Google or Facebook. But those systems are so old Some of them are written on really old languages anyways.

Speaker 1: 31:28

But yeah, it doesn't really matter. But you should do a quick google search to understand are other people using this language? Because if you ever can't stay with that company, you need to find someone to take it over, and I have found some clients who have gone with companies that promise they can build faster than their competitors because they use their own internal framework. That unless you're taking a very calculated risk because they're going to do it for so cheap that you don't mind redoing it, stay away from that because you're not a very calculated risk, because they're going to do it for so cheap that you don't mind redoing it. Stay away from that, because you're not going to be able to find a new developer to take it over and they might own the rights to that platform and you might not be able to take it with you.

Speaker 2: 32:03

When I was in a conversation with someone the other day and I'm really curious on your perspective on this around that idea of build cheaply, test the market and then rebuild. But there's so many actual practical challenges with that approach around. Let's say you've onboarded a couple of users and test users. People are giving feedback and all of a sudden they're starting to pay you for it. It's not quite as simple as we're going to take it down and just hold on while we spin up the new one.

Speaker 1: 32:28

Yeah, that is a strategy that Team CarePal tried, and I think it's exactly what you're saying is, we had thought we'll rebuild. We went with a smaller company. They've been great, but we just thought we might outgrow them and we'll do a MVP and then we'll move on. But, exactly like you said, you're, you have a lot of customers on board, you have a lot of data in there and the customers are constantly asking for new features. So even though you think, okay, I'm done, my MVP was cheap, you can't actually usually sell your MVP. So you're constantly making changes to adjust to the market and to adapt to user feedback and all of a sudden, this trial system is very expensive and hard to get away from and usually it's going to take you six months to build that new system. So either you have to stop development on your new system completely waiting for the new one to be built, or you're literally throwing away money because this client says I can't use this unless you do this thing and everything's a couple thousand dollars.

Speaker 2: 33:25

Yeah, everything costs money and everything costs time. Yeah, so that brings me into my next question, which is really around the sustainment of everything. So you have these partners that have been along with you for the ride, but are most of the engagements that you're seeing people set up for these types of projects do they have a finish line? Or when do they start to transition into maintenance mode? Or do they never transition into maintenance mode?

Speaker 1: 33:47

Usually the end game for the software company is to get a maintenance contract because that's often how they make their money. Those builds can have really low margins because things always go wrong and so the initial build can be lower margin for them. But if they can get a lot of maintenance clients, that's helpful for them to have that reoccurring revenue. I often see that's where the relationships devolve, because everything is a change order and those hours are used up very quickly with bugs and a lot of founders are like you built this.

Speaker 1: 34:18

I paid you to build it and I'm paying you to build to fix the bugs. And my friend Seth and he's the president of Corridor, a custom software shop, he's I wouldn't have a job if code didn't have bugs.

Speaker 1: 34:28

I wish we could build it and it would have no bugs forever, but then you wouldn't need software developers, really right? You also have to remember that your product is living in a living environment, and so if it's connected to APIs, or if your phone updates, or if the browser updates, all of these things could cause bugs.

Speaker 2: 34:46

Right, it's not just your system, it's all of these things that are around it that connect into it that the information goes back and forth. Yeah, it's all of these things that are around it, that connect into it, that the information goes back and forth, and it's. Yeah, there's no longer, and I'd be. I'm sure there are many examples of this, but there's not too many applications that just stand by themselves, that don't talk to anything else exactly like your calculator app is one that's.

Speaker 2: 35:04

That's about it and even I don't. The new ios update there's a. It's much more advanced than it was as well, which is very exciting, yeah, I that.

Speaker 1: 35:11

I can't believe they kept that calculator app the same for as long as they did.

Speaker 2: 35:14

Yeah, very limited upkeep on that one.

Speaker 1: 35:17

Yeah, so I definitely see. If the relationship moves into this maintenance mode, that's when there starts to be even more friction, because you're like this should have been part of the initial build, I shouldn't have to pay for this. But you do have to remember all of that is attached to man hours. The other thing is the software company wants to make you happy. So if you're giving them, if you're asking them for these changes that are out of scope, they might give you a few of them. But then when they see the spend hit this threshold, even if it was in scope, the answer has to be no or they have to recoup it at some point. So sometimes they give you these little things along the way and then a mistake is actually their fault and it's hard to get them to pay for it because it's no matter who says yeah we like.

Speaker 1: 36:01

They're a business right.

Speaker 2: 36:02

And I've seen this as well in a lot of kind of larger corporate service agreements where you know, sometimes people as well do in the right things and inadvertently reinforce the wrong behaviors and so they might them saying yes to these things out of the goodness of their heart. They have a great relationship. They want to do the right thing for the customer Sometimes leads them down these weird path where either it creates this weird expectation to what you're saying they take a shortcut because they're doing it outside of the process, so maybe they don't QA it properly or maybe they don't take some of the steps.

Speaker 2: 36:30

That things would usually happen when it goes through this usual rigor, but sometimes, in doing the right things, it actually creates these horrible outcomes.

Speaker 1: 36:38

Yes, absolutely. And yeah it's hard to explain that to a cash strap founder that you, you asked for this. I gave it to you. That cost me 30 extra hours of dev time. Now that you're saying this is the thing you really need, it's yeah, you've used up your goodwill. And then the founders I wouldn't have done that if.

Speaker 2: 36:58

I knew.

Speaker 1: 36:58

And it's. We wouldn't have done that if we knew we were just trying to be nice.

Speaker 2: 37:01

Yeah, so I want to pivot a tiny bit towards Pivot.

Speaker 1: 37:06

Yeah, like that, ross.

Speaker 2: 37:08

I'm afraid to make meme references, because I feel like I'm going to steal one of your memes inadvertently again here.

Speaker 1: 37:12

I do use the Ross one a lot, me and the founder of CarePal. Cindy, send it to each other all the time, that's well used it's in your favorites there just to copy and paste.

Speaker 2: 37:22

A lot of the work that we do and a lot of the people listening are on the corporate side of things, and so I know you're incredibly involved in the startup community, the innovation community here in Calgary, and I have this love for the startup scene in Calgary and this innovation community. It's incredibly inspiring. It's quick, moving, things are happening, there's an energy around it and I feel like sometimes there's such a contrast to the corporate side. I don't know if you see it the same way, but do you do most of your work on the startup side or are you working at all with kind of corporate customers that are trying to adapt some of those more agile, startup-esque principles?

Speaker 1: 37:59

Yeah, most of my clients are startups or they're mid-sized companies that are adopting a new product.

Speaker 1: 38:06

I usually catch people as they're building out a new product, but I do product management as well for larger companies, so I have dipped my toes in that water, but I think it is so needed and so I think it's the same principles that if you're a mid-level manager, if you're an HR person, if you're if you're anybody working in a tech company, you should understand these terms as well and you should understand the basics of software, because everything is a software company nowadays, or you might have a dev team, and I think these principles are the same everywhere.

Speaker 1: 38:43

And I think I mentioned to you that somebody on LinkedIn commented and I don't think they're a startup, but he was saying oh, hearing you say front end and back end. That was the first time I've heard those explained. And then the next day somebody asked him to hire a front-end and back-end software developer. So he actually knew what that meant. And it just shows the disconnect that a lot of these people who have very high-level jobs in these organizations might not know those basic terms. And it's what could we do and how much more efficient could those companies be if there was just more understanding.

Speaker 2: 39:13

I could not agree more was just more understanding. I could not agree more. Most of the work that I see and a lot of the innovation that I see being driven in some of these larger corporate environments isn't coming from IT. It's coming from their marketing, it's coming from their revenue engines, it's coming from HR and operations and all the parts of the business and sometimes and I probably shouldn't say this, but sometimes IT is the one actually slowing things down.

Speaker 2: 39:50

And so I agree with you wholeheartedly that this language of how do you make some of these ideas come to life in a technical capacity is a language that needs to be learned, not just in IT, not just from the technical founder, but it needs to be like French. It needs to become part of the common vernacular across organizations, because they need to be able to communicate in ways that can make their organizations digitally forward 100% and it's just like it's 2025.

Speaker 1: 40:04

We all should know these terms. Like you said, that should be common and they should also understand the players on each of the software team. I think that would be a really great step forward. My dream would be for everybody that works in any sort of tech company, no matter your role sales or HR I want you to know what the nine or 10 common roles are in a software company. I want you to understand the salaries ranges of these people. I want you to understand how much of their time goes into building a product, and then the process and some of the basics of how software works, because that's where you get to build some of this empathy and understand why things are taking so long, why they're so expensive. It's not just lobbing things over the fence to your product team. It's like having that true collaboration and empathy.

Speaker 2: 40:49

Love it. I feel like we probably could talk for another four or five hours. This entire conversation zoomed by and I just I want to thank you so much for coming today. Before we leave, there's kind of two things I want to dive into. One final word of advice for anyone listening outside of Take your Course, which I feel like is implied, but a final word of advice for some of these folks that are interested in learning more about this.

Speaker 1: 41:12

Be super curious. Leverage ChatGPT and other LLMs. You can ask so many good questions. Google top 10 software terms. Throw them into ChatGPT. Ask it to give you a metaphor. Ask it to bring it down to a grade two level. There's so many ways that you can get this information for free and just be really curious. If you hear a term, google it. If you don't quite understand it, ask someone. I just think the more technically literate we are, the more we can all work together better.

Speaker 2: 41:40

Amazing. And if people want to become even more technically literate and they want to either connect with you, learn more about you or your course, what's the best way to get in touch with you?

Speaker 1: 41:48

You can follow my LinkedIn page, the Tech Translator, or just send me a message. Reach out to me directly. I'd be happy to chat.

Speaker 2: 41:54

Awesome. Well, thank you so much, paisley, and really appreciate the time today. Thank you, and this was a blast. Thank you so much yeah.

Speaker 1: 42:00

Thanks for having me.