• Speculid Talk
• Development Alternatives
  • Ionic
  • React Native
  • Xamarian
  • Cordova
  • NativeScript
• Continuous Integration for iOS Options
  • MacStadium
  • Travis-CI
  • Jenkins 
  • MacinCloud
  • Xcode Server
  • CircleCI
  • HockeyApp

Complete Transcription

[00:00:00] Theresa Jasko (Host): I feel like last time we had our podcast you've maybe done a few speaking engagements. 

[00:00:06] Leo Dion (Host): I spoke at ArborMoon at the Ann Arbor Cocoaheads group about Try! Swift which is the conference, I went to Labor Day week. And then I also talked about Speculid which is a Mac App for developers that I've been working on for building graphics for apps. I just talked about how it works and kind of the guts of the challenges I faced building the app. 

[00:00:31] Theresa Jasko (Host): Nice, So what is IOS development? 

[00:00:34] Leo Dion (Host): IOS, of course, is the operating system for iPads and iPhones. So typically it's the process of coding, designing, testing, and packaging an app and delivering it in whatever way a customer would want.

[00:00:52] Theresa Jasko (Host): Yeah, so if someone's looking into doing that what kind of factors go into getting a quote for that kind of service.

[00:00:59] Leo Dion (Host): So really it depends on the features and kind of the timeline of the app. So faster timeline is going to mean a higher quote then integrating any sort of third party services. So if you're integrating something like Facebook or integrating any sort of special controls or sensors on the iPhone like motion controls then that's going to up your quote. And then the complexity of the data that's being used, especially if it's data that's going to be stored locally or remotely - there's going to be some complexity there and that will take take more time. 

[00:01:40] Because that's essentially what we're talking about is quality and time the more you pay the more time it will take and the more higher quality will also mean a higher quote for those Services because that quality also takes time of course. So offline capabilities - not a lot of apps necessarily need that but a lot of apps want to have the ability to just having online and offline capabilities so syncing and things like that. Any sort of UI complexity and any UX complexity, chat, the amount or number of screens is a good indicator of how complex an app is going to be and how much the price is going to be. 

[00:02:26] And then this is much more an issue on Android but as far as iOS is concerned, It's what operating system versions you support. What devices you support. So is this just an iPad app is it just an iPhone app is a support iOS 12, iOS 11 how far down the chain are you going and that usually factors into the price of the quote for developing an app.

[00:02:53] And also another thing to mention is in many cases we're thinking a green app, but starting an app from scratch that has its challenges but also picking up an app that's already been developed on has its challenges as well. So that's something to that will weigh into the quote of developing an IOS app.

[00:03:17] Theresa Jasko (Host): Yeah, so when you talk about like those factors just now is there like a common app that you could use it as an example of like kind of illustrating some of that stuff? Is there maybe like a weather app or something like when you talk about like UI ux complexity and things like that? I'm having a hard time envisioning what that means in real life.

[00:03:38] Leo Dion (Host): Sure. So the way I think about it is a lot of times customers depending on how much they want to do when it comes to getting requirements for an app have a pretty good idea of what screens they want. And so I usually get into the process of asking them - Okay, what does this app do? What are you trying to do? What is your end goal and then figure out - okay, we'll need a screen for this and a screen for that and then the screen will go to that. Then I'll start thinking about like different edge cases because we always have to think like what happens in this case what happens in that case. What I do is in spreadsheet will write out the different screens that an app will need in order for it to essentially work. 

[00:04:26] For instance, we developed a nurse training app and that uses about four different tabs and probably each of those have different dialogues for adding credits for a nurse. And so we'll have say 12 screens in that app. Just kind of roughly and so that I look at the complexity how much data is being entered is it like one field, 2 fields, 3 Fields? How complex is that data? Is that data dependent on certain variables? Is there a certain range of acceptable values and then that factors into some of the UX that's involved or the user experience because I want to make sure that the user is walked through the app. Easily and knows what they need to do and it's intuitive.

[00:05:17] So I kind of rough guess how many hours that's going to be for each screen. We also talked about for instance with a brand new app, there's some setup time usually involved. And then for each screen, there's going to be testing involved say every week or two weeks so that gets added in as well.

[00:05:41] And then of course at the end, there's the issue of getting into the App Store assuming it's a app store app and there's always time involved there because you'll always find all sorts of issues when you get into App Store. There's also dependencies for their marketing or graphic design folks to make sure that they have the assets that are needed to get into the App Store.

[00:06:02] Theresa Jasko (Host): Hmm. Wow, do you find that when people approach you about getting a quote or something? Do they have a full understanding of the things that you're talking about are usually have to really kind of work with people to even explain that?

[00:06:17] Leo Dion (Host): Usually what I like to do is kind of do a rough tree of how the app is going to work. And then from there I'll go ahead and make estimates for each of those things. Sometimes I might do something like an initial consultation for a fee depending on how complex the app is. And then what I like to do early on in the project is have basically an app that doesn't work but at least has the UI and the workflow that they expect out of the app so that way early on in the process they're there confirming how the app is going to work eventually at some point. 

[00:07:00] Theresa Jasko (Host): What are the things - you know what - let's say someone wants to do a development project and they get let's say three different quotes. What's the reasons you know, if the prices are kind of varying pretty significantly what could be different there? What would you be maybe missing out on if you go with the least expensive? 

[00:07:23] Leo Dion (Host): Sometimes they are perhaps using services that might expediate the development process without really offering any ability to customize it later. Perhaps it's using some sort of different method besides building it native Apple like Swift or Objective-C. We can talk about the different methods for developing apps later. It's all kind of based on maybe an extensive experience or you know, just kind of taking shortcuts and things like that. There's some app building templates out there that people might be using as well which doesn't really fit with what they want. But really you're getting different quotes based on possibly the quality of work and just what features haven't been completely flushed out early in the process. 

[00:08:20] Theresa Jasko (Host): Yeah, so when you say for instance that you won't be able to be updated later or something. Does that mean they kind of cobble something together? And then that's just kind of it and you can't add to it later? 

[00:08:34] Leo Dion (Host): Yeah, that could definitely be the case in many ways. 

[00:08:37] Theresa Jasko (Host): Do a lot of people like when they make an app want to update it later or is it kind of 50/50 or you know, like well, yeah, we made this and it's good enough and we just kind of let it lie.

[00:08:48] Leo Dion (Host): I think it's 50/50 but with a lot of at least with iOS you need to keep updating app if you're going to want people to use it when you come out with a new iPhone that's bigger or has a notch or uses a different design then you pretty much have to update your app. You can't get away with keeping on the App Store because Apple can just drop the app if it doesn't work on newer phones. 

[00:09:15] Theresa Jasko (Host): Mhm. And so when you're saying people you maybe use like a template or something to say is it is it kind of like a square peg in a round hole thing where it's like, well we have this starting point and we're going to kind of make it work for you.

[00:09:26] Leo Dion (Host): Yeah, that's exactly what you could run into. If somebody could just be using like a template and they're not maintaining a they're not keeping it working and keeping it going. So when the new phones come around they haven't updated the template or they haven't updated the app. You're going to have to just come back to those people to update the app and your kind of dependent on them at that point.

[00:09:51] Theresa Jasko (Host): So you're saying you couldn't have somebody else come in and update it then. 

[00:09:56] Leo Dion (Host): Well somebody else could but they're going to charge for whatever it takes to reconfigure that app. That might be outside of their wheel house. 

[00:10:06] Theresa Jasko (Host): So what is the difference between starting from scratch like to me when I feel like when you start from scratch with something it's going to take longer than going to be more expensive. But then you're saying if you using a template or you know, kind of a starting point that somebody else is made then that can create problems later on too. So you ever start with a template or anything or do always kind of start from scratch? I've started with some templates before or at least started with other development projects and it really depends on that previous team and how well they did if they did a good job and structured their app well, then it might not be that big of a deal to pick it up. But if it's just cobbled together like what we're talking about then there could be some serious issues trying to bring that app in. And if it's old enough that it uses some old code that doesn't work anymore. That could be a serious issue for the new team that comes in and adds new features to the app. They might come to a conclusion that is some of the stuff is worth just burning down and starting from scratch. 

[00:11:13] We've been kind of talking about different ways of going about it. Does that mean that there are different methods for developing apps for the iPhone? 

[00:11:21] Leo Dion (Host): Yeah. So we kind of talked about some templates. There's app building templates are out there, but there's also a different methods that deviate from just doing it the Apple way so to speak. So there's what I like to call like the web development wrapper way of doing it and the building it in my own favorite language, but still make it a native way of doing it and they each have their advantages.

[00:11:48] So with the web development wrapper, that's typically something like Cordova or Ionic. Cordova was built by Adobe and essentially what it is is you build a web app. So you're just you doing regular HTML and things like that to build. The app and it's wrapped but you still have access to certain native features on that phone.

[00:12:14] So to the user it looks like just regular app out of the box, but to you the developer, you're actually just building a web page. There's so many questions as far as how to get something like that into the App Store that can sometimes be a challenge but if you do it, right, there's quite a few apps that are built using that technology

[00:12:39] Theresa Jasko (Host): what do you mean by native? 

[00:12:41] Leo Dion (Host): When I say at least looking native is an app that doesn't look like something that's hacked together using custom components or packaged like it doesn't use like actual apple design elements that people typically use when they build an app.

[00:13:01] So like I've been on certain apps that have like a weird wood grain or it has buttons that don't look quite right or has drop down menus, which you don't really see in a lot of Apple apps and that kind of gives a good indication that use some custom software to build it. Unless of course it's designed well, and it uses kind of some of the third-party tools will talk about in a little bit.

[00:13:26] So like with a web development wrapper, sometimes it'll just have a weird color scheme attached to it or it'll have different menus that you don't typically see in an app that's developed natively using xcode the toolset Apple has available. 

[00:13:45] Theresa Jasko (Host): Okay, so it just kind of feels a little off or looks a little off at best.

[00:13:49] Leo Dion (Host): Yeah, exactly. 

[00:13:51] Theresa Jasko (Host): Okay, then what at worse? It just doesn't work correctly. Yeah. 

[00:13:55] Leo Dion (Host): Yeah or it just doesn't make any sense. It doesn't follow the paradigms people typically are used to when they use a IOS app. 

[00:14:04] Theresa Jasko (Host): Well, if so if it's clunky and weird like that, why do people even make them or release them 

[00:14:14] Leo Dion (Host): because it's cheap and easy. So, I mean that's kind of it. Also, maybe maybe they're focusing on Android. So they just wanted to make sure it works on Android and if it works on iOS, that's fine. It's a lot of that. So that is the benefit. A lot of these different methods is that you can ideally developed for both Android and iPhone at the same time. But in a lot of cases your UI won't look natural on Android, but also won't look all that natural on iPhone as well. Okay, because you've made some compromises. 

[00:14:51] Theresa Jasko (Host): Yeah, I didn't think it went that both ways because I've always heard. You know, when I complain about different apps that I use on my Android usually people are like, well it's because you have an Android. I didn't realize it happened on IPhones and stuff too. 

[00:15:08] Leo Dion (Host): Yeah, there's definitely some crappy apps out there on the iPhone. 

[00:15:15] Theresa Jasko (Host): All right. So what other ways are there to develop apps than besides this cobbled thing?

[00:15:20] Leo Dion (Host): So we talked about building a website or webpage and then packaging it as an app kind of what Cordova or Ionic does. And then the other method is developing in a specific language that your development team might know in a lot of cases JavaScript and then building it using that for iPhone or IPad. You see that a lot with NativeScript which is built by the folks at Progress  but even more popular we see that with React Native which is built by the folks at Facebook. React is really popular amongst folks in the web development circles. And so if you're somebody who's already have a web team and they're already familiar with React then it makes sense. Maybe you just reuse those same people to build an app using React Native and it uses the same a lot of the same things that React does, but you can use it to build basically a native app. Whereas the first one [Ionic] takes it. A series of web pages are and HTML files and kind of puts it in a frame or wraps it this one actually converts the code into native code. So it actually is building a app. There's no HTML or anything like that in the app. It's actually building native features, but it's converting it to native from JavaScript in these cases or NativeScript. 

[00:16:55] Theresa Jasko (Host): Okay. Have you done all these different methods? 

[00:16:59] Leo Dion (Host): Well, the one that I've used is Xamarin, which is by the folks at Microsoft. So that uses C# to build apps. The problem that I found was constantly these tools have to catch up with Apple or Google to make sure that they're compatible. So Apple might come out with new stuff. That means your have to be dependent on them to make sure that they're updating their tools to work with whatever is new when it comes to Apple. So there can be a little bit of a support issue. Also at least with Xamarian those files can get pretty large because they might have like a file in there that has to do all the heavy lifting of making sure that the app works, even though it's written in a different language. So your app size might be a little bit larger a little bit slower because of that. That's kind of the issues I ran into at least when it came to developing using Xamarin 

[00:18:02] Theresa Jasko (Host): So developers do use different methods. 

[00:18:06] Leo Dion (Host): Yeah You'll see a lot of teams, they might just do react native because that's what they know - React. So it's easier for them to just go ahead and stick with that. Or they might be a bunch of web developers, so it might just be quick and easy to use Cordova or Ionic in that case. 

[00:18:25] Theresa Jasko (Host): So one of the related words or phrases I guess I've heard is continuous integration. So how does this relate to continuous integration? 

[00:18:38] Leo Dion (Host): Well, we're talking earlier about experience, testing, UI complexity are kind of the factors that might make a quote more expensive. One of the things is being able to continually make sure that as software is written that it actually is tested. So there's the common term in programming called unit testing where you'll write a thing that does addition. So you'll write a method or function that does addition that is takes numbers outputs the sum. Right, and then the way a unit test will work is you might have a series of numbers that you know add up to another number and you want to continually test to make sure that if you add two and two that will always equal four with this function if you had four and six at always equal 10, and so on. That's gives kind of a really simplified it sample, but you might have some developers come in and have make modifications to this method so that it does things like negative numbers or take decimal points. So then you need to make sure that you add those tests and you continually are testing both with the new test but also the old tests as you make changes to this function that adds two numbers together. So that's kind of the idea of continuous integration is as your team comes in and makes changes to different functions and methods and features within an app that the app still works based on the old code that's been written before. And typically how that's done is you might have a separate individual machine or you might use some service in the cloud that will take your code build it and make sure everything works no matter the environment that it's in and that it works on whatever you support and whatever devices you intend to support. Does that kind of make sense?

[00:20:32] Theresa Jasko (Host): Yeah a little bit. I'm I guess I'm having a hard time imagining like. Do some people not tests throughout their development?

[00:20:40] Leo Dion (Host): Yeah, I mean everybody "tests", but typically it's - so does it work? Like and you just kind of use the app and it works and you're fine, but there are so many outliers and different things that people do or my might do differently. And there's different kind of testing of course, but you'd be surprised how many teams don't test and don't do things like continuous integration.

[00:21:03] Theresa Jasko (Host): It makes me wonder there's stuff going on at work where they developed a new system and has never quite functioned right and then they will do bug fixes and then the next day a bunch of other things have been broken and It's always kind of intrigued me like why is this happening? 

[00:21:21] Leo Dion (Host): Yep, and that's a lot of cases what they find is, you know, the testing is part of the thing that gets cut because if it works good enough that it works good enough and that's unfortunate in a lot of cases. 

[00:21:33] Theresa Jasko (Host): Yeah. So do you is this the method you use the continuous integration?

[00:21:37] Leo Dion (Host): Yeah, actually  last night when I was in Ann Arbor. I talked about Speculid and how I used Continuous Integration. I used a Cloud Service - Travis CI which is available for free for open source projects, which is really nice because a lot of services that do continuous integration of the cloud are expensive. Because of how much it costs you pretty much have to get a Mac machine in order to do it. So yeah last night I talked about Travis CI and how there's some customization involved. But also one of the biggest challenges is if you are building in this case the Mac app or especially if you're building an app for the App Store you have to make sure that you have certificates and keys setup so that like for instance in the case of Travis CI you might want to just upload it to the App Store as soon as your testing is verified and it works correctly.

[00:22:34] So that's always something to keep in mind is to make sure that you have your environment set up correctly and you have things like certificates and provisioning profiles and all the little doodads and security stuff that Apple requires when you want to post something to app store. Or in the case that I ran into just distribute the app downloadable.

[00:23:01] So there's some other services out there. There's like Mac Stadium -Where you're typically like renting a machine essentially on a monthly basis. There's Jenkins if you want to run it on site or xcode server, which but I've been playing around with lately. And the idea is you're not running it on a machine. You'll especially run into the issue where a developer has something specifically set up and it works fine on this developer machine, but then when they run out on somebody else's machine, it doesn't work.

[00:23:34] Well you need to know that. Because if you're going to write a piece of software you need to know what's depending on what needs to be set up or what you're missing in your application in order to get it to work. It's really nice with iOS because you can just run it in the simulator, but even simulators have some major differences to how it works on an actual device.

[00:23:54] So you want to have access to something you can reset and start from scratch and run the app and make sure it works. 

[00:24:02] Theresa Jasko (Host): So is this automated is this something you set up and say test every day at 10 or is it something that you do yourself or how does it work? 

[00:24:10] Leo Dion (Host): So there's a couple of things you could do. You can set up on a schedule so you can say I'll run hourly or daily. You can especially if you're using something like git to control code where code gets checked in you can listen for changes to the code unlike the central server and when a code change happens, you can get the code and run it on the continuous integration machine. So it's another way to do it.

[00:24:37] And typically those are kind of the two main ways - run it on any code change that you listen to or run it on a scheduled basis. 

[00:24:45] Theresa Jasko (Host): So if you know kind of your average customer is considering a developing an app, are there certain things that they would maybe assume comes along with it, but it doesn't or just things for them to keep in mind if they start thinking about this.

[00:25:04] Leo Dion (Host): So we talked about continuous integration testing - that's something that they should look into and ask questions. What kind of testing do you do? What kind of testing environment do you have? Another thing you want to ask is analytics? I don't think people think about that enough, but I think it's super important to have some analytics to know how people are using your app and what issues they have is there any sort of bug reporting that's natively built into the app something like instabug or bugsnag or some service like that. Also animations like that stuff is pretty complex. Don't make the assumption that there's any animations any custom fonts or any Custom Graphics. Those are things that you have to think about when you're building an app and then any sort of like backup support.

[00:25:56] Are you going to actually own the code when it's done? What kind of services are there for maintaining the app is that baked into your contract or into your quote? So those are some things to think about when you're asking somebody to build an app for you essentially.

[00:26:13] Theresa Jasko (Host): Okay. Do you offer those different things depending on what your customers want or do you kind of have a standard like I always have bug reporting and analytics or something like that. 

[00:26:24] Leo Dion (Host): I always ask the customer what they want because it really depends on their budget coming up for my end. I want to make sure that I stay within their budget and make sure that I'm not adding in extra services they might not need because in some cases they just need a simple app. And then which is what I usually suggest depending on the budget is like both building something simple get like not a prototype but like a usable proof of concept that you can get to your customers so they can actually start using it and then if you see like there's some issues or there some features that we really need to flush out then, you know, come back to me let's build version 2.0 and really flesh this thing out. 

[00:27:04] Theresa Jasko (Host): So is it easier for people to come in and kind of know how much they have to spend or is it better to have a range and then work someone like you to start to hone in on like what features they want or what's the best way to approach a project like that?

[00:27:20] Leo Dion (Host): I think both I think what is the ideal app you're looking at building and then what's your budget and that gives a good idea. Because the budget really is going to give me a good idea of what kind of features are reasonable. And also of course the timeline like well how soon do you expect it to be done?

[00:27:40] And that really gives me a good idea because I want to build the best app within what somebody can spend and knowing those factors really help communicate clearly to me and clearly to them what can be done within that range. I work to make my customers happy and I want them to be happy and I hate to be in a position where I over-promised and that's something I never do.

[00:28:06] So, the other thing to keep in mind is sometimes what the customer wants isn't really what the customer wants. And so you know, I could do a really kind of basic estimation but if they want something more flushed out, what I like to do is kind of do a requirements analysis and get an idea of  what are they really?

[00:28:33] What's their end goal and then kind of design around that and maybe build a rapport that at the very least if they don't want that app, then they can they can take that to somebody else and go: "oh, you know, we had an analysis done this is kind of what we're looking at getting built and maybe take it to somebody else to have it built for them if that's much more a better fit for them.

[00:29:00] So it really depends on their budget to like do they want to spend some money on a kind of report that we can take and then build an app against or do we want to put a quick estimate together and build based on that? And so that depends too is like how much of an analysis do they want beforehand.

[00:29:20] Theresa Jasko (Host): Do you have any examples of someone thought maybe they wanted something but it what they really wanted was something else?

[00:29:27]Leo Dion (Host): Yeah in a lot of cases. I've found that people you hear the I have a great idea for an app thing and I think I'm always surprised at how many times people haven't just looked in the App Store to see if that app already exists because a lot of times it does and in a lot of case It doesn't work very well. So that can always be a challenge. I think it a lot of cases people don't get into the specifics of the rules that they have in mind and they don't think of the weird edge cases that actually come up more often than they think so they think something is fairly simple, but then they realize that there's going to be situations where in fact it isn't that simple and that there might be a lot a situations where people are running into all sorts of issues because there are certain things that they need. for instance we had that nurse training app where we have on occasion with  nurses that need certifications in multiple states. So that's a big deal because you know, that might have been built to only support one state and if you're somebody who needs to get certifications in two states you need to track those credits accordingly in both States. And this is something people didn't think about and we brought that in and so they're always situations like that. Especially what you get with somebody like me is I've been developing an apple space for almost a decade now and I understand how different UI and ux paradigms work on Apple what people expect from a app that it's on an Apple device and those are things to think about as well.

[00:31:19] Theresa Jasko (Host): You had mentioned earlier one of the questions was about like who owns the code. Can you explain more what that means? 

[00:31:26] Leo Dion (Host): Right so you'd wall was want somebody who develops an app for you to give you a copy or access to the code or repository? I mean, I feel like that's what requirement with any app.

[00:31:38] Theresa Jasko (Host): Are There people that develop stuff and then don't give it to the customer. 

[00:31:41] Leo Dion (Host): Exactly and that is always something to check on. 

[00:31:45] Theresa Jasko (Host): What would be the reason for? 

[00:31:47] Leo Dion (Host): Maybe in a lot of cases they don't even think about the code. They just want the app in the app store and maybe they don't want the customer to see how poorly the code is written. I always provide the code like that just makes common sense. Yeah, but you'll find situations where that isn't the case.

[00:32:05] Theresa Jasko (Host): yeah definitely wouldn't have thought about that. So if someone were interested in investigating this do people offer like a free consultation or it it usually like a fee to kind of start to explore 

[00:32:18] Leo Dion (Host): depends on how much you want me to break down the estimate if you want something for pretty basic than I could probably do it for free, but I think it's always better to like talk to the customers start like sketching things out and of course when it gets more details than it's not a free consultation, but for a very basic app yeah, I've done free consultation certainly. 

[00:32:43] Theresa Jasko (Host): I just mean like if I don't even have any idea like I'm thinking I want an app. I could probably spend $5,000. I mean is that even like in the realm of reality? Like how do you even know what you need to put aside for that. 

[00:32:56] Leo Dion (Host): No, I think five thousand dollar app would be well below the budget at this point. Yeah, I mean it's possible to do a five grand app, but it's not going to have a lot of features quite frankly. I think like right now you're talking bass price for an app would be 10 grand and it goes up from there. And I think that yeah, so typically, you know, that's where you need to start thinking about like third-party services, analytics, offline, UI  and ux complexity and things like that and that's where the price kind of increases from there.

[00:33:33] Theresa Jasko (Host): So other than getting like referrals from people that have worked with folks, is there other ways to kind of tell if you know who's a good developer and if they know what they're doing. 

[00:33:44] Leo Dion (Host): I think look at their portfolio. I think that's a great way to look at the references and then kind of get an idea - talk to them about how a typical timeline will work and you want somebody that's going to be honest with you and tell you all the different missteps that can go along the way and all different gotchas that happen in the app development process, especially with like Apple, like something that will come up is your app gets rejected for the App Store. Now, what are you going to do and you have to think about those things and you want to developer that'll be honest with you and forthright about the different issues that could come up. Like I said, portfolio references what's on the App Store? what do they have as far as on the company website?

[00:34:30] What do they have that talks about this kind of stuff that's going to give you some confidence to know that they're actually doing what they're talking about. 

[00:34:36] Theresa Jasko (Host): So is it safe to assume there are going to be hiccups. There are going to be speed bumps and it's just kind of matter of what they are and when they're going to happen.

[00:34:45] Leo Dion (Host): Yes, exactly. Yeah. 

[00:34:47] Theresa Jasko (Host): So if anyone tries to tell you it's just going to be smooth sailing and nothing bad's going to happen - that's a red flag. 

[00:34:53] Leo Dion (Host): Yeah, I would say so it's definitely a red flag and like if they haven't given you a portfolio or a list of references, like that's a red flag as well because they probably don't know what they're talking about.

[00:35:04] Theresa Jasko (Host): Yeah. So what kind of things you know, besides getting a budget are there certain things that a customer should think about beforehand or prepare in order to make the most that time.

[00:35:16]Leo Dion (Host): Have regular meetings with that customer talk to them. Make sure you have a copy of the app to test around on your own machine on your own iPhone so that you can look at it get it into your hands as quickly as possible so you can see it and talk about it and look at what issues come up and I think that's a big part of it. 

[00:35:38] Theresa Jasko (Host): I feel like what we've talked about does make it maybe seem less scary to me, you know, if this was something I was going to be investigating for myself, which I think is a big big thing. Right? I mean a lot of technology stuff I feel like because kind of based on fear you make decisions based on fear. You don't make decisions based on fear. So, you know, I think anything that makes it a little more easier to understand is good

[00:36:01] Leo Dion (Host): Going to our discussion previously about continuous integration. I think it'll be interesting to see how Mac Mini is that into other development shops and how they might employ Mac minis in their environment because you know that I think is the biggest draw of getting a Mac Mini is having a continuous integration machine you can you could format and do all sorts of stuff with and break, essentially without having to worry about you know the cost of getting into enormous machine to do it. Because this is easy to run every so often interested work. 

[00:36:33] Theresa Jasko (Host): Yeah. Well cool. This has been super interesting. I always learn a lot from our discussions. 

[00:36:39] Leo Dion (Host): Yeah. Well, thank you Teresa. 

[00:36:41] Theresa Jasko (Host): Yeah, great. I can't wait till next time. Yep. Talk to you later.

★ Support this podcast on Patreon ★