Ditching Hourly

Hello and welcome to Ditching Hourly. I'm Jonathan Stark. I got a question over email that basically comes down to this. Should you look at your client's code before you quote them a price? And my answer is no, I wouldn't. You gotta ask yourself, why do you think you need to look at their code? What you're doing there is that you are trying to judge your level of effort, your cost, how much time is gonna be required to do the things that you need to do. And that's understandable. But I'm gonna give you three reasons why you don't need to do that and why it might not be a good idea to do that. In fact, I feel pretty strongly that it's a bad idea to do that. The first thing is that getting access to a total stranger's code base opens you up to risk. That can go sideways in a lot of ways. Let's say somebody gives you login credentials for their GitHub or they send you a zip file. That is a valuable business asset that they are exposing to a total stranger. And if they trust you to do that, that's a good sign that they trust that you won't do anything bad with it. But what if someone else, maybe a disgruntled employee does something bad with that? And then it shows up on the internet somewhere, a competitor ends up with it. It's database access and the customer data includes database access and customer data ends up loose on the internet. You don't want this company wondering whether or not you were the leak, even if it was inadvertent. Maybe you left something in your Dropbox or whatever. This might sound like edge cases, but I have seen it happen. There's no reason to expose yourself to that kind of risk and you'll learn why as I continue. The next reason why I think people should not worry about looking at the code before you're in a financial arrangement, before money has changed hands, before you're actually your client, is because it indicates to me that you're thinking in a cost-based model. You're planning on setting a price based on how hard you think it's going to be to do the tasks that they want you to do in the context that they want you to do them. So you're thinking about scope. You're thinking about scope. I don't want you to think about scope. I want you to think about what they're trying to accomplish. I want you to think about the client's business goals. When you're thinking about the client's business goals, if they're big goals, the scope matters less and less and less. So just to exaggerate for emphasis and for educational purposes, imagine that some client came to you and said, we've got this massive, we've got this code base, and we want you to make some changes to it. It's critically important that you do this. It's critically important that we get it done now. And it's critically important that you are the person who does it because we know that you're the worldwide expert on this. You came highly recommended from people who we trust intrinsically. How much is it going to cost? And it's a massive, it's of massive importance and urgency to their business. It's a bet the business type of project. And you say, it'll be, let's say it's $100 million business. This is a bet the business type of project. And you say, it'll be $10 million. Do you really care what the code base looks like right now? You probably don't. If you've got margin, because the value to the client is so high that you can set a price that's very high for you, you could rewrite the code base from scratch for $10 million. It doesn't really matter what state the code is in if you're not worried about margin. And now I'm exaggerating with big numbers, but if you are worried about the scope, which is what you're worried about when you want to see the code base, your margins are probably too thin. They're definitely too thin. You would not be that worried about it if your margins were going to be higher. And the way that you make your margins higher is you find clients who have big problems that they trust that you can solve or at least move the needle on some leading indicator or you can contribute to solving the problem and you price that. There's no reason to look at the code before you determine that there is some kind of value that you can provide to these people, which leads right into the third point I'm going to make, which is that there are plenty of ways you can find out what you need to know without actually getting access to their code. So it could be that you need to see the code to determine if what they want to achieve is even feasible. So for example, company, we go back to the $100 million business. They've got a bet the business project. They trust that you can move the needle for them. You charge them $10 million. But there's something about the code base, even if you were going to rewrite it from scratch, even if it was such a disaster, it was a giant legacy application, you couldn't rewrite Salesforce from scratch for $10 million, I'm sure, or Facebook. There's just too many things going on. It's not feasible. So if the...

and you want to look at the code base is to determine whether their requests are feasible, you can do that after the money changes hands. So if they come to you and they say, hey, we want you to do this stuff, you say, okay, great. Here's the business outcome that you want to achieve is this. Here are three ways that we can engage. They pick option two. You get in there and then you get access to the code base. They're our client. They are indicating that they trust you. You're moving forward. There's a contractual agreement here that goes in both directions. You get in there and it's just not feasible to do what they want to do, either in the timeline or on the budget or whatever. At that point, you can say, look, you guys, this is not going to be feasible to do. And certainly in the way that we're planning on doing it, but there might not be any way that this is possible. So let's brainstorm this. See if there's another approach. See if we can tweak the goals. Maybe we can chunk off a phase and do a phase first to fit in the required timeline, whatever the thing is, kind of brainstorm the situation and kind of rehab the conversation or you can just give their money back. If the code is really that bad, and in my experience, this doesn't happen that often. Yes, there's spaghetti code out there. It doesn't happen that often. The code is so bad that there is not feasible to do what they want to do. So assuming that, but even if that was the case, you can say, look, I hate to break this to you, but the code that you got from this company that delivered it to you, it's like unmaintainable. We would have to start from scratch. We don't have time to start from scratch. We just can't do this for you. Unfortunately, we're going to have to refund your money. Or we can maybe come up with a different approach, but that might involve a new proposal. But for me, there's a huge difference in doing the code review after they've become a client. I think that is really important. Otherwise, you're potentially just, you're in the job of reviewing code in order to write proposals. I don't like that idea. Okay, so here are some other ways. We just talked about feasibility. The other things to consider are you do want to hedge your risks to a certain extent. I can imagine people wanting to know somewhat how hard it's going to be to implement the things that they want done. So the client comes to you, this is, hey, we want these features. Okay, why do you want these features? For these reasons. Okay, so if we can get you to these business outcomes that you're looking for with features that look like these or at least achieve the desired outcome, everybody will be happy. Yes, okay, great. The more of a mess their code base is, granted, the more work it's going to be for you. I agree with this. It will eat into your margin somewhat if the code is really, really bad. At a certain point, you could just do a rewrite, but again, you're eating into your costs. Hopefully, you'll find a way to take the existing code within the constraints and guarantees that you provide that you can take the existing code base and do as little as possible to deliver the, as little work as possible to deliver the desired business outcomes at the level of quality that's required. That would be a win for everybody. So you might want to kind of hedge your bets and get a sense of what it's going to be like before you write the proposal to inform what your profit margin might be. But you can do that without looking at the code. So here's some questions you could ask to find out whether or not there's probably a mess on the other side of that private repo. One thing you could ask is who wrote the code? Was it someone internal? Was it someone you outsourced to? Was it your cousin Jimmy? That's probably going to tell you quite a bit about the quality of the code, or at least start to. You can ask what frameworks or libraries or platforms are involved. You can ask if they're on the latest versions of those platforms or are they running way behind? Is everything really out of date? You can ask if the team is using version control. You can ask how often they deploy to production. You can ask how often bugs end up in production. You can ask if show-stopping bugs end up in production on a regular basis. You can ask how many environments do they have? Do they have a dev environment, staging environment, QA, production, or are they just doing everything on the live site or in the live application server? Does the dev team have any coding guidelines? How many devs are on the team? How does the process work? Do they work on different branches and merge and do code review and pull requests, or how does it work? If you think about the reason why you want to look at the code, I think most people want to look at it to get an idea of whether or not they agree with it, whether or not they are going to feel like they can work with it or if they're going to feel like they want to throw the baby out with the bathwater and start from scratch. And if you are used to working in a particular kind of dev environment where you're dealing

continuous integration and you're using particular platforms and you stay cutting edge and you use certain coding guidelines, you can find all of that stuff out by looking at the code. Yes, you can at a glance, you can probably learn quite a few things about, you know, by looking at a code repo. I know I could. But you can find those things out without without looking at the code. And that doesn't expose you to risk. It limits the amount of work you need to do before a proposal. And even if it all blows up in your face, you can always just give them their money back when you if you get in there. And it turns out that even though they're using the latest frameworks and all of the greatest coding guidelines, the repo is still a spaghetti disaster area. I promise you that is not going to happen on a regular basis if you get the answers to these questions. And of course, if they're truthful with you. So to summarize, I feel strongly that not only don't you need to look at the client's code before quoting a value price, you probably shouldn't. All right, that's it for this time around. I'm Jonathan Stark. Hope you join me next time on Ditching Hourly. Bye. Would you like to learn how to get paid what you're worth? How about selling your expertise and not your labor. We work through all of this together in the pricing seminar. Pre-registration starts soon and you can sign up to be the first to know when early bird pricing is announced at the pricing seminar.com. That URL again is the pricing seminar.com. Hope to see you there. Hey, Jonathan again. Do you have questions about how to improve your business? Things like value pricing your work instead of billing for your time or positioning yourself as the go-to person in your space or maybe productizing your services so you never have to have another awkward sales call or spend hours writing another custom proposal. Book a one-on-one coaching call with me and get answers to these questions and others in the time it takes you to get ready for work in the morning. Best of all, you're covered by my 100% satisfaction guarantee. If at the end of the call you don't feel like it was worth it, just say the word and I'll refund your purchase in full. To book your one-on-one coaching call, go to jonathanstark.com slash call, C-A-L-L. That URL again is jonathanstark.com slash call. Hope to see you there.