Summary
In this episode, Rob and Michael discuss the importance of using AI safely and choosing mobile at the right time. They interview Angelo Zanetti, a guest with extensive experience in AI and development. The conversation covers the benefits and risks of using AI, the role of senior developers, and the importance of planning and human judgment in building products with AI.
Detailed Notes
The episode starts with an introduction to the topic of using AI safely and choosing mobile at the right time. Rob and Michael explain that AI can be a powerful tool for developers, but it also requires careful planning and human judgment to avoid causing harm. They interview Angelo Zanetti, who shares his experience with AI and development. Angelo explains that senior developers are essential in using AI effectively and that planning is crucial when building a product with AI. He also emphasizes the importance of the human element in translating an idea into code. The conversation then shifts to the topic of web applications versus mobile apps. Rob and Michael explain that web applications are often easier and quicker to build than mobile apps, but that mobile apps have their own unique benefits and challenges. Angelo shares his experience with building mobile apps and the importance of considering the costs and complexities of mobile development. The episode concludes with a discussion of the role of AI in development and the importance of finding the right balance between using AI and human judgment.
Highlights
- AI can make developers more efficient, but it can also cause harm if not used correctly
- Senior developers are essential in using AI effectively
- Planning is crucial when building a product with AI
- Founders should consider the human element of translating an idea into code
- Web applications are often easier and quicker to build than mobile apps
Key Takeaways
- AI can be a powerful tool for developers, but it requires careful planning and human judgment to avoid causing harm
- Senior developers are essential in using AI effectively
- Planning is crucial when building a product with AI
- Web applications are often easier and quicker to build than mobile apps
- Mobile apps have their own unique benefits and challenges
Practical Lessons
- Developers should carefully consider the benefits and risks of using AI in their projects
- Senior developers should be involved in the planning and development process to ensure AI is used effectively
- Planning and human judgment are essential in building products with AI
- Web applications can be a cost-effective and efficient way to build a product
- Mobile apps require careful consideration of costs and complexities
Strong Lines
- AI is a tool, not a replacement for human judgment
- Planning is key to using AI effectively
- Web applications are often the best choice for building a product
Blog Post Angles
- The importance of using AI safely and effectively in development
- The role of senior developers in using AI effectively
- The benefits and challenges of building mobile apps versus web applications
- The importance of planning and human judgment in building products with AI
- The potential risks and benefits of using AI in development
Keywords
- AI
- Development
- Web applications
- Mobile apps
- Planning
- Human judgment
Transcript Text
Welcome to Building Better Developers, the Develop-a-Nor podcast, where we work on getting better step by step, professionally and personally. Let's get started. Hello and welcome back. We are continuing our season of Building Better Foundations. This is the Building Better Developers podcast, also known as Develop-a-Nor. We are in part two of an interview. I'm going to be speaking with Angelo again here in a few moments, but first, I'm going to introduce myself and let somebody else introduce themselves. A little cliffhanger there for you. My name is Rob Brodhead. I'm one of the founders of Develop-a-Nor, also the founder of RV Consulting, where we help you sift through your technology junk drawer and build a roadmap for success, leveraging technology and making it work for you instead of maybe even against you. Good things and bad things. A good thing would be, I am like, the tools that are out there to do our work are phenomenal these days. The things that like, it's funny when I would think back to when I was starting out my career and how slow and ponderous some of the compilers and things were and how long it took to deal with them. It's like, you know, you could go like have a whole meal before you got back and your code was actually compiled so you could test your latest changes. Versus now, you can test entire applications in a day basically with some of the tools that are out there. So loving that. The downside of bad things is like, there are just not enough hours in the day still because with the ability to do more, there is more that I want to do and it just seems like my, the desire to do more is constantly outpacing the ability to get some stuff done. But right now I'm going to pause, I'm going to go get some stuff done while Michael introduces himself. Hey everyone, my name is Michael Milaj. I'm one of the co-founders of Developmenter. I'm also the founder of Envision QA where we create and test custom software that solves your problems. Good thing, bad thing. Good thing, similar to Rob, there's so much out there helping us improve on our jobs and businesses. When we're recording this, it's nearing the end of the year. There's some actually some new updates to some of the versions of Java Spring Boot that just got released and I'm going to be digging into those. A downside, similar to Rob, the more these tools speed things up, the more we want to do and we still just run out of time to get stuff done. Yeah, life is, it's just the more, the more things change, the more they stay the same. The more it's just like, yep, I still just don't have enough time to get the crap done. I just, whenever we get, we're more productive, but now we just put more on our plate to get done. But right now we're going to take a few things off of our plate, mostly the stepping into the next portion of this interview. And here we go back to our conversation with Angelo. I do want to like, I guess shift a little because you've been doing this for quite a while. You've been doing development and now even though you've gotten out of it, how do you see, like especially because now you've been through, I think a couple of the game changing moments of things that have like apps have come out since you started. And before that it was, there's the web was it's what it was. And then you had the applications and you've had, now the latest is obviously AI has become a big part of development. But even you can go back a few years and the code generators basically came back. So a lot of IDs, a lot of tools were already even before AI was kicking in. We're doing a lot of that generation. So how have you, how do you see, especially like, I guess this latest wave of, you know, the latest silver bullet of AI, how do you see that and how do you see it impacting your development teams and moving forward? I think it's helpful. I think that it can make developers a lot more efficient, but it's also a very powerful tool that if you're not an experienced developer, it can actually cause more harm than good. Yeah, I posted, we've got like a few chat groups on our, with our business. And then someone sent me a little meme or something like that where I think it was cursor where cursor by accident dropped, you know, this vibe coders database. And then for those of you who don't know what drop means, it basically deleted the whole database and recreated it. And he asked cursor like, did you just like delete my database? And cursor was like, yes, I'm sorry. I had to delete it because of the database changes, but I'm sorry. What I should have done is I should have asked you, do you want me to drop the database and recreate it? And so it's powerful. Like they really are powerful, these tools, but you really need to kind of know what you're doing. But it can definitely make you more efficient and it's, you know, it learns your coding style and it can, you know, obviously auto completion, as you mentioned, has been in the ideas for, for a long time. But I think it's like even more powerful now, like this cursor and other tools where it can do multiple auto completions in multiple files that aren't even open. But that's also where the danger can come in because, you know, you kind of, you need to know what it's doing. Yeah, so I think it's a tool. You've got to use it. You've got to embrace it, but you also got to be wary of it. Where it's going to go in the future. I'm not exactly sure. You know, is it going to replace developers entirely? Possibly. But I think there's a lot of still a lot of value and experience in terms of dealing with people, what their ideas are and sort of thinking and reading between the lines in terms of, OK, this is actually a tool. OK, this is actually what they need. And this is how we need a bullet. And this is what we need to consider for the future based on previous experience. So there's still that sort of human element of translating an idea into code and into a vision, but also making it scalable and robust and future proof. So I think that's where there's the seniority plays a big role and experience. But maybe this sort of simple tasks, you know, will will sort of be maybe a little bit more automated with with AI and with code generation. So along with the lines of AI these days and like you said, having like senior developers in that and leaning on the developers to help you build the applications from a founder's perspective. However, being a founder, if you aren't really technically inclined, how do you kind of structure that? How do you think through that to avoid wasting time, wasting money and kind of like we started early on building things that don't scale that have too many features in it? It's a good question. It's like building a house, right? You don't just start putting in a foundation and start putting up walls and windows and things like that. You actually start with an architect. So I think planning is still really, really important. You know, thinking about your product, scoping it out properly, defining it from a technical specification point of view, thinking about the different scenarios, different user journeys, the different exceptions. And I think that is a very, very good step. But I think it's also overlooked. And I think people just want to build quickly. But then you kind of rush stuff and you haven't thought about, you know, knock on effects. So I think that the planning, you know, scoping, specifying phase is really, really important. And because it's not so tangible, it's often undervalued. But I think that is key to the success of a project. And not only in the initial MVP, it's the key to the scaling, you know, scalability, which I spoke about earlier in terms of scalability, in terms of features and in terms of data. So thinking about that upfront, you know, what is it going to look like in a few years time? Is it going to are we going to have like multiple payment gateways, multiple payment options, are we going to have multiple languages? Are we going to have a loyalty system? Is it going to be gamification? Great. If those are sort of things that we need to consider, let's make provision for them now. And then what does the data look like? You know, is it going to be like millions and millions of records? And at what point does the database slow down? At what point do we need to kind of archive data? How are we going to handle that? So, again, that happens, you know, ideally upfront as a best practice. But in, you know, often, you know, things need to get a market quickly and that step is skipped by founders or they just don't even know to do that. You know, they just think you need to write the code. You know, they don't even know to plan it. And it's almost like you need a systems analyst or a architect to kind of go, let's go to the drawing board first before, you know, let's write code. Because if you speak to the developer, they're probably just going to start writing code. They like that, you know, maybe senior ones will plan it a lot better. So expanding on that just a little bit. So from a founder's perspective, I believe earlier you mentioned lovable. What are some tools that a founder could use to help them wireframe besides just, you know, writing it out on paper, putting it on, you know, a PowerPoint, something like that? What are some good tools that they could use to kind of build their idea or kind of wireframe their idea and get like clickable demos without having to really write code? Yeah, so obviously you've got things like Figma, but you need to be a you've got to need some design skills for that. I think there's a platform called Relume. I speak under correction, which basically allows you to, you know, to kind of prompt and create wireframes that, you know, can become clickable prototypes. We haven't done that much work with the reduced plate around it, but I think that's that's sort of something that a non tech founder could use to create some, you know, some screens, some user journeys, some process flows, some clickable prototypes, and then, you know, use that as a base to design and build the rest of the product. Those are some very good examples. Just one other follow up here to that even. So when dealing with founders and, you know, I've run into this over the years and kind of curious what your experience is. When you have an idea and you are like, hey, I want to solve this problem. Yes, you can just go out and try to look for that problem on the Internet. Are there any focused approaches that you could offer our listeners to help them kind of narrow their focus on how to do product marketing to determine if their idea is a good for a mobile app? I'd say in a slightly different way. So where we've seen a lot of success and also just speaking to other, you know, dev houses and other tech founders. I think there's a lot more success when someone comes from a certain industry and they know that industry sort of inside and outside. They've been in the industry for many years and they've seen a niche or niche, you know, a problem and they've seen it over and over again and it's not getting solved. And then they they they create a solution around that, as opposed to me going, well, I think that the restaurant industry has got this problem and it's my hypothesis and my theory. And then I need to go and validate it. I think that's quite difficult. I mean, it's not it's not to say it's it's it's not possible, but I think you have a lot more success with the founders off from that industry, whereas they kind of trying to solve problems for an industry that they they're not based in. I mean, kid to hear your your takes on that and your experiences on that. I don't know if you have any, but, you know, maybe it's contradictory to mine. That's actually kind of funny because I was working with a founder visionary a couple of years ago and that was one of the things he wanted to do. He's like, oh, I want to go build this restaurant POS system for restaurants. He had never owned a restaurant, never worked in a restaurant and really had no idea what the software was needed for. He just had this idea and he wanted to spend money and time building this. And it was like time out. You know, it's like go do a little more market research on that. And then other people I've worked with, like you said, that have been in the industry and have figured out, hey, this is a problem. How do I solve it? Tend to do better. That was just kind of funny that you used a similar example of something I actually ran into. Did you go ahead with that or not? No, eventually I finally talked them out of that because they were not going to be very successful with that. It was more like a clouds in the sky idea. It's like you don't have enough money or time or resources and it's not going to go anywhere. That's where their ego comes in, right? Because they believe that they write and they want to pursue it. And I think you save them a lot of money and pain, right? Through talking them out of it. But Rob, from your side, do you have any, Kinty, have you got any examples of this or any experiences like this? Yeah, I tend to, I guess I tend to fall into two categories that I would have experienced. One is the ones that are, somebody that's an outsider that sees something. It would be like in a restaurant and they're like, oh, I see this problem. I can go solve this because I can get food to the table faster or whatever it happens to be. They see something, but they haven't really lived it. They're just like, they have a problem. It's something that's an issue they have, but they haven't really experienced from the inside. And it may be that there are solutions for that, especially these days. There's a lot of times that they'll say like, oh, there's got to be, you know, I'm going to go build this product. And once you start looking, you realize that product actually exists, you know, a dozen different ways because it's actually a common problem. And people have solved it. They just didn't know it because they're not part of that, you know, that industry. They're not on the inside. The ones that I that I find are far more successful, I think, like you do, is that the ones that have been the problem comes out of being within that industry, actually spending time and realizing that, you know, it's a they've got a special problem or something like that that just doesn't hasn't been addressed. Or if it's been addressed, it hasn't been addressed very well. A good example is a lot of times I've seen in the health care industry where there are there are applications to solutions that are sort of general purpose. They solve for a lot of places, but they don't solve maybe for a specific type like a specialist, like maybe like a podiatrist has something that's a little bit different. Or I know that there's there's a lot of people that think that health care and dental are the same thing. But dental records and all the stuff they track and how they do stuff is very different from other specialists. And then, of course, hospitals are very different from clinics. And so I find that it's it's it's a lot of times I want to talk to them when I'm when I'm talking to somebody with an idea like that. It's like, where did this come from? How did you how did you how did you come about the problem itself? How do you see that? How often have you seen it? Because it may be specific to them. It may be something that's like, wow, that's a horrible problem. And as you talk through it, you realize that they're the only person that ever is going to suffer with that problem. Or it's such a so niche that it's just like that's going to be tough for you to do, especially if it's if it's an expensive solution. I was like, all right, you know, you're solving things for only a few people and those people aren't rich and aren't willing to spend a ton of money. Then you're probably not going to go very well with it. And I found that like this goes back to I love doing like proof of concepts and clickable demos and very minimal MVP's and things like that to say, like, let's get this out and get in front of people that aren't like your best friend or your family. They're like, oh, I love it. It's great. And get in front of people, particularly those that have like they've got skin in the game where it's like, hey, let's get something out there and see, will they pay some money for it? Will they? What would you pay for this? So you can start figuring out is this real or is it just a nice to have or something like that? I love what you said earlier is like what happens? Does is going to be some sort of pain if you take this if you give them this application or this solution and you take it away? Because I think that's I think that's a really good markers. It's like, OK, that means that they, you know, they were there was some lack. There's some discomfort caused by that solution not being there. So that's essentially. Yeah. I do want to I want to sort of switch gears a little bit on this, too, is that because you do web and application and I'm I'm curious as what your your experience in doing. Web web web applications and apps and where you like, I guess the biggest struggle in particularly when you try to do a hybrid kind of thing where there's a there's a web solution and there's a mobile particularly. I mean, sometimes mobile native, then you just got completely separate code bases. But I'm thinking more the kinds where you're you're trying to do that hybrid approach and some of the issues, particularly for developers that they may want to keep an eye out for when you're trying to to solve for both of those platforms. Yeah, I think it's. Maybe I can answer this in a little bit of a different way. I think, you know, with founders, it's like they'll come to us and I'll say, listen, I want a mobile app. And you're like, well, why do you want a mobile app? No, no, I love apps. My competitors got an app. And then we're like, yeah, sure. OK, that's maybe a semi good reason. But, you know, the point is you want to get something out to market quickly. You want to get it, you know, this MVP. We spoke about this many times. And generally, Web is easy and quicker to build for. Right. So it's you know, it's nicer on the budget, on the wallet. You can get to market quicker and. You can, you know, everyone's got a browser on your mobile phone, on your tablet, on your laptop, whatever. But not everyone wants to install an app. Right. And then you've got. You've got. You know, as we spoke about in the beginning, like SEO versus kind of marketing within app stores is a big thing as well. And, you know, you've got to do a lot of different things or extra things with mobile apps. You know, if you're going to do the store submissions, you know, that takes a lot of time. Generally developing mobile apps, you know, if it's a hybrid mobile app compared to a Web app, you know, the functionality might be very similar. But it just it takes longer because of the nature of that development. You know, you've got to do a lot of compiling. You've got to deploy it to an emulator or to devices or test test flight. And that takes time and that costs money. And, you know, if you're just trying to prove product market fit, you know, does this product that I'm building solve a problem? We generally say go web first. And then if you're getting traction, you know, you can always go mobile app later. And I'll give an example. We built a big platform here in South Africa. And this client's been speaking to us for many, many years. So it's a web based platform. And he kept on saying, like, you know, I want to do a mobile app, want to do a mobile app, but it's quite costly. You know, it's not cheap and it's there's a lot of things to consider. And, you know, there's a lot of development behind the scenes. And eventually his markets, his user base is asking him, you know, through social media, through direct engagement, like when you bring out a mobile app, you know, I want the mobile app. And, you know, it's come up so many times now that the time is right to do it right. So then that makes sense, you know, from a cost, from a traction, from a testing the market, transitionary point of view. The other thing that, you know, where you need a mobile app is where you need something specific on that mobile app. You know, so maybe you need something specific to the hardware, you know, where you can't get that through a web application or even a hybrid app. That's less and less common now because even like hybrid apps are getting more and more access to the device's hardware. But yeah, so that that's another instance. And then there might be certain things you need to integrate with like SDKs that you can only do that through native, you know, so that your only your only option is to go native. Your only option is to go mobile app based. You can't build a web application based for that. And then another thing that people need to think about is the costs of these app stores. You know, if you've got a subscription based or in app payments, these app stores can take 20 to 30 percent of those payments, which a lot of founders don't even know about. They go to mobile app route and then they find out the hardware that, hey, you're giving away a large margin of your income to the app stores. So that's that's something to think about as well. Yeah, so I've answered your question in a little bit of a roundabout way, but I think it's quite an important consideration. You know, when you look at web versus mobile. Now, when you do a when you have something that's that's web and now you're you come back, you say, all right, we're going to do a mobile application. Do you or I guess more wonder maybe what are your thoughts on the web application being treated or the mobile application being treated almost like a second or a brand new application so that you're not because there's some definitely in the situation. So they want to just like make the app, the mobile app look like the web. But, you know, we know that once you get the real estates different and all the kinds of other stuff on the screen that makes it very difficult a lot of times to try to just shrink the web down to even with responsive design. There's like it tends to be I think there there can be an argument definitely for just design the mobile application, especially the user interface, the UX from ground up for mobile as opposed to trying to to pick it up from web. And what are your thoughts on that? Yeah, I think that, you know, trying to wrap a mobile version of the of the website or a responsive web based version into a mobile app. I don't think it it works so well. I think, you know, you can even get penalized for that. And I think that mobile apps have got a different look and feel. They've got different usability. You know, you typically got that bar at the bottom where you've got all your different buttons. But a mobile responsive website doesn't doesn't have that sort of usability look and feel. So, yeah, I agree. I think it should be its own project. I think it should be handled as its own code base, but also with its own interface and how users engage with it. And and you've got things like push notifications, which work really well on mobile apps, which, you know, you do get push on web, but it's kind of very limited. And it's not yeah, it's not really that well used. So I think, again, there that ties in with that whole usability of the of the mobile app. So kind of a final question, kind of flowing with all of that. What are some of the hybrid tools you like to use to build your web applications or somebody out there? What are kind of your favorite flavors? Yeah, so excuse me. We've done quite a bit of development in Ionic and Cordova, you know, that works nicely with Angular. There's Flutter as well. We built a few apps in Flutter, you know, React Native. We we've worked with one or two apps in that. But yeah, that that's about it. You know, we don't want to spread ourselves too wide. And I think that they're all they're all good tools. They've all got benefits. They've all got slight disadvantages. So, you know, there's not really one that we are preferencing over the others. Yeah, but there are others that we don't even use that people are using that, you know, are good as well. Well, I want to leave once again. Our has flown right by our time that we're hanging out here with you. So definitely want to appreciate the I appreciate you hanging out and giving us some some really cool stuff from. All the way on the other side of the world, practically from us right now. But anybody else is listening, I'm sure a lot of them are like, wow, this sounds like a great company. You guys are maybe they're sitting there going, hey, I've got some app ideas or some web ideas that I would love to have somebody work on. What's the best way for them to get a hold of you? Yeah, they can come to our website. So www.elemental.agency or they can look me up on LinkedIn. Yeah, that simple as that. Excellent. So we will make sure we get links to the show notes for anybody that is interested. And we will go ahead and wrap this one up. And thank you for hanging out with us and sort of wandering through the the desert or the forest or whatever it is, all of the snaggles of web and application development and tackling some of these latest questions and where where we think things are going. Thanks. Thanks, Rob, for the invite. It was my pleasure. I enjoyed it. I think we tackled quite a lot of subjects in a really short period of time. But yeah, it's been a real pleasure. Thank you. And definitely very much. So it's one of those that we have we have more than they have filled everybody's time, I think. Well, with with content heavy content rich our couple episodes now of time. So thank you so much. Those you guys are listening to out there and have yourself a great day, a great week. And we will talk to you next time. Thank you. Thank you.