Business strategy for mobile app development freelancers: Position yourself for success | Evan Kimbrell | Skillshare

Business strategy for mobile app development freelancers: Position yourself for success

Evan Kimbrell, Director at Sprintkick

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
7 Lessons (39m)
    • 1. Welcome to the class!

      2:04
    • 2. First thing to do

      1:05
    • 3. iOS versus Android

      10:46
    • 4. Native versus hybrid

      10:38
    • 5. Build yourself or contract?

      4:33
    • 6. In house hiring or out house?

      8:21
    • 7. Keep the learning going

      1:32

About This Class

If you're new to mobile app development or venturing out into the big, bad world as a big, not-bad freelancer, you'll need to know how to position and pitch yourself to prospective clients. You'd be surprised (on second thought, maybe not) at how many developers don't know how to do this. Unfortunately, being able to build an app is not enough. Like any other entrepreneur, you'll need to strategize.

This class will teach you how to hone your business skills. You'll come out of here knowing the answers to crucial contextual and platform-specific questions that will help you sell your services as a freelancer. Should you go native or hybrid? iOS or Android? ...Blackberry? How to brand? How to expand? How to outsource?

We all know there are tons of benefits to being a developer (we're mainly talking about money). Now just imagine those benefits if you become a super-developer (we're mainly talking about money and boats).

What you'll learn:

  • How to make crucial marketing decisions
  • Specialization strategies
  • When and how to scale
  • When and how to subcontract

What you'll do: 

I want you to go on a scavenger for hybrid apps. They're out there...waiting. 

Transcripts

1. Welcome to the class!: Hey, guys. I'm Evan Kimbrell, and I'm the director at Sprint Kick, which is a Web and mobile development studio based out of San Francisco, California So this class is called business strategy for mobile app developers. What do you guys out there are probably interested in jumping onto the mobile application Gold Rush. And a lot of you out there probably already know a thing or two about Swift and making your own applications. What things I've noticed is that a lot of mobile application developers don't know really anything with regards to how to sell their services as a freelancer. So this class was created as a way to target that problem. Mobile app. Developers don't really know enough about how to position themselves on how to pitch themselves to be successful as a freelancer in this class, we're gonna cover a lot of contextual and platform specific questions and a lot of mobile app. Developers have to answer themselves. The angle we're gonna take with this class is we're gonna focus on what decisions is a mobile app developer should you make to put yourself in the best position as a freelancer, we're gonna tackle questions like Should you build native applications or should you build hybrid? We're gonna talk critically about whether or not you should work on Iowa's android or both . Should you ignore things like BlackBerry and Windows phone? Probably. We're also gonna talk about subcontracting. How is it feasible as a mobile application developer? When should you use it? And is it realistic for your situation? The last thing we talk about is planning for expansion at the end of this class. I hope that you have a better idea of what works. Well, in a business sense, with regards to your mobile development skills, hopefully I can impart some information to you from my experience running a studio that builds mobile applications. Okay, if you want to learn the basics of business strategy for mobile app, developers roll in the course we'll see in there. 2. First thing to do: Hey, guys, welcome back to the class. So I have an assignment for you really quickly. I want this to be the first thing you dio eso at the bottom of the skill share page. It says discussions, the clip discussions, and then you can click new post. I want you right now to go and do that and introduce yourself. You don't have to tell me a lot of information. You can just say your name or your from. But what I'd like to actually hear from you is one. What do you struggling with? And to what are you looking to get out of the class? I think this is something that helped immensely with the class. I really like to make my classes as engaging as possible. I respond to everyone, and I want to make sure that as I'm teaching, I'm meeting your goals and I know exactly what I'm trying to fix. Okay, so this is the first thing. Just go down to the bottom of the page. Do that now. Don't skip it. You can skip it if you want, but I think you'll miss out. All right. Seeing the next lecture 3. iOS versus Android: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk about IOS versus Android. How do you pick which platform to focus on? And how do you pick where you want to direct your marketing strategy towards Now, I'm sure you guys have a general idea of what IOS is like who uses it, Um, and how it feels like. And I'm sure you have also a similar understanding of Android. Now there's reasons why people choose to use one of the other as a consumer. And there's reasons why mobile app studios choose them as well. Those are two different decisions, and the logic for each is a little bit different. I'm explain both you. Now, first, let me dispel any notions we're gonna be talking about the other platforms, the Windows phone and the BlackBerry. And the reason why we don't really talk about these visits in general, it's not really worth spending your time on them between IOS and Android, that actually covers 97% of the smartphone market. So 3% is divided up between android and windows phone. While it's nice toe, have a specialisation strategy, it doesn't really make sense to have a strategy that's based off of something that caters of 3% of the market. That's just too small on your leaving way too much money out there. So let's get back to the main topic, which is how do you pick between Iowa's and Android now? First off, let me tell you that in my experience for every one person that came to me and said, Hey, I have an idea for an android app at about nine people who came to me who said, I have an idea for an IOS app now to understand why there's such a skew in that you have to understand kind of the rationale that companies use when they pick their go mobile strategy . So when a company goes mobile, there typically gonna focus on whatever platform is gonna put them in the best position to make money and look good. So with that being said, IOS is pretty much the favorite now. The first reason why IOS is so much more popular with companies is the demographics. The people who generally use IOS live in United States and Europe in in developed countries , and they're typically in the middle income or upper middle income bracket. Those people typically have disposable income, and they're willing to spend it so more profitable customers are on IOS. And the second biggest reason is branding now at branding. There's a couple things going on here in general, companies that want to control how the user feels when they use their application. I want to control the user experience are going to pick a platform that they can control. IOS has 20 different mobile screen sizes. While that might sound like a lot, Android has well over 200. Now, what does that mean for branding? Well, if I'm building an application and I want to have a consistent experience across the board in my application, depending on who's using it, I'm generally gonna pick the one that's less fragmented. Now imagine you're making an application and you want this screen to be this size. You want this button to look like this and you want. After I click this, go to this section and you don't want anything to look off and you want it all fit seamlessly. Well, if you're building it for Android, there's over 200 different screen resolutions So how are you going to do that? To people? People will do is that they'll build for five or six main screen resolutions and just hope that it fits roughly well with the rest of them. But it's always the case that people out there, if they have a less common screen resolution, are going to see your app in a different way. So that's one element of Brandon. You can't really control the android experience with IOS you gnome or what you're getting yourself into. The other thing is how your app is presented. Now, if you've used IOS and you, I'm sure you have, you've probably been to the APP Store, the APP store. If you haven't noticed it's centralized, that's one of the biggest features of it. If you want to download something on IOS, you have to go to the APP store. That's the only place you can get it on. The APP store displays all the apse, all the information in a standardised and easy to understand way. The rankings are all standard, and they're all determined by Apple. Now, with Android, it's a totally different story. If I want to download an android app. I have to do it either the Google play Store, Amazon App store or other third party APP download sites. Now, if I were presenting my app and presenting my company, I probably prefer to go somewhere that looks better and more standardized. If I display my app, I have no idea what it's gonna look like on those third party distribution sites. Also, wanna be able to track my rankings? That's really hard when Amazon might say something and Google play might say something different. And, you know, one of the third party say says something totally different now those air big reasons. But the biggest reason is that in general, a user on IOS is just more valuable users on IOS arm or willing to spend money, and they spend money more often. Also, advertising on IOS gets a better rate on Android. You're gonna get pennies on IOS. You're gonna get tens of pennies. In general, the figure comes out. Teoh, an IOS user, is worth 60% more than an android user, and that's the biggest deal. If you're building an application that needs to make money through the purchase of its app or needs to make money inside of that through in app purchasing. Um, you're gonna want to go to the platform that's gonna make you the most money. Now another side, No. In another reason why this is the case is because people are patterned following creatures and is the case that most companies out there started with an IOS application first and then moved Android if they ever got to that point. So in general, when a company or a startup is deciding to go mobile, they're usually gonna follow the lead of the other companies and goto Iowa's first. And it's such the case that consumers air completely used to that. And that's generally what they expect. It's more odd if you would android first and then Backwards and IOS, but that's all fine and dandy. It's helpful that you understand that, but what's the most important thing when it comes to you as a mobile application business? What's gonna make you the most money and what's gonna be the best thing to position yourself for now? Not surprisingly, I actually support focusing on Iowa s and Onley, having a secondary expertise in Android. Now there's three reasons why I say that's the case and why I think it's gonna make you more money and get you more clients. The 1st 1 is that there are obviously three different types of clients. There's one that wants IOS to that once android and three that wants both of them. A dual app system now is usually the case that people want both. Um, usually they assume that if they're popular on one, they'll get the other. It's very rare that you get an android only, and it's somewhat common that you get an IOS only. But in general, big money is in the people who want dual applications. And since it's common practice to go Iowa's then android, you need to be aligned. Teoh, get the first contract to begin with. If you Onley focus on Android and they want to go IOS and Android, you're not gonna get your foot in the door. It's very hard for you to get that project from them because they're gonna be much more inclined to work with the first company who made their first app. So you need to set yourself up to get the first deal. And if IOS is the first application that the vast majority of companies go for. You need to be their first number two people who have a brand to protect and are interested or concerned with curing their brand that they're typically clients that have more money. So in general, if you have a client come to you and they have a brand, they care about their prey, and they care about how people feel about their brand. That generally means that there probably a well established company, and they're probably going to be more reasonable. And it's easier to explain to them why they should ADM or to their application to make it better and to make the user feel better. If you have someone who doesn't care about how it looks or even care about how the APP presents who they are, then they probably don't have a well established company, and they probably don't have a very large budget now. The other reason is that android it actually could be a huge pain. Like I said, Android has over 200 plus resolution screens. That means that you can only focus your efforts on a certain section of the most popular ones and no matter what, you're always gonna have visual errors at the end of the day making thing for Android and then showing it to the client. It's you're less likely to wow them because as soon as they're done looking at it on approved device, they're going open it with a different one, and it's gonna look totally different. The other part of this is that Android has a smooch, slower adoption when it comes to their versions than Iowa's. To explain that a little bit better, IOS updates their operating system quite frequently when they do, people download that newest version very, very quickly, so the newest version of IOS has 80% of the users on it now. Android, on the other hand, they just released Lollipop and On Lollipop. They only actually have 10% of their users on the newest version. So when you develop for Android, it's actually a lot harder to know what you're trying to develop. Four. Now, keep in mind, different operating systems have different functionalities. They have different ways of going about doing things. So when you're building the application, you don't know what operating system the person is going to be using it from. And so you don't even know if some of the features might not even work now not to rag completely on android Androids. Great for a lot of other things. Android has an open architecture system. What that means is that you're able to modify I'm or of their system and access more of their features or core operating system features, then IOS. So what ends up happening occasionally is you have people who come and say I want to build this IOS application that does this and you actually end up saying, Hey, we can't do it for IOS but we can do it for Android. Other advantages of android is that well, they have eight times as many users. So if you care about how many people see your application, that could also be important there also dominant in developing economies. So if you will have a marketing strategy or you have an app that you want to get out outside the United States and outside Mawr of the developed western countries, then you probably have to go android. So if you wanna build something that is primarily technical and you really only care about how many eyeballs see it, then Android might be a good idea now. What's most important to keep in mind is that when a company decides to go mobile and builds a strategy around that there is rarely the case that there is a go mobile strategy that excludes IOS. It's very common that a company decides to build out a mobile application strategy that excludes Android. But it's very rarely the case that they decide that Iowa shouldn't be included in the mix. So my advice is to focus on IOS. That's what the money is. That's where you could have a better user experience in a better in product at the absolute minimum, focus on Iowa s and have a separate subcontracting strategy for Android so that when you get a client you can keep them, make more money off them. They can also be more appealing to people who want dual applications, and those are very, very lucrative clients 4. Native versus hybrid: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk about what? Our hybrid applications. What are native applications? How do you make a decision yourself about which one you're gonna use? Whether that's both or it's one of the other. Now, first off, if you are already familiar with what native applications are and what hybrid applications are you can actually skip towards the end of this lecture, I'm gonna cover some of the basics to explain to the people who don't actually know what those are just really quickly. And then towards the end, I'm gonna give you my opinion, in my experience, working with both. So first of all, let's actually define what I mean by native application and hybrid application. So first off, a native application is an application that's designed for one specific platform. Now buy platform. I mean IOS android. I could also mean windows phone or BlackBerry. Now, a native application is written in the programmatic language that is specific to that platform. Therefore, when you make, say, a native IOS application, you can't just copy and paste that into Android and expect it to work now. Hybrid on the other hand is actually more of a relatively new form of application. What this is, it's an application that it can actually be deployed throughout every single platform, and it uses common programming languages that are very similar to basic Web programming languages. Now, if you've ever seen Adobe Air, that's a good example of what the hybrid concept is now. Adobe Air doesn't necessarily speak to mobile, but if you're familiar with it, then you can understand the basic concept. So with mobile, the system you should be familiar with if you want to go hybrid his phone gap and phone gap is probably about the number one application that allows you to put in Web programming languages and then deploy across multiple mobile platforms. Now, just as a side, guys don't get confused when I say native and hybrid, Um, don't get confused. That with what mobile Web is mobile websites are completely different. That's when you have a website that has a custom layout so that I could actually display itself on your phone correctly. Now that could happen in two different ways. One is that you go to a website and it's actually formatted towards your screen, and most large websites are like that now. But also you can launch Web applications directly from the phone itself. You can package it like an application, you press it and an opens that's entirely different than what we're covering right now. Now let's talk about cost and development time. In general, Native takes a little bit longer and cost a little bit more. Hybrid, on the other hand, is faster and cheaper now. Why is that? The reason why is because a native application requires kind of custom, specific, unique skill set to build it. And in general you have to build it with the tools each platform gives you. So it's not actually the most efficient way of doing it. When you build a native application for Apple, you have to use the tool on the STK kits they give you. Same goes for android. Same goes for all the other platforms. Now hybrid is faster and cheaper because it uses Web technologies. Um, and you only really have to make one version and then do smaller tweaks or smaller Custom is ations as you replicate that for each platform. Now, if that was all you heard me say you would think that the answer is actually quite obvious . Right? Hybrid. You can save money, do it faster, and it could go on all platforms and not just one. It seems like a no brainer. Well, you have to actually think about it, though. Money and time are not the only thing that makes a good application. The biggest difference between the two and this is the difference that is much more important than all the other differences. Um, is user experience now. Native applications in general have better user experience or are capable of having better user experience. Why is that? When you work with a native application and you use the platform that you are given, say you're working with IOS. IOS allows you to access basic phone features like dialing numbers, sending SMS saving contacts, taking photos, saving photos, anything that is actually part of the hardware of your phone. You can access that with the native application. Now that is actually not the case with the hybrid application. Most hybrid applications struggle to control hardware because they're not built for one specific type of phone not built for one specific type of platform. They try to cover all of the platforms, and what ends up happening is it's very difficult to actually access some of the more basic features that you take for granted in normal applications. Of course, some hybrid systems now actually can handle a lot of those. But for the most part, and with my experience, it's always with very mixed. Success is always something. It's always a little bit harder than it should be. So, really, that's the biggest difference. Hybrid is faster and cheaper, but native looks a lot better, actually flows a lot better, and it can control lots of different things in the phone that hybrid applications struggle to control. So just for fun, open up your phone. See if you can find a hybrid application and see if you can find a native application. I'll give you a little bit of a hint. Native applications typically look much more seamless. They look like they fit the screen perfectly. They look what they have graphics that actually are made for your screen resolution. When you click a button, this is usually the key giveaway. Native applications will respond differently than hybrid, so let's say you click the next button in a native application. You might actually see the image depressed and then come back up and then load the screen and you might have some cool intermediate pages. Now, if you're using a hybrid application, you would notice that is actually slightly different now. A lot of you don't really care about that, but that kind of thing adds up very quickly. It loads much more like you're punching a Web page. Then if you're punching an application. So like I saying, pull up your phone and see if you can find the two. I can give you some hens. Instagram. That's native Netflix. That's actually a hybrid app. In general, most of the applications you use are going to be native, and some of them actually have kind of a cross between the two. Facebook's a great example that uses native functionality and is a native application, but uses a lot of Web technology in HTML five in it. So Facebook's kind of on edge case, but the rest of them that you're probably familiar with, there's a very good chance their native so the inevitable question is which strategy is going to set you up for success with your mobile APP development studio. Do you go with one? Do you go with both or do you do something completely different? So I think that if I were a developer, I would say that Ah, hybrid application makes more sense. But as someone who runs a digital studio, I actually say Go with Native Now, the reason why I say this. There's a lot of different reasons, and I'm not 100% for Native. We have built hybrid applications, but I prefer native now. The reason I prefer native is directly to related to what I said before. The user experience is a lot better, and when you build a hybrid application, it's much harder to make it work the same way. It's much harder to bring in basic types of phone functionality into the hybrid application , and that's a problem with your clients. Clients will say yes, we want to go hybrid, but then you run into problems down the road, and a lot of times you can't reconcile them. It's hard to have beautiful design in a hybrid application. It's much easier to have beautiful design in a native application and that in turn reflects on you. It makes your perform will look better now, while it is nice to save your clients Hey, we can build Tuapse for the price of one. I have to actually gotten a lot of pushback from trying to sell hybrid applications. The main reason why that is, is because people are used to what they're used. Teoh. And if they ask you say, what do you prefer or can you give me examples of hybrid or native applications? They're probably gonna end up going with Native because most of the applications they're used to and they're mostly applications they're gonna make references to are gonna be native now. Also, from a financial standpoint, if you're trying to make more money per client or book more deals, it's almost better to go in Native. Typically, they're kind of rule of thumb, and this is something you should never quote me on because it could really, really range. Or the rule of thumb we use is that you build on IOS application and then you build a second android application. You can save a lot of the hours, maybe 2030% because you can share some of the Web server technology that supplies information. But in a hybrid application you can save usually around 70%. So typically, you know, if you spend, say, $100. This is just relative on IOS application. For the hybrid version, you'll spend another $30 to then port that over to Android and make it work on Android as well. So just in general, it's much easier to say, Hey, I can make you a native application. It's gonna look a lot better. Unfortunately, it cost mawr, but we could just build one application now and another one later. That's a better footing for your studio. It's a better way of making more money. It's also a better way of delivering a better user experience. There's only one example where I push clients towards the hybrid at PATH, and typically in those cases, the client fits three criteria. So the 1st 1 is that their application does not use really advanced technology, and their application does not need to access hardware like the phone like sending SMS or I need to access other applications that are on the phone. The second thing is when we have a client that's building a mobile application, and the reason they're building a mobile application is because they want to be on mobile period. So really, what they're just trying to build is more of a glorified extension off their Web application. You will run into people all the time. I have a shop. It's semi successful. I need to have a mobile application because other people have mobile applications. Typically, in this case, there's nothing specific that they want their mobile application to do that. A Web application can't dio. And then the last criteria is that the client is budget conscious. Because if you came to them and said, Hey, I can save you 60% of your project costs for the application is going to be worse. Um, the only person who's to say yes to that It's someone who's probably budget conscious. So in that case, I think it's OK to go with hybrid. Otherwise, I usually say Stick to native, but you know, if you wanna build your strategy around selling hybrid APS, it's quite a sales pitch. You just have to work with some technology limitations. Personally, I like to use native better user experience and you make more money on each project. So I think that aligns with your interest better. But it's really up to you to make your own decision. So if you guys have any questions posting the group discussion, otherwise see in the next lecture. 5. Build yourself or contract?: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk a little bit about Do you build something yourself or do you contract it out? Do you find someone else to do it for you? So you probably wanting to yourself eso Do I just build this myself? And you, after all, do know the most about yourself. You know exactly what you're capable of, so there's no real, like, a chance for a miscommunication. Now, this is obviously up to every single person, A lot of guys. I want to keep this small on. You want to do all of your own projects? That's perfectly fun. My advice, though, is that if you want to become efficient and you want to grow this at all or just maintain a much higher quality of life, I strongly suggest that you do not program 100% of the time. In fact, it's of my opinion that you can't run a Web development business if you're the only person doing the work all the time. So if you spend 100% of your time programming the sites and applications, who is going to be bringing in the new projects. When your projects over, what do you do now? Do you literally just have a period of time where you're just searching for the next contract? You have to understand that contracts. In general, it's usually like a burst of work, and then you have maintenance work, and then you have add Elin's. But those coming in much slower frequency and the amount of work is considerably smaller than the first chunk of actual work on the project. So let's accept the fact that you're gonna have a least a smidge of marketing and sales that you're gonna have to dio. And perhaps it's only at the beginning. So how much marketing or you know having to do? Is it 10% of your time? 20% time, 50% of your time? Let's say you spend 30% your time finding contracts in 70% of your time. Working on those contracts. Do you feel comfortable being the lead developer? Well, the person who's controls the entire project if you could only spend 70% of your time on that project. What if it's more like 50%? Do you really want to spend 50% of your time on that project. Now, the reason why development firms are so successful when they're founded by someone who is a programmer somebody was technical is because your expertise and your experience is gonna allow you to have critical insights and make much better project decisions during a project . Now, while you might be a fantastic developer, now that you're trying to build a business around this, you need to understand that what you bring to the business might not necessarily be your programming skill. By and far with successful development companies. The programmer, the original founder, their best kind of role is oversight. Now you can still program on a day to day basis, if that's the way you want to go. But realistically, you're gonna need to lay off just a little bit. You're much more useful to your project. When you're inserting your little bits of brilliance directly to a contractor or through management and basic project oversight. You are probably the magic combination that can use Lok lost contractors to build high quality products. And honestly, if you wanted to tackle higher quality products, mawr kind of premium side applications, you could work with higher paid contractors as well, and then convert them into a really high, high quality of product. However, in my opinion, since you're inclined to be technical, it might be best for you to focus on low cost options. So just be aware. If you're trying to build a successful development business on, you're trying to grow it, whether that's grow it in terms of better projects, mawr projects. Or maybe you just want to get to a position where you're more choosy about the projects you take in your still going to need to be very thoughtful about how you apply your time. You're in the best position to help the project. But if you're the person in the trenches doing the programming every single day, you're not gonna benefit from the synergies of bringing in someone else to collaborate with you. So you're more than welcome to try whatever you want. You can use this course in many different ways. There are lots of ways that could help you just as an individual freelancer. Expand your clientele base, expand your business base, but if you really want to be successful with this, you really want to see the true advantages of turning your freelance operation into a legitimate business. You need to consider taking time off of programming, focusing on oversight and then focusing on delivering value through that management. 6. In house hiring or out house?: Hey, guys, welcome back to the course. So in this section, we're gonna talk about whether or not it's worth it, to hire people as employees and to work with him in person. Now the vast majority of well known development studios out there, they'll have employees. That's not to say that they don't use contractors extensively, but they all do have some form of in house staff. Now that is what makes them resemble more closely a traditional company. They don't just distribute all of their employees over the world, even its sprint kick. We have a little bit of both going on. We have some full time employees, and then we have the majority contractors. Now, that's something that took us a very long period of time to get to, mainly because, you know, at the very beginning we didn't have consistent enough project work to hire someone for a yearly rate, as opposed to just paying them a project rate. We transitioned into that. So whether or not you make the decision to hire someone in person at the beginning, well, that's gonna depend on a couple things that we're gonna cover in this lecture. Now, First off. Let's do this backwards. Let's talk about the disadvantages of bringing someone on as an employee now. And I'm talking about graphic designer, a developer, really anyone or anyone that has to do with the service that you're offering through your development business. Now having employees and having a set static group of employees that makes it a lot harder to take on a wider variety of projects. If you're running a contract ID based development group, you can be a lot more flexible as to who you let go and who you hire so that you can take on a much wider variety of projects with employees. You kind of are stuck toe whatever skill set they have. So if you hire a ruby developer and someone comes to you and says they want the project done in PHP, you're not gonna able to take that project. Whereas if you did this contract, Chua Li, you could actually go and look for another subcontractor to do that. Now, obviously, if you have employees, you could capture that lead as well by bringing on another contractor. The difference is that if you do that, your other employees, the ruby on rails, employees still gonna get paid regardless of whether he works on a project. Another big disadvantage of hiring in House employees is it's It's hard to do, and it takes a long period of time. It's hard because there's a lot of paperwork. It's hard because there's a lot of hoops you have to go through. And it's also hard because because it takes so long for these people to get integrated into your team, it means it's very difficult for you to ramp up on projects. We have a big project come through the pipeline. You don't have the manpower now. You might not be able to service that with actual traditional employees. Also, if you have a project that grows in size or doing really well or your clients doing really well, it's gonna be very hard for you to ramp up to meet their new demand. Another reason is that recruiting is incredibly difficult. If you live in any of the tech hubs now, it's really, really hard to find people and to entice them toe work with you, mainly because there's so much competition for them. What ends up happening is you end up paying a much higher premium. A special if you live on, say, like the coast in United States, it's probably the same as well. If you live in any large metropolitan area, even in Europe or Asia, more demand means higher prices means it's a lot harder to recruit. Also, when you bring someone and it's a full time employee, you're kind of married to them. And kind of what I mean by that is that it's really difficult to bring them on really difficult to get rid of them. So you really is going to take something monumental to get rid of them. And a lot of times you just end up making a new, ideal decisions because the cost of changing the person or getting someone else is just too high. Another reason is that housing it's really expensive. That was some That was the biggest reason why it's friend kick. We opted to keep contractors on for honestly the 1st 3 years of the business in San Francisco. The stat I just heard was that per employee for office space per year is $40,000 so he paid employees $80,000. It's another $40,000 in housing. Now that's an extreme example. But housing is just It's an overhead expense that you don't necessarily need. And the last thing is that off hours air really expensive. Now let me explain to you the concept of what off hours are off hours are is kind of the in between time between one of developers working on a project and when they're not. Now there's a lot of time that happened. So at the end of the day, if they, you know, if they only have an hour left and they don't have something that can take an hour, that's lost time. If they're in between projects, you're bringing in a project. But it's not coming as fast as you thought it could be. They could end up sitting around for a week to two weeks. That's expensive because you have to pay them regardless of what they output. That's how basic pull years work. Now the advantages are a little bit more obvious. This is why lefties to the second part, your project quality and your ability to meet deadlines are gonna increase considerably. The reason why not only do you have a closer feedback loop with their employees. But because their employees, they're more willing to work overtime win needed and then to kind of balance it out other times because for them it doesn't really matter. They just need to get to create good products and to make their clients happy. They don't really care how many hours air billing. Another reason is that your ability to communicate increases considerably. So the ability to collaborate to come up with solutions to problems to come up with new project ideas that increases considerably, mainly because your communication lag is just limited. I mean, even when you're talking on Skype, they're still going to be some lag in between. Now, if you cut that lag in half, you can communicate twice as fast. Now the biggest reason I think that employees are a good idea if you're trying to build a development business is because they have no incentive to cut corners. That's the biggest drawback to contractors draw contractors. They're always looking to cut costs because they're either working on a per hour per project rate and they're only concerned about whether or not they get paid, so they're not always in it for the long term, they don't necessarily care about the finished product. They care more about billable hours and finishing the one section that their assigned so employees. They have a lot more on the line so they can step up when you need them. Contractors will if they're a good contractor, but there's much less likely to. So now, Either way, you can do it. You know, like I said before, the big Web companies, big Web studios, they all pretty much do most of it in house. But that's because their angle is that they're going for quality is paramount. They only care about quality. They want to make the best possible. They primarily work with people who don't even think about budget. If your product offering and your value proposition is going to be different than that, then you might want to consider contracting because that's gonna be a lot easier for you. Now. Everybody wants great product quality, right, and employees give the best product quality. So you would think if you want the best product quality, you take employees. So just like I said before, that only makes sense when you're going for always having that most quality in most cases, you need to create some combination. Contractors are much more flexible in that regard, so take a moment to consider what you want yourself. Do you want flexibility or do you want ability? In house, teams are invariably going to have an advantage on product quality, and contracting firms are invariably going to have an advantage on flexibility. If you don't have a project for your contractor to work on, it's not a big deal. They're in charge of their own product load. If an employee you run out of a product or a project for them, that actually is quite expensive. So do you see yourself as running this full time or part time? Is this something that you're more interested in cash? Or you're more interested in building a brand on establishing your reputation? If you care more about cash and you care more about the kind of the ratio, how much work you put into this to what you get out of it? I'd suggest working with contractors you're trying to do this full time, and you're trying to build this into something really big and you're trying to focus on your reputation, um, and getting a lot of publicity for the things you build. Then you probably want to focus employees. So just one more thing to consider. Make sure that whatever strategy you use aligns with you yourself and you, you in your goals. That's the most important thing. If you build this and it aligns to what you want out of it and what you're capable of, you're going to be the most successful. All right, see next lecture. 7. Keep the learning going: Hey, guys, I just wanted to say thank you for taking this class, and I hope you learned something. I hope what I said made sense. And I was clear. If you have any questions, any concerns, just posting the group discussion all respond to you. You could even send me a direct message if you want to. I want to give you a quick word of how you could take the skills that we learned in this class and how to bring it to the next level. Learn some other related skills. So in this class we learned how to position yourself for success as a mobile app. Development freelancer talked about things like Should you pick IOS or Android? She put native or hybrid, and we covered some other important criteria. Should pick going forward. Now, if you want to keep the learning going, I have other classes. I think you should check out. One of them is called creating cheap and easy online presence for freelancers. In that class, I'm gonna show you how you can pick out what targeted messaging you think you should use for your targeted clientele. Now to take that and then put it online in a professional looking website that's cheap and easy. Another way worth checking out is the art of the proposal. Now, if you're going out there and trying to find mobile clients for your business, you need to know how to make a proposal that seductive. That's interesting and more importantly, closes sales. This is something that almost everybody I know's a mobile app developer they struggle with . Okay, If you want to go further with your skills, check those out. Otherwise, again, Thank you for taking the course.