Best Practices for running a web development business | Evan Kimbrell | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Best Practices for running a web development business

teacher avatar Evan Kimbrell, Director at Sprintkick

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

20 Lessons (1h 47m)
    • 1. Welcome to the class!

    • 2. First thing to do

    • 3. Under promise, over deliver

    • 4. What is agile? Should I use it?

    • 5. Client budgets and what difference they make

    • 6. Web presence clients aren't worth it

    • 7. Price per project, price per hour

    • 8. Should you worry about competition?

    • 9. Beautiful design makes beautiful development

    • 10. Hedging your launch date

    • 11. Rich clients versus successful clients

    • 12. Running without contracts

    • 13. Red flags for bad clients

    • 14. Tell when you're getting fizzled

    • 15. Don't quote off the top of your head

    • 16. Is there a benefit to delivering early?

    • 17. Meeting in person

    • 18. Repeat customers are the best

    • 19. Avoid assumers

    • 20. Keep the learning going

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

When it comes to running a web development business you'll have to establish an online presence, grow and maintain a client base, create an amazing portfolio, and make sure that every single one of your clients leaves happy, bonus points if they come back.

Assuming you have a general idea of how to do the above (and if not I just so happen to teach other courses on them) this class goes on to cover a breadth of more advanced topics such as how to price your projects (per hour or per project), legality (contract or no contract), development methodology, and more answers to questions you might have when you first start out.

This course offers a nice mix of what I have learned in growing my own web development business, now passed on to you.

What you'll learn:

  • Use advanced best practices to maintain your businesses growth
  • Recognize red flags for clients before you start working with them
  • Figure out the optimal pricing configuration for your rates
  • Handle client meetings in person
  • Tell when clients are not likely to accept an estimate or proposal
  • Make long term decisions about which clients to retain and which to lose

What you'll do: 

This project is discussion-based. Have you ever been in a situation where you needed to use (or should have used) a best practice covered in the course? Share with us.

Meet Your Teacher

Teacher Profile Image

Evan Kimbrell

Director at Sprintkick


Hi, I'm Evan Kimbrell.

Thanks for checking out my classes.

Currently, I'm the Founder, Director of Sprintkick, a referral-based full service digital agency based out of San Francisco. Over the past 4 years, I've overseen the development and launch of over 100 web and mobile apps. Clients range from 1-2 man startups bootstrapping their initial idea to multibillion dollar Fortune 100's like Wal-Mart, Dick's Sporting Goods, & GNC.

Prior to Sprintkick, I worked as a VC for a firm called Juvo Capital, based out of L.A. I spearheaded the firm's expansion into the Silicon Valley deal flow and into the Consumer Web tech category.

Before working for Juvo, in the long, long ago, I was a co-founder for an educational software startup called ScholarPRO that raised a ton ... See full profile

Class Ratings

Expectations Met?
  • 0%
  • Yes
  • 0%
  • Somewhat
  • 0%
  • Not really
  • 0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


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 here, on skill share, I teach a lot of classes directed towards Web and mobile freelancers getting an online presence, finding clients, growing your client base, managing them, building portfolios. This causes a little bit different, and it's everything that couldn't fit into the other ones. This class is called best practices for running a freelance development business. What I'm gonna do in this class is cover a breath of more advanced topics. We'll talk about questions that a lot of you guys probably struggle with when you first started out your freelance development business. Such as How do you price your projects? What's the best way of pricing it? Hybrid per project per hour. We'll talk about legality. Will talk about contracts, will talk about running without contract. I'll even introduce you to development methodologies such as agile development. This class is kind of an eclectic mix of everything I've learned and developed over the last 4 to 5 years. Growing spread kick. If you're ready to take your freelance development business to the next level, I suggest taking this class I'll see inside 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. Under promise, over deliver: Hey, guys, welcome back to the course. So in this lecture, or talk about this kind of adage that has been going around in freelancer circles forever and it's under promise over deliver. So for those of you who were never heard this before, I'm gonna give you a brief explanation of what it means and why it's important. Then, after that, I'm gonna give you my take on it and to give you a little bit more of a nuanced approach to it as it applies to development. Business is now under promise over deliver. What it means is that it's always better when you're talking with a client to promise less than what you're capable of. And then when you actually deliver the project over deliver so as opposed to what ends up happening. A lot of times, people promise the moon, they say, I could do this and this and this and this could do it in this in a time, and they failed to meet those expectations. The opposite of it is a more realistic approach to always keeping your clients happy and focusing on customer retention. So that's what that really just comes from you always want to be timid with how much you can propose or promise, um, and then always just plan on either meeting. Those expectations are blowing them out of the water. Never plan Teoh, Um, at best make your expectations and most likely miss the mark. Now. Why, though kind of in general, is this good advice while in general, you want your project we built on realistic expectations. You want them to know how complicated it is, how big it is, how expensive it is because that's going to keep them in tune in sync, Um, and it's gonna give them the same priorities as you Now if a client thinks you're going to be delivering something that you aren't or thinks they're going to be delivering something that was never agreed on their unrealistic expectations. You want everybody on the same page because if that's the case, then there's not a lot of miscommunication. There's not a lot of puffery in the sense that you don't always have to try extra hard to impress that person. They know exactly what they're looking for and what they're going to get out of it. It also makes it such that you don't feel inclined, toe lie or embellish. If they know exactly how long this is going to take and you're completely honest with them , then you don't have to feel like lying about where your development schedule is or how quickly it's coming along or trying to hide the fact that you might if it snags. Now, if you fail to live up to your expectations of your client and you do that habitually on and you kind of built a practice around promising everything and then delivering always short of what you've said, well, you're basically dooming yourself to a situation where you spend a lot of your time looking for projects, Um, and not allowed here time working with repeat clients that is a very untidy, a way of running a development business development Businesses should focus on what they're good at making APS. They should not have to focus on constantly looking for a new fresh load of clients that have no familiarity with your company. So in general, under promise over deliver is a very good kind of mindset to follow and kind of ah, a rule to follow with regards to your clients and your clients work, but I think it's really important for you guys to understand that that does not cover all bases. When you're starting your business under promise over deliver that will get you zero clients. Remember, at the very beginning, your portfolio is going to be very small. It could be absolutely zero items. Um, your websites not gonna look as good as the final version of it. You're not gonna have as many contacts. You're not gonna have as many references. So getting someone to sign on the dotted line on contract That's really hard, right? And especially hard if you're being really pessimistic about what you can do for them and you're under promising. So now I've seen a lot of people use that kind of adage before under promise over deliver. They go into a business, and they try to do that the very beginning, and they just don't get traction. That's why it's important to understand why it's different when you're starting your business. Now you need to understand that any development project there's three things that you have the opportunity to exaggerate on or kind of under emphasize. Number one is cost number two is timeline and number three is expertise or ability. So in any given project, when we're thinking about whether or not we promised the moon, it's really along those three categories. How much is this gonna cost? How long is it gonna take us? And can we do this specific thing? So with regards to starting your business, let's go through those three. Number one. Do not ever exaggerate on your timeline. That's something that is true. The first day you start this business, and the day that you ring in the 10th year of being in business, lying about your timeline or exaggerate your timeline never works out in development. The timeline is just not something you can really fiddle with. I mean, unless you somehow have the magic ability to have people work 100 hours a week and think that your product quality is not going to go down. That's the only time I can think of where this would happen. You know, realistic circumstances. You can't dictate how many hours a week they work. And if you could, it's always tetra mental. So don't focus on timeline. The timeline is what it is. If they're telling you. That's not right. That's a ridiculous. They don't know what the timeline is. You can actually be having a problem because another one is trying to over promise their timeline. Now. The second thing was cost and cost is absolutely the thing you should manipulate to get more sales at the very beginning of your business, You shouldn't be focused on how much money you're making per project. You should be concerned about your portfolio items and bringing in good, long term clients that you can show off to other people. So cost is kind of your edge of the very beginning. It's something that you should be able to kind of flip which ever way you need if you have a project and they're looking at multiple vendors and this is very early on you, and then you can tell that they are trying to decide between them. It's very much a good idea to try and see whether you can manipulate your price downward to get to the point where they accept you as their vendor because at the very beginning you just need clients. You just need something to show off someone that can give you repeat business so you can get this ship afloat later on down the line. That doesn't really make sense. You shouldn't be competitive necessarily on price. Unless for some reason this is a fantastic project. That's great for many other reasons. So remember that at beginning just get some clients. So don't worry about cost, absolutely mess with your cost, you can always over promise on cost. Just make sure that you're not over promising so much that you're losing a ton of money. You can go into the red and you can plan to lose money on some of your projects. That's up to you and thats upto whether or not you're okay with that risk. That's a great way of getting clients. But it's not for everybody. Now. The third thing was ability. Now, ability just kind of refers to whether not someone says, Hey, I wanna have this feature and maybe you're not totally sure whether that you can do it or if they say you know I need something built in this technology and you're not totally sure that you can do it A lot of times someone will ask, I need is built on this platform, and I need to build it for iPad. But I also need to build it for, you know, some android nexus tablet, and you only do one of the other. And that, honestly, that has happened quite a bit. Uh, and it's one of those things that you might consider that over promising by saying, Hey, I can do this one and the other one because remember, you know, I can get that project unless you could do both of them. So in general, that's considered over promising, too. But the way that I typically suggest people handle it is that you just kind of hedge your bets at the very beginning. Clients are really, really, really important, at least the first couple ones that you get. So you might b'more inclined to give them some kind of flexibility, or at least to make some kind of a promise of adding some new technology that you might not have right this moment. But the way that you do this correctly in the way that you do that's in a nuanced, intelligent way is you don't ever say I absolutely can do this. Just say you know, I could build it for this platform, and I'm very confident I can build it for this platform. And then you just basically say, But if for some reason I can't this is realistically what's going to happen. So in that second kind of contingency, what you can do is you could try to soften the blow and say, Well, if that's the case that happens, I can lower the price for you Or You could just say, if that's the case that happens Well, it's only something that's gonna take me another month to figure out a lot of times you'd be surprised. People don't even care about that. They they could be really happy about your price being lowered. But they also don't even really care that's gonna take an extra month. They're more or less just concerned that one vendor deals with Mawr of their project, and they're not gonna have to work with multiple vendors for different technologies. So don't ever say 100%. Absolutely, I'm doing it. It's done. Expect it done, say I'm confident I can do it, but realistically, that might mean it takes a longer and if for some reason I can't do it Well, then we'll lower the price of a project. That's something that works really, really effectively. Okay, guys. So in general, we don't. When in doubt, go with under promise, over deliver. But in the very beginning of your business, be realistic. I mean, only one of those three things that you can manipulate is not is unmovable is something that is just insane to move. And that's timeline. You could always manipulate your cost. Feel free to do that. In fact, actor, that's one of your strongest tools to get clients at the beginning. And the other one is just, you know, ability. Try to be realistic about it. Never promised 100%. But be confident and tell them you're confident that you can add additional services, even if you're not sure you can. That's how you close clients at the beginning. And that's how you get this ball rolling. If you guys have any questions posted the group discussion. Otherwise, seeing the next lecture 4. What is agile? Should I use it?: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk about what is agile. So what is this agile thing that you might have heard up? So you might have heard of it, and you might not have heard. If you know what agile is, you even used it before. Skip this lecture. Save yourself some time. I'm gonna cover very basically what it is, what you should know about it and whether or not it should apply to your development business. Okay, So the best way of explaining it with regards to a project is to explain that there's two ways of delivering a product. The 1st 1 would be to have all of your specifications heavily a project requirements built up front. You analyze them, given estimate, and then you build the entire thing. And at the very end of a big Harada, you pop champagne and the projects done In that scenario, you deliver the application in one big final piece, and then you go and do feedback rounds where they say, Fix this, fix this change this change this. Now the alternative is what's called agile in Angela. What you do is you work on separate chunks of the application and you deliver each one at a time and then go through feedback grounds. Now the way that you do this is by listing out tasks and features and then trying to figure out how long each individual feature or task is going to take. Then what you do is you take all of those features and you gather them into essentially what are bundles, and each individual agile methodology has a different name for them, but with scrum, we call them sprints. You can also call them iterations, but they're basically burst of work. So maybe we have 100 different features will bundle up these ones into eight because they're bigger ones and these ones into 12 and these ones into 20 etcetera, etcetera, and then we'll tackle each individual trunk of work at a time. Now, with Adroll, what you're focusing on is making each individual chunk of work or sprint or iteration and making whatever you build in that section fully tested and ready to be deployed by the end of that session. So in our scenario, we do sprints, and so what we'll do is we'll take features for a two week sprint, the end of the two weeks. Everything should be fully designed, fully tested, and if we deploy it, it should act as if the whole thing was finished in Andhra. When you post a big chunk of work, nothing should have dependencies on other sections of the application. Everything should deploy as if it's 100% done now. Typically, a truly agile team will develop with a designer in pair, and the designer then will design as the developers create requirements. So traditionally, what you'll do is you'll do one. A big design. Once that's OK. Then you'll go and actually develop button. Agile and traditional agile, you'll have a designer who designs as it's being developed. Now there's some obvious advantages to that. The designer will only spend time on requirements as they're needed, and also it allows them to be more flexible. As things change, they can change it on the fly. So that's the basics of what agile is. It's a very, very, very basic thing. A lot of people even specialize and teach courses on agile. That is just a crash course. Now the way that this applies to development businesses is, you have the option of following an agile methodology and then offering chunks of work to your clients having multiple feedback grounds, depending on which chunks been done, as opposed to having one big Harada the end of your project Now here it's spring kick were obviously big fans of agile, and that's what we use. He didn't actually caught on. Our name is Sprint Kick. It's just a play on words because we delivers breads and Sprint kick is just another way of showing acceleration or speed. Now, as a project in general, Agile has a lot of benefits. It's generally faster, and in general it's gonna deliver code that's better produced and better tested. It allows you to reassess your project mid progression and make any changes along the way that you need Teoh. It's a much more flexible, modular way of looking at a project, and that's probably why most development teams out there use some form of this methodology . And that's probably why there's so many courses on you to me about running agile teams. But what's the biggest reason why this is a good thing for a development business? Well, agile and building your project an agile way makes it a lot easier to sell. Now. When you estimate out your project, you can do it in an agile way, which means that you estimated out in hours hours are much more transparent, and they're much more digestible for the client. Hours in general also are much harder to argue with. A client can say $500 is too much, but they can't say four hours is too long. What you can do, then is you can apply individual early estimates, every single task that allows your client to visualize how big the project is, how big certain sections are and taken. Really. Just do an ad drop, pick which ones they want and drop the ones they don't. The biggest benefit, though, is that you can, periodically, during the project deliver code that's 100% fully deployable and tested, and allow your client to actually play around with it. Now if you did this in one big batch, that means that your client just big writes you a big check, goes to sleep, wakes up in a couple months when it's done, but with agile, they get to see it progress during every single iteration, every single sprint. They get to see visual reinforcement that your project is progressing. What's great about Agile is you can say this individual chunk of work because I've done an itemized estimation, is going to cost this much. But you can. Also do is you can also say, since we're building out in chunks, we'll only charge you for this first sprint at the end of the sprint or iteration or chunk of work. What you can say is, if you're not happy in anyway, since it's fully deployable, fully tested and it's done, you can take that code base and have an easier time integrating that with a different firm or different contractor. In general, they don't really need to understand the deeper code base, at least, especially at first. Now we've never had that actually happened to us, but for your client to know that there's a way that they can back out that's a big problem , and a big worry that they have is that they can't ever get out of a project once they know it's going to be a disaster. Being able to show off your work every two weeks also allows you to tell much earlier on if something's wrong with your project and whether or not you need to make a pivot or make some serious changes, it saves everyone time, and it saves you from running into some really hard project decisions down the line. If you miss something early and became a big problem, so should you use agile well. I strongly prefer using it because it's easier to sell. It's easier to show your clients that is exactly what you're paying for. This is when it's going to be done, and it also makes the whole experience more interactive, with more transparency. And in general, I've experienced it makes her clients a lot happier. Now, if you need to build this into your system, how do you go about doing that? It's actually quite simple. The vast majority of developers and subcontractors out there know how to build, at least somewhat in an agile fashion. Now you don't need to follow agile traditionally to the tea. What you gonna simply do is say, we need to follow a basic, agile system, build out individual features, deliver those features and just follow a basic path of chunk of work, chunk of work, chunk of work. Now, any true clients not gonna know whether or not you're doing traditional scrum or traditional extreme programming, they're not going to know that All they know is that you're delivering and chunks, which is essentially the same thing. So if you want to do agile, look for contractors that have experience with agile and make them know that this is how you want to deliver the project. This is how they should be doing their estimates. And this is how they should be timing their updates and their check ins. Okay. And if for some reason you guys want to become an expert and agile, there's a lot of great courses on it, they could teach you all about it. Probably more helpful if you are developer or programmer yourself, but also quite educational. If you're not all right, guys. Any questions posting the group discussion. Otherwise, send me a private message. Seeing the next lecture 5. Client budgets and what difference they make: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk about client budgets. What do they mean? Why are they important now? A lot of you might think that why is a client budget important? Which would be important is whether or not I could make a margin on it or not. It's something that I can make very easily or do very well now. While that is important, all those things are important. Trust me. There's the things that you need to have a healthy business. Also important to work with clients that have good budgets. This is one of the biggest differences you'll notice between established firms and new firms. New businesses typically will work with clients that have budgets that are all over the place. On oftentimes will work with people that have budgets don't fit their project needs. Prior, more established companies often have the opportunity work with companies, been around for a while, used to paying what it should be. You know what they should be paying for a project and have had the longevity to stick around to see successful projects work and so have been able to kind of re invest and probably have some sort of a war chest to draw from now, you obviously want to get to that second thing I just described. You wanna start working with the cream of the crop kind of clients now? The reason why bigger budgets or healthier budgets, or at least proportionate budgets are important is because of the project's success. In general, bigger budgets make better projects say that 10 times fast, it's very important. A bigger budget can pay for better graphic design. It can pay for you to research problems. Come up with novel solutions. It can pay for wind. Things break. It can pay for additional features. It can pay for a complete pivot away from the original concept of the idea into something they found out is more successful now. A dead project is on Lee as valuable to you as the dollar amount that you pocketed from it . That's very important. If you make money off a project and then it fails, it is a literally just the dollar amount you made out of it. That's it. A successful project is a fantastic portfolio item. It's something that can constantly give you leads It's something you can constantly show off, and it's the shining star in your portfolio. A dead project is kind of hard. It's hard to show it off. It's hard to use them as references. It's just, in general, a dead end. In general. You want to be building your business around mo mentum. You want to do projects that not only help you now help you land your next project. You want to focus on this being kind of a snowball effort. You want to start with projects. They will help you get better projects in the future. A project that fails is going to be a project that doesn't help you improve in the future. So focus on budget budget is typically the primary problem. Obviously, bad entrepreneurs will be hard to work with, and they'll probably make the product quality suffer. But in general, any bad project you make will probably be because you are hamstrung by the amount of money and time you could spend on it. Too many times in our history, we've had to build maps that are just awful. They fail and they could have been successful had the client had more budget for us to at least push them through other it orations of their idea. At the very beginning, you can't obviously be picky, but try to focus on the ones that can actually be realistic about the money that they have , Um, and how to apply that towards making their project successful? Try not to focus on clients that just have enough money to make it work because those ones that have a high likelihood of failure and that is just a project that doesn't help you doesn't help you moving forward. Try to focus on things that push your mo mentum forward our guys. Any other questions? Posting the group discussion budgets are very, very important. There's a lot of things we could say on budgets. That's the biggest take away. I think you need to know is that bigger budgets, better projects, better portfolio, better success rate, all that successful projects are good. That's a lot of people might think that that's not something that you should worry yourself about. Once you push out the door, it's no longer your child. You'll notice. Successful development firms are focused on client success and project success beyond their actual scope of development. Alright, guys, seeing the next lecture 6. Web presence clients aren't worth it: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk about a best practice that revolves around looking for the right clients. And I call this one. Look for clients that have depth. What I mean by that now, I don't mean look for clients that have really rich personalities and deep wells of knowledge. Your clients could be a shallow, as you want them to be. That's not what I'm talking about. I'm talking about their projects. Look for clients that have projects that are not only ambitious but actually have development depth to them now, you might think to yourself, but it's so easy to find someone who wants a custom WordPress theme installed. Yes, that's great. Yes, that's money, and I'm not discourage you from doing that. You have to understand that has a place when you're starting your business and you go after any client, you can a word someone who's doing a very basic one off project like doing a WordPress theme installed. That's fantastic only at the beginning. Now, that type of client that I'm describing is what I call a Web presence client. Someone is a Web presence, client if someone is not necessarily in the business off making their own application there just in the business of getting a website or a mobile presence application. Those are typically people who literally just want a website to display information about who they are with their company does, or to announce an upcoming product or something along those lines is a very large portion of development projects out there that fall into these this category. People who just want to say Hello Internet. This is something to represent whatever I'm doing, who I am and it's up online. Now there's multiple problems with Web presence clients being your main crop of clients. First of all, remember when I said that in any given development project, design is always smaller than development, and development is always the largest by far portion of the money spent now with Web presence clients. You're really kind of testing me on that rule because in a lot of cases, the design is actually more expensive than the development that is the biggest exception to this rule. These projects, typically from a development standpoint, are not very deep. There's something that is very easily put onto a platform very easily catered Teoh from a website like Squarespace or Wicks or Shopify or WordPress. Very easy to go after these air clients that typically aren't looking for adding complexity . They don't have any new ideas that need to be made. They don't have any custom specifications or any algorithms or new features or really anything out of the ordinary. They're just looking for a flat pages that do very, very basic common functionalities. So one reason why they're bad clients is that there's a lot of competition for what they're trying to do. It's very hard for you to compete with another company that's out there that spending millions of millions of dollars to create a platform that can do everything for them. The second thing is that they are often people with very, very small budgets. It is almost always the case 90% of the time that after you do a Web presence, clients work. They have nothing else for you to do. That's generally not something that you want. Remember, we're trying to escape the cycle of constantly looking for new clients because that sucks up a lot of time, and that time you don't get paid for. You want to focus on finding clients that stick around for a long time because that's where they really get profitable. That's where you really get kind of the juice out of this relationship. So where presidents clients, even if they stick with you for a very long period of time, you don't actually get the benefits of retaining a client. Even if they do have work, it's typically very small, and it's often off just a distraction. It's like you have to take a developer who's working in a larger project and say, Hey, this client needs four hours of work done that is just hard to get into. That's hard to make money off of, and often it's a bigger detriment to another project. So in general, try to focus on projects that are trying to expand, try to focus on projects that have some sort of novelty. The very beginning. You're perfectly fine bringing on Web presence clients. They were great for your portfolio, but when your portfolios full, we're past the point where you can display them anymore. You need to start looking further down field looking for people are trying to build applications, trying people, trying to build things that actually have some uniqueness to them. And more importantly, they're gonna be people that bring back significant chunks of work over the long term and not just bring in trickles of money and trickles of billable hours. That's a strategy that's just not sustainable. Even if you're a solo freelancer, you can fill your plate off of these Web presence clients, but you're never gonna grow this into something that's ideal or better than the situation you're in. If you stick with this client type questions, comments, concerns, complaints, anything you disagree with me posted in the group discussion, otherwise see in the next lecture. 7. Price per project, price per hour: Hey, guys, open back to the course in this lecture. I'm just gonna talk real quickly about how do development firms get paid. So if you've never contract it out with a development firm or with the freelancer, this may be completely new to you. So there are two primary ways that a development firm and also development freelancers get paid. One is price per hour, and two is price per project. Now there are other ones out there on, and a lot of times we end up working for things like day rates or hybrid rates. Those air kind of abnormal, and that's not something you're normally gonna run into. And it's really not something that you're going to really worry about, probably in your first year of running a Web development business. So price per hour is exactly what you think it is. It's when you charge per hour of labor you put into the project another way of calling. This is time and materials. So instead of say, estimating that a project is going to just take this amount of money, what you typically end up doing is give a projection of how many hours it takes and then you'll just work on the project and bill afterwards. Now, in a lot of cases, really well known, well established firms they can charge time and materials and not even given estimation. Well, they do is say this is our per hour rate. And then if you engage us for this entire project, then really only worry about is building after the fact. So after they spent 100 hours of 50 hours will send you a bill, and then they typically will use something like Net 15 or Net 30 to get paid. Now, the other one is price per project. And basically, what that means is that you take a chunk of work or a task and you give an estimate for the entirety of that task. So that is regardless of whether or not that task takes you 10 hours or 100 hours or 200 hours, you're gonna make an estimation. At the beginning, you're going to say that price. The client's gonna agree with you, and then you work on it, and then you get paid based off of whatever agreement you have for when you get paid, maybe get paid up front maybe get paid at the end. Maybe it's split out over milestones, so now they're obvious pros and columns for both of them. As a development firm, you're almost always going toe. Want to work on time and materials on? The reason why that is, is because one of the biggest headaches of running a development firm is that your estimations are not always correct, and it's almost impossible to get an estimation that's accurate every single time. Why are estimations hard to predict? Well, because a lot of times you just don't know everything that goes into a project, and it's impossible without spending an enormous amount of time up front to figure out how complex each individual issue that's included, two in a project is a lot of times you look at something and say, Oh, we can do that 10 hours. Once you actually get into it, research it, try to actually do it. You run into a bug and it ends up taking 30 hours. This happens to quite literally, every developer in the world. Every development firm in the world has trouble estimating up front under a time and material agreement. The communication between you and the client. It's so much easier. All you have to say is this has how long it took me and that's really it, because you've agreed to just pay for your time. And ultimately that's what every single freelancer or development firm wants. They want to be paid for their time. So obviously, the cons of setting up a time and materials way of getting paid that it's harder to be competitive with time and materials. You can't really bid against other people. You almost always have a per hour rate on, and it's hard to change that per hour rate and then have them kind of believe you when you say all of a sudden this developers Onley worth $30 an hour, as opposed to before when you said he was worth $50 an hour. The biggest condo is actually on the client side. Clients don't generally like time and materials because they like to be able to budget up front. They like to know exactly what this is going to cost, and they also like to know that if anything goes wrong, it falls on you, the development firm to figure it out and keep it within budget. There's also this kind of general anxiety about what happens if my project really gets away from us. Um, what happens if this project you said, Oh, I think it'll be 100 hours ends up being 1000 that could break in organizations budget, and a lot of them really aren't there every single day, so they might not notice when it's about to go outside of their budget constraints. So on the flip side, you can do price per project. Um, it's obviously a problem for you is the development firm because you're gonna have to bid up front for exactly what you think it is. You know, if you're smart about it, you can hedge and say This is what I think it will be. But with more research and more information, it might change. You can say things like, you know, this is the range that I think it will be once actually spend more time on it than I could get more specific. One of the biggest problems I think for development firms is that if you're giving out price per project estimates you, it's been a lot of time estimating that up, out, like right at the very beginning. You know, if you're doing five estimations, each one could take you 2 to 3 hours. You just sucked up two days of someone's time. You end up spending 15 hours of time estimating, and you don't even know which ones they're gonna win. So regardless, you're gonna end up wasting time, and that is not what you want to do at all. Now, the obvious advantage to a project price for you, the development firm, is that you could be more competitive about it. You can lower your price to bid out other people. If you know you have a specialty or you're better at building something that someone else is, then you're gonna have an inherent advantage when you give them a project cost. You can just, you know, if you know it's gonna take you half the time to someone else to do it. Because you have expertise. You have ah, ready to use code base before you have a project you can use pieces. From then you can outbid that person pretty effectively, and you yourself still stay in budget. Now, like I said before, there are other ways of doing this. Here it's spread cake. We use an agile methodology. Basically, what we say is we given estimate of how many hours each chunk of work is going to cost, and then we have a price per chunk of work. So, really, it's kind of like a hybrid were really kind of bidding per hour, but then giving you an hourly estimate on then. Typically, what we do is we say, You know, here's an early estimate for this section, and we'll cover it if it goes above this amount. So keep in mind, though, also, that when you start, you're probably going to have to use price per project. That is usually the pricing scheme that any development firm or freelancer uses when they're first starting out. When you don't have this ready to use client base that keeps coming back and back from or work you can't be is picky, so you kind of have to give them what they want, especially a lot of times. If you're working with a client that's never worked with you before, they're probably going to expect a price per project estimate. Unless, of course, they came from a really warm referral or something like that, in which case they might be willing to give you the benefit of the doubt and to use it a price per hour. So biggest takeaways here is that when you start, please expect that you will be doing probably a little mixture of both. If you're lucky, you'll do price per hour or time and materials, as we call it. But realistically, you're gonna have to doing a lot of price per project estimations. And that's really what you're gonna have to use to leverage your costs and your time to get the best price to get the best projects. Over time, this will get much, much more. Koshi. You'll start using more and more time and materials on all of a sudden, a lot of your headaches associate with project management and budget management will pretty much go away. 8. Should you worry about competition?: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk about a question I get all the time. Which is, Should I worry about competition now, in the traditional business, you would have a product offering you would need to examine your competition. You need to be concerned about how saturated your market is, and you need to be confident that there's a market opportunity that isn't gonna be swooped up by some other company now specifically to development businesses. When people ask me, should I be worried about competition? The answer is always unambiguously. No. Why is that? Well, because there are an immense amount of development businesses out there, and there's almost an infinite amount of development work out there that needs to be done that's being developed on a day to day basis. It is. There is a mind boggling amount off development firms and a mind boggling amount of work that's out there that's constantly being produced and needed. Now, why do clients pick development firms? They picked them typically because they can match their expertise. They have a good reputation than a good portfolio, and they can build a relationship to them now, one of the biggest problems. The market. When it comes to development firms, is it highly fragmented? It is virtually impossible for one company to compare another on an apples to apples ratio . If one company says, you know, this is our proposal, this is our timeline. How is it possible that the person that that client could even know about whether or not there's a better proposal out there from a better company, even on the other side of the world, the market in general just lacks transparency? And that's because every single development firm is just different, and every single client and what they need is also very, very different. There's always an infinite number of configurations in terms of what you could offer as a development firm, an infinite number of configurations that a client ends up needing At the end of the day. Clients care about referrals, and they care about their relationship with they're contractor. There is no company out there that can dominate the entire market and steal all of that from everyone, because again, the number one thing that care about is something that's established on an individual basis . We have so many different technologies out there, so many different projects being created, that there's almost infinite numbers of opportunities to create a development business and create a offering and then to go out and find those projects and connect yourself with them . So no, don't worry about competition. If you had to worry about competition, your head would explode. You couldn't possibly take into consideration every single move, every single decision, every single change of every single competitors. Because no one even knows how many development businesses there are. There are two who many. And honestly, if you're not the right fit for a client, it's kind of like they say client work in this situation is like a bus. If you missed your first bus, there's always another one coming. So don't fret. You can always find the right combination with right client. There's unbowed ending amount of work out there. It's so much so that it's not even worth really worrying about competition. The only reason why you should even keep an eye on what people you perceive as competitors or people are in a similar space is merely because it gives you a great opportunity to emulate what they're doing. I could give you ideas for how to improve your service, give you ideas for areas to move into techniques. Best practices. Use those competitors or perceived competitors as a way to improve yourself. But that's literally it. Don't front about it. Your market potential is built off your ability to find clients, keep good relationships and keep really good business fundamentals. If you focus on that, you're going to grow. You're gonna find more clients. Um, and it's virtually impossible to ever run into a situation where competitors stealing all your business or markets too saturated. It just doesn't happen in the development world. All right, guys, see in the next lecture. 9. Beautiful design makes beautiful development: Hey, guys, welcome back to the course. So in this lecture, we're going to talk about something that can severely hamstring your portfolio and something that, when addressed correctly, can dramatically improve your product in project quality. Now, a lot of times you have a project that you'll work on. That's big. It's grand, its ambitious. It's interesting from a technical perspective. You put a lot of work into it, and when the product launches, it is just not something that you want to show off. Now, I'm not talking about something that you might have botched in some way or something that you just don't really like. What it's about I'm talking about. It's a product that comes out. It's just not very impressive. It looks like it's from the nineties. It's something that just doesn't look like it's trendsetting or something that might reflect a high quality application. Now, a lot of times, the copra in the situation is the design, and since this is for developers or people starting development businesses, that is technically something that might be outside of the scope of your control. Now this is a problem. It happens to developers all the time you work on something, it's great, but the designer is just not up to speed. They're not high quality, and it ends up making the app look bad. We control Al the functionality of the application. We control everything that happens below the visual layer. But customers, On the other hand, they see the visual layer first and only the most acute. The most experienced ones even pay attention to how complex the back end interactions are. Simply put, ugly user interface is ugly to everyone. Ugly code is only ugly to the developer that's looking at it. So if this is a problem, you're having you having a lot of cool projects. But none of them are really port fully a worthy or something. You really want to show off its because of design. I have a couple of tips for you to how you can fix this. So keep in mind, great design makes a great portfolio. The first thing you can do is take into consideration who is the designer. When you make a decision toe work with a client, take some time to actually look at who they employ. Look over the designs coming from and see if you can request this up front now. I'm not saying that if it's bad design, it's not a project you should take on at all. But I am saying that you should take this as a factor in your judgment about whether or not this is a client you want to work with, whether not this a client you don't want to work with or the weather not to client you really do, and someone that you want to put a lot of pressure on or work really hard to try. Teoh create a contract with. So take that into consideration. Asked them who it is, asked to see the designs before you get them. Another thing you can actually dio is to keep a list of all the designers who have you worked with or ones that you admire that you think make good, reasonably priced design. And when it comes to that point, would Chris remember? You are usually contract ID after the conception stage and potentially after the design phase, introduce that person as an option to your client. A lot of times, clients are also not happy with their design or they simply don't have the design. So if you introduce someone you know, creates high quality work, you're setting yourself up to work on a project that could actually be shown off. Now the last option is to offer design services yourself. There's a lot of reasons why that's helpful and why people like that a lot. Find a designer that you work with. Well, try working with them on a couple projects to find out very quickly the ones you really like and the ones that you can work with for a long period of time. You might even consider not making a margin on their rates because remember, whatever they design is going to be the face of anything you develop. So if they're really, really good, it shouldn't matter to you. You're getting a lot of benefits just from working with them. If you have a top of the line designer and they're up on trends, and there's someone that puts a lot of thought down to the every pixel, what they put together, anything they produce and anything you then subsequently develop is going to look great. Doesn't matter how ugly or how clunky your programming is. It could have been one of your worst projects ever. It's still going to look good, and it's gonna look good to 99% of the people who see it. Now that is true. And you know, in the reverse scenario where you have great development, ugly design, what we already covered, that that's terrible. You have to remember that clients are at the end of the day customers and there no real difference between them and their end users. They still look an app, and they see it, and they see it just the same way that any old, uneducated users going to see it. So take this into consideration. Bad design, It always gets hidden away, and you never get to show it off again. It's just a valuable is the dollar amount that you put into it. And great design can honestly really change how many leads you get, how many clients close, how great your Web presence is and how great your portfolio is. So if you're running into this problem, try to tackle it in a variety of ways. Make sure you know who the designer is. Make a judgment on whether or not you think they're a good designer and decide whether or not that's a client. You want to take on you considerably. Open up your own network of designers and use them as an introduction to your client so that you can know that someone you've worked with before is introduced in the project. Now, you can also go as far as to do what we do and have your own designer and then include them in any development package that you dio that gives you additional benefits as a service. But it also allows you to know exactly the quality of the design that's gonna come down the line for you, um, and then put into your portfolio. Alright, guys, questions on this post in the group discussion, otherwise seeing the next lecture. 10. Hedging your launch date: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk about hedging your launch date, which is a strategy you can use with your clientele that can save you a lot of headaches and making process go a lot more fluidly. So I always like to think of a project timeline like a car trip you take from point A to point B. Except in this car trip. A lot of places along the way from point A to point B. There's a bunch of hidden landmines. Now there could be 100 landmines or there could be one or two. Or maybe there's even zero. You might hit all 100 you might not hiss single one. The point is, even if you're fantastic, a calculating how fast your car drives and how far the distances from point A to point B. Um, and if you've driven this route before, it all doesn't really matter, because you can't really calculate how many landmines they're gonna hit. Um, and each one of them could take up a day or two of your time. People will get sick services that you use for information there. AP eyes will get taken down other companies you use for information their services will go down. People you rely on for assets like a graphic designer for design assets or outside of your business. They could be late. All of the stuff. It happens all the time. Now. The only way that I found you can consistently avoid the fallout from missing a deadline because of some of this issue you couldn't possibly foresee is to head your launch date. Okay, so let's take an example. Say you have a project. It's a month on project and it's launching on July 1st. Now is your client launching their product on July 2nd will? Probably not. So why say I'll deliver the product on July 1st when you can easily just get away with saying I'll deliver it the first week of July? Now, it sounds sloppy to say that, but you would be surprised how few people actually care whether or not they have a single day that everything's going to be delivered. Now. Remember, the sticklers for timeline are typically the clients that are gonna be unrealistic about the project that are probably going to be headaches down the road so had your bets plan on hitting at least a couple landmines and again, landmines being any issue that could blow up and take a couple days of your time that you couldn't possibly have foreseen. So if you have the option to say a specific date or a range of dates, always pick the range of dates. Even if you think you know exactly the day you're going to deliver it, your future self will. Thank you immensely. How is this possible? Well, deadlines and development projects are very rarely set, the only time anyone ever cares if you're giving a timeline that takes at disproportionate amount of time or it's unrealistic, Lee Short. That's the only time something is a huge problem. The difference between launching on July 1st are launching anywhere from July 1st to July 7th is absolutely minimal. So head your launch date, say, the week of July, say the weekend after July, say July 1 to 2 or July 1 to 4. But the point is, though internally, then plan to launch on July 1st. You just gave yourself some significant breathing room that can save you in a pinch. And remember if your client is specific about it being delivered on July 1st and not July 2nd, your client probably sucks. Your client is probably a bad person, so it's not someone that you really want to have a long term relationship anyway. All right, guys, you just want as much as you can. What? A lot of people don't realize that deadlines are often kind of up in the air. You can set the tone, and a lot of people are perfectly fine with there being a wide range. Even if they ask you why you could say well, potentially some issues should could could arise. So use that to your advantage. Alright, guys, questions posted the discussion otherwise seeing the next lecture. 11. Rich clients versus successful clients: Hey, guys, welcome back to the course. So in this lecture, I'm gonna talk about a distinction you should make with your clients, which is rich versus successful. Now, this is a big problem that I had when I first started this development business. I often would go after clients that had big budgets, and I thought that should be the number one thing I should be looking for more money, I thought meant better projects. I thought it also meant that I'd have more future growth options and that hopefully they could refer me to other people who are just as rich now that I've had quite a bit of experience running and growing. A development business, I realize, is a very important distinction that should be made. Some clients air rich and some clients are successful. And kind of what I learned was that you had a position yourself to align with this client that is successful. It has a track record of being successful. Whereas if you just focus on rich clients you Jack, you're doing yourself a disservice. Now. A rich client simply has lots of funds. You don't know where they got the funds that could have inherited it. You don't know what they did in the past to produce those funds. Just the existence of funds does not mean that this person can create more funds in the future. It's very possible that they had a very high up position in the past, and whatever that was is completely irrelevant to what they're doing now. Now a successful client is completely different. This is someone who has a track record of successful projects. They're not just someone who has a gigantic budget. They have a portfolio of their own, so to speak, and you can tell that they consistently pick ideas that have actual potential to them. And they have shown that in the past they were able to take things and do something with it . Now a rich client might be really hands off, and they might be a really enjoyable client toe work with. But just in general, these air, not the types of clients that are going to grow your business rich clients might create large projects. But those large projects do not have a very long life expectancy. It's much better to work on a medium project that goes on from multiple years than a large project that fails right out of the gate. A successful client is gonna launch something that brings you consistent business consistently for a very long period of time. They're gonna refer you to similar people. These are the types of people that in the future they'll raunch separate ventures as well, and they're probably going to be a similar level of successful. If you look at this from a portfolio perspective, it's really important to take into consideration how successful a client's been in the past , because the best portfolio items are companies that are out there, who that are actually doing well, getting customers and getting seen that dramatically increases the value of report folio. Someone looks at your portfolio and they see something that actually recognize that's a huge, huge plus how many development studios out there have a portfolio or have an application they've built that you actually recognize. It's probably a very, very small percentage. So guys take this into consideration. You should be vetting your clients just as much as their vetting. You is your client, someone who has a very large budget, but you have no idea where it came from. No idea whether or not they're going to be successful. And you have no idea if six months from now the project's going to stick around, focus on clients that have a track record of success. Try anything you can to hitch your wagon to them because they're gonna bring you a lot more money in the long term and a lot better referrals going to bring you the mo mentum that can allow you to grow your business. All right, guys, any question posting the group discussion Otherwise seen the next lecture? 12. Running without contracts: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk about running without contracts. What happens in the scenarios where you didn't sign a contract? You're still making contract work for one of your clients. Now, this is the type of scenario that will eventually happen. A lot of you out there are gonna try out your development business as an experiment and you might not want to put a lot of time up front into making contracts. Now, that's not a huge excuse if you're taking this course, because we have contracts at the very end of the course and the resource is section that you can literally just plug and play your information. And we would have a lecture that explains how you get them signed Elektronik Lee Really easy within 10 minutes. But for a variety of reasons, it might be tempting not to sign a contract. Maybe the work that you're doing is incredibly small, and it's just not worth it. Maybe it's someone that you worked with in the past, and so you feel like you trust them. Or maybe it's like a friend and family type situation where you feel like a contract might be kind of a rude thing to do, and it signals that you don't trust them. It could also be the case that you are trying to close a client, and you're worried that sitting them a contract might actually scare them away because it takes an extra step and a lot a little bit more time. But it also makes them have to come to terms exactly what they're doing and paying for now running with contracts. It's never ideal, and I strongly suggest you don't do it. I suggest you focus more time figuring out ways to make contracts easy and get them signed quickly. That's a better time investment trying to figure out how you could do damage control after you've got an entire project that has no contract. Okay, but if you do insist on going down this route, I have three things that you should keep in mind that will help you quite a bit. So number one don't ever do this with someone that you've never worked with before. And not never was someone who hasn't paid you before. That's the key there. Ah, lot of times people think, Oh, I've worked with this person before, but in reality they've worked with them, collaborated. But they've never changed money. That's important. An important distinction. You can figure out pretty quickly how trustworthy someone is, how creditworthy they are by having a cash relationship with them. Once you've established that, you can pay each other and you see eye to eye on projects. You know the chance of you having a miscommunication is significantly slimmer. And if you're working with someone that you've never traded money before with people's behavior around, money is very, very different than the way that they behave around projects that don't involve money number to keep a paper trail as much as possible. And what I mean by this is, if you're gonna do this, try to force all of your communication into something that has a record. Try to put it all into email. When you do do email, try to be as extensive as possible. Try to take screenshots of updates. Take screenshots of changes to the application so you can show on day one that looked like this on Day two. Looked like this. Put annotations, try to keep his much paper as you can, because later down the line, if something does happen, this is the only thing that's going to stop you from being in a situation where the other person says none of this ever happened, not Number three. When you are communicating with them, make sure every opportunity you have to include costs and features. Always list out everything you're doing. You make sure this isn't the written record, and you make sure there's a record of your client seeing you say it's gonna cost this and do this and them Agreeing to it now doesn't necessarily have to be explicit. They can see the cost and see what you said you're going to do for them. And, you know, just by virtue of the fact they didn't say no and they continued on with the project, that is an implicit agreement. At the end of the day, if you need to go back, written records are going to save you there a little bit sloppy and they're a little bit tedious. But hey, there are a lot better than nothing, right And again, you are trying to save yourself some time by not writing a contract, which would have saved you all of this trouble. So in general, if a problem actually arises and you get caught running without the ball, so to speak, running without a contract, I wouldn't worry entirely as long as you followed those three things I just covered with you. If you do have eight, an extensive written record of conversations and transcripts and places where you list out exactly what you're doing and they agreed to it, then you're in a decent position. Obviously, you're in a weaker position because you don't have a contract where a signature is pretty explicit that they agreed to it. But for the most part, you actually do have a solid foundation In virtually every jurisdiction, at least in the United States, any type of verbal agreement in writing is virtually the same thing as a contract, and any judge or court is gonna look at it the same way. The only problem with them is just that they're so sloppily put together, they're very hard to prove what exactly someone meant by this or is a contract is completely unambiguous. So I wouldn't completely fret if something happens at the end of the day. Written contracts are still the law and the fact that you have documentation showing that they agreed to something that's pretty much all you need, but it's not advisable, and it's really not ideal. But there are certain scenarios. Were running without a contract might be an okay thing to Dio. Now, keep in mind any long term project should always have a contract, no matter what the absolute minimum. Just have a contract saying that you're being hired to do some work for them, and this is roughly what you're going to dio. At least you can do that to show that you're in a contract ID relationship and then anything after that is just work that could be considered addendum or additional work. At that point, there's really it's impossible to do. Then I that you are not in a contract relations with this person. They have not willingly agreed to bring you on in some kind of a paid position. Now, remember, if you're using one of the online platforms like the Lancer up work, they have their own contract written into it, and they use their own escrow services on those scenarios. Don't worry about it, okay? guys, If you feel like running without a contract, you don't have to worry two months. Just keep in mind some very basic things. Focus on having a written record. Focus on Onley. Doing this with people that you traded money with and focus on in your written record being explicit as possible, listing things out and getting verbal. Agreement your snot in a huge amount of trouble. You're just up for something. What? It's more of a headache down the road. It's not really the end of the world. It just might be more time consuming than it would have been otherwise. Alright, guys, any questions posted a good discussion, although I see in the next lecture. 13. Red flags for bad clients: Hey, guys, holding back to the course in this lecture, we're gonna talk about red flags for bad clients. How can you tell beforehand whether or not a client is going to be a nightmare town, the road and whether or not this is something you should steer completely clear of now your quality of life as a project manager as a developer, um, as the business owner has really gonna depend on the clients that you end up working with, Some clients are fantastic. They just get it. You learn a lot from them. They're easy to work with. They always have the right budget. They always respond on time. They're very forgiving when anything happens, and they understand that some things are outside of your control. Those people are great. They make this so much sweeter because you're getting paid toe work with people that are great. Now, on the flip side, you will run into some difficult clients clients that are a nightmare. Clients that have a lot of expectation issues, clients. I have a lot of authority issues. You run into ones that are immature ones that are completely unprofessional. You'll run into ones that have trust issues and ones that just take forever to get anything done. So to help you recognize some of the tell tale signs of a bad client, let's go over some common scenarios or some common things you might look for or start to notice. So Number one, um, this is it, like I see all the time. Do they disagree with your estimates? Now that is something that's very, very strange in the development business. You know, if you're buying a shirt or buying something on the street, someone might have the potential to disagree with the price of something. Maybe they sought the same price somewhere else. But in development, this is not a commodity. We're not selling you a glass of orange juice. We're selling you something that's very, very complicated and very, very technical, something that's very, very complicated and something that's almost always very much customized to your individual case. It's also the case that in development projects, unless you're the one doing the estimate, there's no way you could possibly know exactly what it's going to take to build something. So if a client is disagreeing with your estimates, saying it's wrong, saying one sections too large. That is a generally a big red flag, and this is why I put this is number one. A lot of time you'll have this happen. You'll have a client who is not even technical trying to say, Oh, that didn't take as much time. We have this problem a lot with graphic design, and you I design because you I designed Sometimes it just takes a lot of time up front until you get a general design theme or a layout, and then they use that to build the other pages faster. But that first batch of work, we always get people saying No way. That took X amount of hours the fact that your client even thought that they could make a judgment on how long that took and they could go so far as to say that it's wrong. Huge red flag steer clear. Number two Does their project idea make no sense? Now here's one thing I want to say is that when you're in the development business and I say this frequently, you're not in the business of picking winners. If that were the case, you'd be in venture capital, you be an angel investor would be somebody who hops from start up to start up. You're not in a position to make a decision about whether or not their market opportunity is good enough or they're not their execution capacities good or their team is a fantastic set up. That's not what you're doing. You're here toe build whatever it is they want and do the best job possible. But since you are putting a lot of time thinking about it estimating it, you should have a decent idea of whether or not this idea is terrible or if it's OK if it is the case that they're giving you something that just doesn't make any sense whatsoever. You couldn't possibly imagine why anyone would use it or it's something that's completely derivative of something else. Usually that's a red flag now. It doesn't matter if they're copying something else that happens all the time. But if they're trying to make something that just flat out makes no sense, they're talking about users using it in a way that can't work or any general kind of disconnect. In that sense, this might be a project or a client. You might wanna steer clear. The reason why is because a best case scenario, this is a one off project. They build something, it goes out there. It completely fails because a person's unrealistic or un insightful but what they're doing . But the worst case scenario is that this bad project idea is indicative of a bigger problem . Is probably a bigger problem has to do with the client themselves. They probably just have a whole lot of bad ideas, and you're gonna have to deal with a lot of bad ideas later down the road. There's no reason to think that they might have some bright ideas to fire you in the middle of the project or to bring up issues that don't even exist. Number three. Are they trying toe haggle with your rates Now there's a big difference between haggling and just saying I cant afford something. No, make that a distinction. If they're coming up to you and you're saying, you know I need $25 an hour, $50 an hour to do this and they're saying, Well, I'll pay you 15 or trying to do a Lobel pitch. They're haggling with you. If someone comes up to you and says, Oh, I can only pay for 22 an hour on I really want to work with you That's the case that they just don't have the budget. Those air, two entirely different things. You have someone coming up and saying, No, that's not worth it. I'd rather pay you this and they're giving you a Lobel. That's haggling. That's a big red flag. If it has ever happened to you, remind them that they're paying for wages. They're not paying for an object. They're not paying for something that you can mark down at will. If they pay you last, that means you pay your people last, which means they wouldn't want to work on the job. So why would you take it? In general, I'm not very accepting of haggling at all. It's awful. Some people out there do, and I personally think that diminishes their brand considerably. So if a person comes up to you and they're haggling over the price of your project, take that as a red flag. It generally means that they're unrealistic about the project. They've never done this before. They're not being particularly professional, and their priorities are probably out of whack. They probably only care about the price. Nothing else. Why would you ever haggle with a long term partner, someone who is in a take charge of very important project that has a large impact on your life? It makes no sense you'd under pay that person. It's also indicative of someone who doesn't have a budget. A lot of times people don't have a budget or just trying to see how low they could get the price. So if they're honestly worried about the hourly rate, they shouldn't be talking to you. Generally, that means you're just about to waste a lot of time with someone who doesn't have money for the Project Number four. Are they giving you multiple proposals at once? Are they asking you to give you an estimate for this application and this application and the whole about two other applications? If that's the case, then you might have a scatterbrain client who's probably not committed to whatever project they pick. To make a project successful, you need to spend a lot of time and effort thinking about the project, developing it and making the concept is bulletproof is possible if you're all over the board with multiple proposals. It means that they're just scrabbling things down on a napkin. And even if they decide to go with one of them, who knows how, honestly, how committed they are? Because they certainly are not focused. That just smells red flag. For me, that could be an issue down the road if they get distracted on something else. So they decided to divert. The resource is over here. You want to work with someone who's at least serious about what they're doing. Number five. Do they argue over trivial items? I've had clients argue with me over fought sizing. I've had them argue over text in their contract. That doesn't actually mean anything there conditional clauses and their with their contract . I've had people argue over what we call projects internally and how he's tell them. These are all trivial things, and basically, that means is you have someone that isn't able to prioritize, isn't able to figure out what's important, and they're more concerned with getting their way or proving themselves in some way. Typically, that's just a sign that you're working with a client. Use insecure and immature, probably don't have a large track record of success. People are successful in development. Projects are not the type of people who nit pick things that just simply don't matter. Also, to be completely honest, that person's gonna drive you crazy. So do you really want to work with them? Number six. Are they being unprofessional now? This one's pretty, plain and obvious. You should know exactly what I mean. Are they the certain person that has a tendency to throw tantrums of the turn person who has a tendency to say things they shouldn't or do They often lie about things blatantly. There's a lot of different things that would be very unprofessional. Do they constantly miss phone calls that you scheduled very basic things. That's another pretty big red flag, means that they can't possibly have been successful in anything else they've done. Who knows how they got the money for their project? Whatever they're gonna put their name on and put their effort towards probably is gonna be dead in the water. You shouldn't subject yourself to that. It's just not worth it. OK, so those are the biggest red flags I've seen with clients there, Some other ones obviously, um, that you could easily think of. These are the ones that I think kind of fly under the radar and are more important, at least in my experience and experience with the other development businesses that I work with. You guys have any questions or anything? You want to comment on any ideas for other red flags you've run into or you want me to say whether or not something is a red flag posting the group discussion? Otherwise, I'll see in the next lecture. 14. Tell when you're getting fizzled: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk about efficiency saving techniques and things that can help you identify whether or not your client is just not that into you. So what I call this lecture is tell when you're getting fizzled. So I call it fizzled. Just simply because something that fizzles is something that bubbles and then just slowly dies off. Now getting fizzled in regards to development means that your client is not interested in the project proposal you've given them, and they're slowly disconnecting and slowly kind of backing away. Now, this isn't happen all the time. You can't win every single contract. This is the natural reaction of someone who looks for a proposal and for whatever reason, does not like what they see now. Being able to tell whether or not they're doing this to you can save you a ton of time, especially when you get to a point where you're juggling lots and lots of proposals. You really don't want to waste your time or your developers time working on proposals that are going towards someone who's actually in the process of fizzling you. So first to help you understand. Let's talk a little bit about why they might be doing this to you. There's a lot of different reasons, and it typically has to do with one of several sections in your proposal. It could be they don't have the money for this project. It could be that they are not actually a serious about completing the project. As you think. I might have actually gotten to a point where they are not actually confident in the idea anymore because it's gotten so complicated. And a lot of times you have potential clients who just finally get to a point where they feel like they're in over their head. And then, lastly, it could be possible that they're looking at other offers. So maybe there's another vendor who clearly just hit the mark much better than you did. They're slowly gonna back off and start going with that vendor now the moral. The story here is that when people start this process, it can go on forever. So you need to cut your losses as soon as you recognize this is being done to you. Seriously, I've been fizzled for like six months before on clients and wasted hours and hours with them. And in retrospect, is only when I realized that they were doing the same things over and over that I should have noticed there were pretty much big red flags showing to me. They're not actually interested. So here, four things you can look for to see relatively, whether or not they're slightly out the door or if they're still actually enthusiastic about the project. So the first red flag is what I call pyramid conversations. So, like a pyramid, it starts off with the bottom that's large and it gets to the top. It's really small now. How I relate this to development is these are the type of clients. When you first start talking to them, they give you tons and tons of information. But every subsequent communication you have with them, their communication and the information they're giving, do you get smaller and smaller and smaller and smaller. They start off with a page of inv O. The next one's very enthusiastic. Maybe it's 3/4 of a page. By the time they're done, they're responding and singular sentences. Now, this is not the sign of a client who is simply run out of things to say. This is a sign of a client who's lost enthusiasm in you. This is what they're doing when they themselves realize that you are unlikely to be the person that they go within the firm that they go with, and they're slowly backing off and minimizing their resource, investment and time investment in you. Now, why don't they just cut off entirely? Well, because a lot of people still think they can get information out of you. They still would like to ask questions. They would still like to use estimates on a lot of them. They want to use that toe, anchor it against another firm they're actually going to work for. But their language never lies. Their commitment to you should be pretty obvious if they're using pyramid conversations Now . The 2nd 1 is slower and slower response times, even if it's two questions or tidbits of information that are really trivial and really standard. So at first you might see that the client responds within an hour within six hours within the same day. But over time you start to notice that it's like three hours and it's like 10 hours. Then it's like a couple days. Then it's like a couple weeks. You're getting fizzled. Basically, that's the same thing. Another way of displaying it is often happens with pyramid ization. The client is basically just backing off, spending more time on other people. But they still feel the need that they should respond somewhat now. One foolproof way to kind of tell if this is happening without having to calculate your email response. Time is T Look at the questions you're asking them. If you're asking a really simple question. When do you want to start the project? What do you do? Have a logo? What's the name? Basic stuff? Um, and it takes him a long time to respond to that. That means they're not serious about you. It's not the case that they're taking time to research these questions because they're trivial. They should be able to respond within the same amount of time that they use beforehand. So clearly they're backing away number three, repeatedly asking you to clarify or re answer questions you've already answered. Now this will happen all the time. A lot of times people ask a question you give them an estimate, and then they'll start asking you questions about the estimate. You gave one kind of telltale sign that they're trying to back away or slow roll. This is they start asking you the same questions. Really, This is kind of like a symptom of, you know, if you're talking to someone and they're also talking to three other people, they might not realize that they've asked you the same question. That's essentially what's going on here. They're either too distracted by other people, and they're asking the same question because they forgot what they've asked. Or the question you're answering just isn't sticking with them. And the really unconfident in your answer. And in general, that is unconfident in you and the number four, using vague timelines and referring to things like decisions. Now this is another one. Someone who's serious about you is gonna want to capture your business, so they're going to be definite as possible with regards to their timeline. People who are overly vague just saying, Oh, we're gonna do it in a couple months, we're gonna do it in the fall Q. Two things like that. That's when they're being overly vague. Typically If they're interested in you, they'll give you a month or they'll give you an actual, like, hard deadline with some different milestones. First, this is gonna happen. This is gonna happen, and this is when we want to start. Another thing that often comes along with this is when people refer to decisions. Lawyers say, You know, in a couple of months we want to make a decision or they'll say they're going to refer it back to other people and we're gonna make a decision later. Taboo. That just is a way of off loading kind of the guilt of not picking you. They'll just say, Oh, it's it's up to the decision making gods. It's up to my partners to say No, really, they're just backing the way There really were interested. They would never say, Oh, we're going to make a decision. They would tell you that they're interested. They would indicate that they're interested and they never say something like that. So watch out for that one, just as much of the others. Okay, so those are four ways you can kind of tell if you're getting fizzle. Try to use your intuition a lot of guys. They're pretty good at this. And, um, it's kind of a scale that you've developed over time. People do this outside of development as well. They do it in relationships. They do it in any professional like setting or scenario. You just kind of have to be aware of things that are kind of projecting towards you. Hey, I'm backing away. You do need to be aware, though, that a lot of people will continue working with you because they think they can get information out of it or I don't even know. Sometimes they'll just keep it going for no reason. So it's really important to notice that they're doing this and get out. Okay. Any questions group discussion, private message may otherwise see in the next lecture. 15. Don't quote off the top of your head: Hey, guys, welcome back to the course, so we're gonna have a quick lecture on something that a lot of people who run a development business make a mistake with. And that is, don't ever quote off the top of your head. Now, this is something that you might not imagine right now. But when you start getting into, it happens all the time. Such and such will say, I want to build this in that and they will ask you on the spot. How many hours do you think this will be? A lot of times you'll say, Oh, I don't know. And they'll still press you. What range of hours do you think it's going to be? This is something that you should almost never, ever do. Even if you're really experience with giving estimates, just don't do it. The upside potential is actually quite small, and the downside is quite large. Now. The biggest reason why this is a problem is because if you try to give an estimate and then later on, try to give a full estimate back to the person chances are you probably missed something or the client forgot to mention something which happens all the time, and then the estimate you give them is going to be different. That's a bad scenario. 90% of the time. If you give them a second estimate, that's not even within the original range you gave them. You're gonna lose that contract. Why? Just honestly, it just makes sense. Even if you believe that person really tried their hardest to give you an estimate, you came back to them and they give you a different one. What would you think the price was higher than you would assume? That they're trying to rip you off its lower. You just assume that they're an idiot and they don't know what they're talking about. They're just throwing numbers out at random. You don't want to lose authority and you don't want to lose your position as an expert, so just don't do it now. One thing that keep in mind is that it might frustrate the person you're talking, Teoh. But be realistic. No other development firm is going to do that. So it's not as if you're the only person sticking them. If they're talking to five different companies, none of them are going to do that. And if one of them does that one is taking on some serious risk. So it's not as if you're withholding information they could get from other people. You're not putting yourself at a disadvantage. You're pretty much doing the industry standard. The best way of tackling these situations is always say, you're not sure, but I can give you an estimate in a short amount of time. Then you need to rely on the framework you've established to give a ballpark estimate. We cover that in a separate lecture. That one is so incredibly crucial. Toe landing clients focus on getting that framework done so that you can create ballpark estimates. Worst case scenario, you could just give them a full estimate and a full proposal. So best case scenario is you might make them slightly happier with you. And worst case scenario is you block them off from ever being your client and you come off looking like you don't know what you're talking about. Now it might be possible that you run into a scenario where you absolutely just have to answer the question some reason or another. If that ever happens to you, do this don't give them a range with two ends, give them one end of the range that is usually enough to satisfy them. So as opposed to saying, Hey, your project's gonna take 1000 to 1600 hours to build. Say it's going to take over 1000 or under 2000 or under 1600. Basically, what you're doing is you're kind of hedging your likelihood of getting the estimate correct . And if it ends up being that you miss it just shyly than you might adjust the price to still capture the client. That's enough information. At least give them idea of Hey, this is big or hey, this is small, which is really all they want if they're being really, really pushy about it. Okay, So regardless of how well you think you know this project, there's still information you're missing, and it's just a gamble that's not worth it. The upside isn't very good, and the downside is quite bad, so don't do it. Don't quote off the top of your head. This is something I get stuck with all the time. I still make this mistake, so try to avoid it as much as possible. worst case scenario. Gun gearhead. Give him one open ended range and don't give him the other number. That should at least increase the odds that you don't shoot yourself in the foot. All right, guys. Questions posting the group discussion. Otherwise seeing the next lecture. 16. Is there a benefit to delivering early?: Hey, guys, look back to the course. So in this lecture, we're gonna talk about what's the benefit, if any, of delivering your product or your project early. Now, a lot of you might have thought what I said under promise over deliver. That might mean, for instance, giving a lax timeline and then delivering it early. Now, while that is an example off over delivering, that just gives you the wrong impression, Unfortunately. So let me just answer the question. Just delivering early benefit you in some way. No, not really. And if it does, it's very marginal. Personally, if I have the option of delivering early, I actually will work on the project Mawr internally, do more testing doom or deep dives. Try to fix mawr bugs that might be cosmetic, spend more time on it and deliver on the deadline that I promised. Now, why is that? Well, just in general, when you tell someone this is the deadline, not only do they plan for that deadline, so if you give it to them early, it might actually just sit for a couple days. So you're not giving them more time to the organization. Any real benefit really the only benefit to giving it to them early is that you appear is if you're a good vendor and that is really about it. But it no practicality. There's very few benefits. In most cases. We're talking on delivering something early. Maybe it's a week early. Maybe it's a couple days early. It's not gonna really matter if you give it to them on July 1st, and they're expecting on July 3rd. What exactly are they going to do in those two days? If you save the money or gave them an extra feature or did something really well, that is important to them that affects their bottom line. Delivering it early doesn't really actually mean anything to them because that time they didn't plan to use and they probably don't have anything they could use it for. So if you have the option of delivering early, maybe you overestimated. That's great. Spend more time working on the project, trying to spend a little bit more time on like bug testing and making sure that when you do give it to them, it does have kind of a wow effect. So there's usually a good thing. It means you're efficient means that you give yourself plenty of breathing room. So take that time and really perfect the project. And keep in mind I did. There's really no real benefit to delivering early. It's not like a lot of other industries. All right, if you have any questions about this, any examples has ever happened to you. Were you ever thrilled that you got a project back early, just posted a group discussion, let me know otherwise seen the next lecture? 17. Meeting in person: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk about meeting your clients in person. What should you plan for? How should you tackle this? Now, if you are using a substantial amount of contractors in your development business, you know that you can run your entire business without ever actually meeting your clients. And in my experience, the majority of them never actually come into our office or meet any of us. Why? Well, really. It's just because today people are more used to working with people through Skype or email or using like a sauna. It's also the case that you might be working with a company on the East Coast. You're on the West Coast. It's unrealistic that you're going to come visit them unless it's a multi $1,000,000 project. And for some reason they really wanted that. Even if I'm in San Francisco and companies in San Jose, it's pretty unrealistic to think I'm gonna take an hour and 1/2 to go take the train down there to meet with them for whatever reason. But in general there are two reasons why you might meet with a client in person. One is that you need to meet them to close a potential sale. Client wants to meet you because they want to see what you're like. They want to see how quick on your feet you are, and I want to see you explain in person what you did with your projects in the past and explain your portfolio or explain your approach to their project. Now the other thing that could happen is you're working with a larger company. Um, and they just have a culture around meetings and meeting in person. And so for them, it's actually a considerable hassle to change everything. Toe work on Lee exclusively with you through Skype or through email. So occasionally they expect you to come in to help them deploy or explain something that's going wrong or to do basic check ins. Now, in general, if you have the opportunity to meet your client person, I do suggest doing it at least once. It really does help establish a bond between you and them. They know you on a personal level, and it's not just an email address that will really help you retain clients and have them feel more confident in you, they feel more confident in you. They give you a lot more leeway for everything you're gonna dio now, like really anything. Your success with a meeting in person is really gonna come down to your preparedness, your composure and your confidence. Now your preparedness that's really gonna come down to how well you could anticipate what they want and what the context of the meeting is. Your composure has more to do with your personality in general and your experience having meetings like this And then confidence really just comes down to whether or not you feel confident you could answer their questions, how technical you are or how proud of your portfolio you feel like now. I obviously can't help you improve your composure and clear of your confidence. That's just something that's gonna come with experience and that's going to something that comes with you trying out different things, Um, and being willing to fail. That's one of the things that I think really will help you de stress before meetings. Just understanding that, you know, not every single client means the world to you and that it's really, really hard to screw up an in person meeting, so I wouldn't necessarily stressed out about it. It's very hard to screw up. And if they do, if you do end up doing that, it's not the end of the world. So now if you are meeting with someone for, say, like a sales pitch, the thing you need to focus on is being able to present your past portfolio items. Being able to explain what those apt to do, how long the project took you could even say how much it costs. Being able to demo it in some way will help immensely as well. So whether or not that's you coming with a bunch of pretty defined links that you could just talk through or if it's a power point that helps you talk through different things, it's really up to you. And it's really up to your style. I personally kind of just wing it. I usually will bring all my portfolio items and because their portfolio items and I spent a lot of time on, I could just talk about them for days and I can show them everything, and I could tell them funny anecdotes about the project or tell them. Why the project successful or why it's interesting or yada yada yada. It should come naturally to you if you are actually part of the project. But if you're type of person that needs something more scripted, try to put some things down on a power point slide just to help you walk through it. Now, the odds of you using that presentation and I'd actually be small, but just knowing that you have that prepared will help you immensely. The other part of an in person meeting for like a sales meeting is that they want to know on a personal 1 to 1 level, you understand what their project needs are. So you need to focus more on being empathetic, toe what their user problems are connecting with them on what problem they're trying to solve and help them understand that you get what they're trying to dio. In general, this is not a time for you to dictate and tell them what they should do with their application. You should absorb their vision, their idea, their project requirements and insert your insight and your wisdom when you can. It's okay to be quiet during these meetings, because you are listening to them. Don't try to set the tone by being way too pushy or authoritarian. They're not heared for a strategy consultant, necessarily. But they are looking for someone who is an expert in making awesome products, so they want someone who can, at the appropriate times, insert some information. Tell them that Oh, that's not gonna work or tell them Hey, this is an interesting idea you could try out Now If you're trying to meet with someone in person or company in person simply because it's a check in, you need to value a couple things. One. Is it worth the client contract? If you have to meet them, say twice a week, it's a big contract. Has promises that there's gonna be a lot of work in the future that maybe it's something you should dio. Also, if it's a company that just naturally does that, they just naturally operate in meetings. Then you're gonna have to adapt to them. And it's not them making you jump through hoops because they don't value U. But in general, if it's a smaller contract, you're not need to the portfolio item. Maybe reconsider. Try to factor that into your margins and try to calculate what's the loss in terms of your time and how much time you could have spent on other things as opposed to traveling and then meeting in person of these people. Keep in mind a lot of these meetings are incredibly redundant. Just in general, there's rarely a reason that you have to meet in person with someone. There's nothing you can't fix through a phone call or an email or through project management tools. But if you do have to end up meeting with them, try to minimize how often you have to meet with them. Try to make it. Is communion as possible? Most importantly, try to be positive about it. So and in general. Regardless, what type of meeting is always be prepared to talk about yourself, but if it's never brought up, don't focus on your client and your client's needs, and only if they ask you. Then be ready to brag about yourself and talk about all the great things you've done before and what your teams capable off. Now something that will also help you is that if you're not technical, you're not a programmer. try to explain to people how your process works so that when you don't have, say, estimates on hand or ability to answer deep technical issue questions, they actually understand why that is. Try to explain to them Hey, this is how we typically work. I deal with this portion. This is This is why I think this is not working. But if you give me this amount of time, I can get back to you very easily. It might be a little frustrating, but if you explain why it is, they can't really be frustrated at, You know, the last thing I think that's worth covering for in person meetings. This is something goofy that everyone always asks. What do you wear? While the best advice I can give you is to be like a mirror, try to mirror whatever the group is you're going to and how they dress. They're going to a fancy bank and financial district. Try to dress in a suit. If you go to that meeting and your under dressed, it might not work. The reason why you want a mirror. What other people do is that people just naturally again notice patterns, but Also, they have a tendency to trust people that look like them. So a banker who wears a pinstriped suit is probably gonna trust. A Web developer also dresses in a suit with pinstripes. If you walked into that meeting wearing foot flops in a hoody Mark Zuckerberg style, you might stick out so much that they're going to spend more time thinking about why you don't fit in and less time thinking about whether or not your proposals any good. Now the opposite into the spectrum is what if you go to like one of those start ups those San Francisco startups, Um, and where everyone is dressed in practically pajamas. Now, if that's the case, what I always say is there's always gonna be a bare minimum of professionalism you should ever drop to and with regards to your dress code. If you're going to one of these places, it's always worth dressing up a little bit more than them. Try to go with something more casual, but you're never getting it blamed for wearing something slightly nicer. No one's gonna kill you for wearing a button up with jeans, and in fact, you'll find that it probably doesn't even stick out at all. But don't ever get so low that you look unprofessional. A lot of companies are ultra casual because when they're working in the in their work environment, they are trying to impress anyone. You, on the other hand, pretty much are, and honestly, the rule here pretty much is it is long as you're confident you can probably pull it off, try to match what they wear. And if you don't know what they wear, try to pick something in a happy medium that's professional, but slightly relaxed. No one's ever gonna fault you for that. And, you know, going forward now. You know? Okay, guys, if you have any other questions, you want me to look over your wardrobe and tell you if you look ridiculous, posted the group discussion. Otherwise I'll see the next lecture. 18. Repeat customers are the best: Hey, guys, welcome back to the course. So in this lecture, we're gonna talk about repeat customers Why they're so important and why they're so awesome . So now, if you were looking at this from an outside perspective, you might think was it haven't seen a new client and a repeat client, right? They probably pay you the same rates. They probably have the same projects. What could possibly be the difference now? Actually, there is quite a big difference now. The reason has to do with the economics of how you get clients and how you maintain clients . Now, it's a pretty simple concept. When you're looking for new clients, you spend a lot of time upfront before they pay you a single dollar that time you spend is not going to be reimbursed. This is time spent running your advertising campaigns, reaching out to people, talking to people, answering their questions, estimating their projects, negotiating contracts, getting them to sign contracts, following up with them, then finally starting a project. Now, if you signed 100 our project, um, it's completely reasonable to think that you spent 10 hours upfront getting that client. Also, you need to take into consideration is for that 100 our project. You probably also chased after four or five other projects that you didn't get. So if you spent any similar amount of time on it, you could have easily spent 50 hours looking for projects landing one that gets you 100 hours. So that's literally 1/3 of your time wasted on something that doesn't make you money and doesn't make you better at what you're doing. Now repeat clients or the complete opposite of that. If someone comes back to you, they've already selected you. You don't have to sell them on anything. You sure do. You have to give them an estimate. But you know, the likelihood of getting that project is very, very high. You're essentially streamlining the process with them. You cut out the fat out of the process and you focus on development, which is what you make money off of and what you're actually good at. Repeat clients are also a good indication that you're doing something well, because if they're coming back to you, it means they're satisfied with your service. Those of the people that are gonna be the best for referrals. Ah, lot of prospective clients will give you referrals, but those don't have the same weight as a repeat client will repeat. Clients can say my project that's up and it's alive. This is the person that built it for me. That's a very strong referral, and that's a referral that's going to convert into a sail quite often. So in general, if you're trying to grow your business, you need to focus on mo mentum. One of the moment, um, killers in this business is constantly having to try and find new clients. Here it's Branca. We only work off referrals because we put enough time and work into our network. We don't have to go out and look for clients anymore. This is the ideal range we waste barely any time on things that don't pay us. That allows us to be more competitive on rates that allows us to be better at what we dio, and that allows us to have more of a margin to spend other places. So focus on the things that give you the best. Our ally for your time, focus on the things that are going to give you the best referrals, but that's gonna allow you to build momentum that's gonna allow you to grow your business, and that's what we're going for. Okay, guys always try to focus on keeping your clients. That's the sweetest deal possible. It also is a good barometer of how well you're doing with the business in general. Repeat clients means you're doing something right. You guys have any questions posting the group discussion, otherwise seen the next lecture. 19. Avoid assumers: Hey, guys, welcome back to the course. So this lecture, we're gonna talk about the worst possible potential client you could ever find. And there's someone that you need to avoid, like the plague there, the people we call the assume er's now one of the biggest problems in development in general. Is it going to be talking with people who are not used to the level of specificity that's required to run a successful development project As a result of that? A lot of them think it's okay for them to speak in very vague terms and to make generalized comparisons that are very unspecific and very unhelpful. Now, this is something you're going to see all the time people use in precise language to describe something to you. Your job is gonna be able to help them take that information and break it down into something that's actually specific and precise and actually describes a riel application. Now, assume Er's are the people that speak in vague terms have an idea in their head or image in their head, and they just assume you know what they mean. That's why we call them assume er's now assume er might say, I want you to build this piece or this feature like this and we'll refer to another website , and then when you build it and you build it the way that you see it working the same, they'll say, No, I thought you understood that. It also meant this in this in this These are the types of people that we use really vague comparisons will say like Facebook or like this feature. But you don't know what piece of that feature or what piece of Facebook, that gigantic platform they're talking about. A sumers use things like loaded sentences. They'll describe something to you that sounds really simple, but there's a lot of things hidden underneath the sentence that when you actually go to develop it, you really could struggle, not give you an example on assume. Er might say on my application. Clicking this button sends an invitation to their friends about the application. You build it exactly that way, they press a button, sends it to their friend, um, and then, you know, it just says click here to sign up. Then when you deliver it to them, they say, No, no, no, it's actually supposed to click this button, open up your contact list, pick someone from the contact list and then send them a pre formatted email that also includes multiple other options. That's what an assume, er does they just assume, since they have no experience working in development or working with contractor Dwork, that if they just say it does this, they just assume you think the same thing they think in general. Just look for people who use overly vague language. If you do see that kind of think of it like a big rock that you need to break it down and get them to agree to the individual pieces, they say shares an invitation. You need to say what happens when I click the button? Does it change animation? Does it pop up, visit text, message them or does it email them in the email? What does it need to say in the email? Are there any graphics? You just need to get every little bit of actual specifics out of them, Um, and then you can at least agree on something. The biggest mistake you can make is just to agree to something vague. I've seen people who work for development firms or freelancers who agree to build multiple hundreds of hours on a project. Um, for something that was described in a paragraph that's crazy. I've seen people take projects where the description was camera app that allows you to take photos like Instagram. What in the world does that mean? There's so many things in instagram and so many things going on in their camera section of their app that how do you know what exactly to include and what not to include? And how do you know what part of it to customize and what not? You need specificity, So try to avoid the dreaded assume, er, as much as possible. These are the people that are really gung ho about the projects, but everything they tell you is really vague, and they packed tons and tons of features and functions into every single sentence, and they probably don't even realize it. These people are generally just lazy and pretty much they're all over the place, so be careful. Try to break down what they're saying into individual estimates, get them to agree on it, but try not to accept work unless it's very specific, and it has at least a medium amount of basic kind of documentation or instructions. Okay, guys, try to avoid these guys seriously. They're the biggest headache you'll ever have. It's purely based out of inexperience, that it's purely based out of them never having done this before, specifically with development contract firms. 20. 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 in this class. We covered the best practices for running your online freelance business. If you want to keep going with your learning and learn more skills and more ways to run your business, effectively, follow my other classes. Specifically, try checking out the art of the proposal. That's a class where I show you how you can make professional, seductive and interesting proposals. Making good proposals can be the make or break in your business. It's whether not you grow or whether or not you shrink. Also worth checking out is grow your client base as a web for you. Answer that class I cover repeatable strategies and techniques for growing your business and bringing in more clientele. Okay, if you want to go further with your skills, check those out. Otherwise, again, Thank you for taking the course.