Project Management and Pricing

Welcome to Building Better Developers, the Developer podcast where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are once again here and we are checking things out. We are moving along in our series of discussions and figuring out what we want to be. So, like, how do we want to be when we grow up to some extent? This episode, I want to change gears a little bit from the, step out a little bit from the developer changes and talk about a topic we've touched on a few times, but I really want to revisit it because I had a conversation yesterday with a customer that makes it relevant, I think, or is a good lesson learned. And this goes into pricing. We have talked about pricing a lot. Michael and I in particular, as we've talked about both our, particularly when we got into our classes and how much you want to, you know, how much do you charge for that content and what does that look like? And then also our services and our products that we have, whether it's Vision QA that's building out or RB Consulting. And I think a lot of developers run into the same problem where we don't charge enough sometimes. Is it, and then some people are just going to go nuts and they're going to charge you a billion dollars and they're going to, but I think if you're a true developer, love doing this work. And so this is something that's fun. And it's really more about getting paid so you can pay the bills and not really because you're doing this to become rich. If we do none of them playing, it's not like we're going to say, Oh man, those bags of money somewhere else. But we do, I think, struggle with that. And it's, it's hard to figure out what, what should I charge? You know, what actually makes sense for me to charge for my service and particularly at whatever level I'm at, whether I'm starting out or whether I'm further along. And before I go into my story, I'm going to throw it to you, Mike, any thoughts on pricing that you want to throw out there? Yeah, we just had a conversation on that this week because in the co-starter class that I'm involved in right now to help boost Envision QA, one of the other students was looking to branch out their business and their bakery. And you wouldn't think tech really goes with a bakery, but they had some ideas that they wanted to pursue outside of the brick and mortar. And it led to some discussions on, you know, what do they need in that? But the key issue you run into with anything really, even when talking to customers is sometimes when you're having a conversation with them, they don't really know what they want. So trying to piece together what type of software they need, what type of application they want can be difficult. And the price can be really high at the start and then you can kind of stream it or filter it down to something that's a little more feasible. But when a customer comes to you and say, hey, I want something like Airbnb or I want something, I want someone to build me something like Facebook, you're not going to tell them, yeah, I can do this for $5,000. No way. A lot of them will come to you and say, hey, can you build this for $5,000? And the answer is going to be, you're crazy. And that's because they typically don't understand what really goes into it, what's involved. So what I like to do is typically start at the high level, try to get the requirements that they want in like a one hour session. And if I can summarize that and send it to them first, and then get feedback on that, then it helps us get a little bit closer to that price tag. But typically, though, it's hard when you really don't know what they want, or if the customer is unclear what they want, then when you make a bid or you give a price for one thing, you can really get yourself in trouble, either you're going to be too high or too low. Yeah. And that's exactly where, really, it's exactly what I ran into with this customer was originally, when I first started working with him a few weeks ago, a month ago, it was, hey, here's our budget. And we want to rewrite, it was essentially, we want to rewrite a system, here's our budget. And I was like, that's your budget? We can, assuming that these things are in place. And then it was one of those, what was there enough to say, okay, that could make sense. To do it from scratch, then we could probably do it. It seemed like a fairly simple application. However, getting into it and starting to dig into the various components and the way it was built, it became something that was much more complicated. And so the initial, it's initially, it's a timeframe of about four to six weeks. And that would work out with their budget and everything else. And that all sort of like, it's one of those where they said, this is what I've got. This is the box that I'm putting you in. It's like, okay, we'll find a way to get something into that box. Well, going into it and talking to them, we started finding out that, no, we're not going to be able to fit this in the box. So it was one of those, yeah, I think a lot of people sort of shy away from those conversations where it's like, hey, I went to you, I said, this is what it was going to take. It's going to take something else, or we're going to have to change stuff quite a bit. And that was how the conversation went. It was like, hey, here's these a couple of key areas. They are not going to be full featured, like, you know, sort of had planned initially. Those things are going to have to be reined in quite a bit because as we, and it was really as a kind of stuff where he was general early on, and then he got more specific about what he wanted. And it's like, oh, wait a minute. There's a difference between, for example, you use like a make me Airbnb or Facebook. It's like, or Google is like, hey, if you want me to make you a page that all you do is you enter something, it gives you some search results, but it's not searching the internet. It's searching some little database. Then sure, we can do that all day long. Now, if you rest of the project, and there's a reason that they've had multiple engineers paid multiple money, a lot of money for a lot of years to get to where they're at. That's, you know, I think where we run into sometimes you have people that just have unrealistic expectations, but sometimes. And particularly when you are as clear as you can be about this is what we are, this is as a developer, what I am seeing that you want. And you set those expectations from the start and they get to say, yes, that's what I want. Or they'll say, no, here's some additional things I want, or those things that you mentioned, I don't really need. Then you can get that clearer picture. And that allowed through just really clear communication along the way, when we had this conversation to say, look, this is where we're at. This is what we're seeing. This is how far we can get. But I don't think it's going to get you where you need to be. And it turned out to be a really good conversation because he said, yeah, I get that. Okay. I didn't realize that the situation with this stuff we had quite as bad as it was. That's happened more than a few times that I've dealt with people. And then you end up with something where now it's like, okay, it turned out to be a good enough thing because we're just going to extend the project out and be able to get what they need. Now, that being said, there are some things that can go completely off the rails. And even in those cases, it is worth it to have that conversation because sometimes you need to decide whether you're going to continue because whatever estimation or whatever you did, if you said it was going to be a 100-hour project and see that now suddenly it's going to be a 500-hour project, as you're getting into it, not when you get to hour 99, but when you start seeing that thing going off the rails, you need to start having the communication of, hey, this doesn't seem like, I think we're going to run into problems. And that conversation and that communication is going to at least help you when you get there to either say, hey, I can't afford to give you 400 hours that I think I'm suddenly going to have. So we need to figure this out. Hey, I'm going to donate a bunch of hours and get you there. Now I've talked a lot, so I think I want to get a little bit of your thoughts on this currently here, Michael, where we're at and some of the things I've laid out and maybe some experiences you've had like that. Sure. So I've heard a couple of things there. So one, I heard you having a difficult conversation with the customer. When you've started a project, you've taken a bit on a project and you start getting in and you start realizing things aren't the way they were presented. And you've figured out either very quickly that, okay, the initial estimate is not going to work or what you were proposed to do is not feasible or is going to take an exceedingly amount of time compared to what you were bid on. Then I heard that, you know, as you got through the project, you ran to something where you're further down, not quite at that last hour, but further along into the project where, okay, now you've already burned half the budget and now you might have encountered something or scope has creeped in or the process has changed. And in that case, then you have to go back and have another conversation of, okay, this is not what we originally discussed. So now we're kind of going a different direction. So you have your initial where the project you've been on is not quite what you expected. You have one where scope has changed or the direction has changed. And then you run into a situation, which I think we talked about before, where you get to the end and you get ready to do the deployment. And now you run into a technology or a kind of a deployment issue, like either be it through like the Apple store or Google store. So there's kind of three areas with that. So the first I would like to talk about how I would handle kind of the initial assessment. So when I go into like a lot of projects, contracts, whatever, I try to have that initial conversation. And I know you do too, before we even take on a customer, we try to get some information about what the project is. Now that's not always clear because in the customer's mind, sometimes they have someone else who they know what the product is supposed to be, but that's not necessarily what the product is. And in that situation, well, we could do the like a free assessment, take a look at it kind of maybe spend an hour to go through it or give them a short bid, like, hey, or maybe 5,100 bucks, I'll take a quick look at what you have, see if that's what you're telling me it is. And then I can give you a better estimate, or I'll accept your full bid for the full project. As you move into the project, though, one of the things I think that we've talked about throughout development and our projects in that is you get into that rhythm of software development, you get into that agile kind of situation where you kind of go through small iteration changes. But with some customers, it's hard because they don't know software development, maybe they're not a software shop, they just need a software product. So they don't understand the workings of software development, they don't understand agile, and getting them to do stand ups or to do daily scrums or even weekly scrums to kind of do touch points to be, oh, here's where we're at, here's what we discussed, and here is the direction we are going, is this what you still want, and have smaller checkpoints along the way might help avoid some of those pitfalls. But then when you get to the end, like we talked about with like the mobile apps and that, you run into the situation where you kind of run into things that are out of your control. And at that point, you're going to have to have the conversation with the customer and say, look, we've run into some roadblocks that weren't potentially there when we talked about at the beginning. So is that something that we need to renegotiate, or just slide it into the current system? Some of those that I've done is I've actually tacked on kind of a customer service or a service little contract on top of that for like maybe six months, like K for like a couple hundred dollars or a couple thousand dollars. I'll give you a couple hours of support that will kind of wrap into this to get us across the finish line, but I'll still be there for you, you know, for a couple calls for a couple hours additional after that. So there's a little bit of revenue tacked on at the end, not a lot, but enough to at least kind of not break bread, but at least leave things in a better place than, you know, be confrontational at the end. Yeah, and I think it comes back to really to communicating is that, and it is sometimes you're going to have, you're just going to have different, for say, the kinds where things aren't going right. You're not happy as a developer because, you know, if you're like me, you hate being stuck in the like configuration hell where you're just trying to figure out how to get everything to line up. It should work, but there's a library that's broken or that's out of sync or something weird like that, or cash that needs to be refreshed or something just ridiculously out of your control until you find it and you go, oh, that's why that works or now it works. But it's communicating things and it is making sure that upfront you set those clear, you know, here's our objectives, here's what we're going to do, here's our timeframes and our milestones, and along the way, make sure that those are milestones that as you're going through, you're either hitting them or you're letting them know that, hey, we've slipped. Sometimes you slip it forward, sometimes it's back, and usually it's back, but it's also, it's one of those like, hey, we've hit some snags. So this is where the trajectory is going. Don't try to, and I've been in projects gone bad where people have either tried to hide it or, you know, they start throwing other features in on top because they're like, hey, we need to do an extra week of work to catch up. Well, what we're going to do is we're going to throw a couple of features on and sell them on those features. And then in that, we're going to sneak in doing that extra week of work. But then what you've done is you've added scope and now you're still trying to, for those things, it's just, those never work. I've also seen the kind where people start cutting stuff out and they're just like, oh, well, they're not going to really worry about this or they're not going to, you know, testing is always awesome. Like, yeah, we're not going to test that or we're going to, you know, this grand scheme that we initially have, we're going to just get rid of all of it. And they don't, they're not really going to know that we're not doing as complex a backup that we're doing or something like that. That stuff will bite you. So be clear about it. And particularly if you start re-finding somewhere, if you're, if you're cutting a corner, have that conversation so that they know, hey, we're running, we're trying to find a way to make this work and just be honest to them. So they can make that decision and either say, yes, cut that corner. Or as in conversation, I had, it's like, no, we're not going to cut corners. We're not going to reduce scope. I need that. I have a, in cases, sometimes it's an, there's an MVP. I have a minimally viable product that I have to get out the door. And so some of those features that you would cut, they can't because they realize that that's critical to the, the, the complete product at that point. Now I didn't want to swing back a little bit because I mentioned pricing and I, I don't want people, I don't want to get away from like the most basic thoughts of that before we, we move on to some of the other things that we've talked about here is getting it, think about it. The best way I've heard it was somebody was like, and it was a lawyer of all people. One time I was like, Hey, people come to him all the time and would, Hey, can you, you know, this legal thing or that legal thing. And yeah, as a lawyer in particular, and I think doctors and that it's the, Hey, can you take a look at this kind of syndrome? And we get that all the time. We have our family members and people like that. They're like, Hey, my PC is broke. Can you go work on that? But we also will have customers that will throw that at us. It's like, Hey, we, you know, I know you're developing this, but we've got this other thing. Can you go take a look at that? And this attorney, this lawyer told me, it's like one of the things it's like, think about it as a, as a taxi driver. And for those of you who, you know, maybe you're too young, there's this thing before Uber and Lyft that was taxi drivers and they're still there in some places. And what they do is they flick their little, you know, they hit the little switch. So once you get in there, the meter's running. And that is sort of what we need to, is that we need to be, we can do stuff for free and pro bono, but we also should be paid for our skills and our time. Now an easy thumb is if you've got to, is if you've got a salary, you should be able to effectively build based on that salary. So, and it's, it's not that very, it's not hard to figure what that is, is you basically take the number divided in half and that's your hourly rate. And I'm not talking your annual salary, but it's to keep it simple. An example would be your annual salary is 50,000, let's say. And let's divide, and you divide it by the number of hours, which is typically the, 2000, which makes it easy as 50 divided by 2000 is just 25. A hundred divided by 2000 is 50. 10 divided by 2000 is, so that would be your hourly rate. Makes it real simple to do the math. And that's sort of like your, your break even. So your minimum that you should be looking for, for example, let's say, you know, nice even numbers, if you're making $40,000 a year, your minimum should be $20 an hour. If you go below that, then you're like, you're killing yourself. But that's the minimum. And usually it's something that you're going to do for, like if you're building out, for example, your, your Upwork or your Guru place or something like that, that you're building out your profile, you want to have some references. You may even do some pro bono work in that case. You may go down to your, you know, your local grocery store and help them out with a system or, or some local, you know, e-commerce person that you've, you've run into, help them out with their tools. But you're doing that for the reference. You're doing that. And that's part of the deal. It's like, Hey, I'm going to give you a rate that's either free rate, discount rate, and this is what I'm going to expect from you. So they understand that it's sort of a, you know, a barter type system. Otherwise, you know, keep an eye out for that because you don't want to be in a situation where you've, you've undersold yourself and now you're working long hours and you're not making enough money for it. And so that's, like I said, your minimum, usually you're going to run a tack at least 10 or 20% onto that because it's going to cover like taxes and all that kinds of other crap. And the fact that you're, you know, sometimes it's a fact that you're now doing, you're, you're giving up your Saturday so you can go spend eight to 10 hours working on this project. And so specifically, when we get into the side hustle, don't undersell yourself on the side hustle and then end up having allowing it to bite you, particularly if that side hustle grows because now, you know, if you've been charging 10 bucks an hour, when you suddenly go to full time, they're still going to want to do that for 10 bucks. They're like, why did you suddenly jump from, you know, 10 to 20 bucks an hour? And you're like, well, now I need that money to feed myself before it was just, you know, icing on the cake. They don't see it that way. That's just money that's going out the door for them. So now suddenly you've changed the arrangement quite a bit. So make sure that when you're doing your pricing, you look at that. And in particular, if you're not sure where your salaries, if you think you're underpaid or overpaid or something like that, there are all kinds of places you can go like Glassdoor.com and places like that, that have, they do, I think most of them do at least quarterly, definitely at least annually. And a lot of them will do it quarterly. So you can see what for my industry, for my skillset, what should I be charging? It's a little bit of extra price bonus stuff in there. It goes back to now sort of swing back, we're saying it's having those conversations. It is, as Michael said, it's like having these smaller, you know, if it's agile, you can do it every time. Sometimes even more often than that do, and often it is having that conversation and making sure that they are up to date as much as possible with what's going on. Now you mentioned something that's a little interesting, I know there is, sometimes you have a customer that doesn't understand software development. The one I lucked out with this one is somebody that understands that they've been in it for a while. They know the, you know, sort of the intricacies of it. Now, sometimes you have a customer that doesn't. So I wonder if you got, do you have any good stories about where you've tried to like, you know, set them up and say, hey, here's something that we do. The reason we do it is X or something along those lines. And they just don't do it, or you send them a status, they ignore it, or you invite them to meetings and they never show up. You run anything, because I sense that maybe you have the way you said that, have you run anything like that, that you want to share some stories with? Actually, I had a couple projects a couple years ago that were like that. I actually had a friend that had a welding business and you walk into their shop and basically, initially they brought me in because their computer was virus infected and everything was not working and they had been hacked. Got all that cleaned up and then started helping them get their systems in place just for using software. They weren't even using the right applications within Office and Windows just to do their bookkeeping. But looking around, every customer that they dealt with, they literally typed up a word document or a handwritten note or something that they had to do to get it or something somewhere on a post-it note for what the customer wanted, what was going to be done, and what the agreed price was. It was so informal, it was scary how they even made money. It's like walking into those old gas stations and you have one of those punch registers and I have a digital register. It's like, how are you keeping track of that for your bookkeeping? So we actually had a week-long discussion on how to get their systems in place to be more automated, more digital, and get it out of the mind of the owner. He basically had all the numbers for how much it took to do a job, how much parts were, nothing was in the computer. It was all in his head. We spent a week, we designed on paper a very simple system for how to get that out of his head and into the computer. So basically they could hire someone to talk to the customers, to maybe hire a salesperson to go out and go look for work. So it's not all on him and he can actually go do the jobs and make the money. Long story short, we spent a week on that. Three months went by, four months went by, a year went by. Then they came back and said, okay, now we want to do this because we're going to sell the business. And I'm thinking, okay, here's how much it's going to be. They're like, oh, never mind, we're going to sell the business. So that was very challenging. And the flip side of that is I had another business similar to that. It was a nonprofit for like habitat, but for animals. It was kind of a humane society type nonprofit. They again had an antiquated system that they did. A lot of stuff was on paper. All their customer memberships were on index cards. So if I came in to buy something, they had to look through index cards to pull it out and say, oh, here you are. Here's how many things spent months with them. And ultimately at the end of the day, they were like, well, we didn't have the money. Okay. I did a little pro bono, got them up to speed, but then they were like, no, not ready to pull the plug, not ready to pull the plug. And then a year later, when I'm six contracts in busy, they're like, oh, we needed this like yesterday. And it's like, sorry, I can't do it. It's just one of those things. That is, wow. That last little bit is one that happens very often where it's, a lot of companies are like this. You like to just run and run and run and go and go and then they'll stop. Particularly if you get to a point where it's like, okay, now we need you to sign on the dotted line. Like you need to sign a statement of work or we need to sign off on this. And so the work's going to start, you're going to get billed, you're going to be, you're going to be invoiced and we're going to be expected to be paid on whatever that schedule is. And a lot of times, oh, wait a minute. Now I got to figure out how to pay for this essentially, or yeah, that's right. Okay. We'll, we'll come back to that a little bit. We're not quite ready. Or they get busy. There's like, sometimes they just, it's not even money. It's just, they've got too many other things going on. And it, sometimes you will see that as a developer, you're saying, okay, I'm going to have five people in the next week to be able to get some requirements. And I know none of those five people are available at all. And it's just like, Hey, let's, you know, let's just like put a little bookmark on this. Let's come back to it later. And then we can, where we can actually go through this conversation with these people. It'll be time. That's where it's worth it to have that clear communication, because if it's something they're going to start up and they're going to bring it back, you know, it's going to go to sleep and come back in six months. Those conversations are great times to say, Hey, we can do that. I'll, you know, Hey, I'll go find her the work. However, if we have to start it back up in six months, that it's going to, there's going to be costs related to the startup. And sometimes we don't want to do that because we're like, Hey, I've got more work and I can just jump back in. Very good to have that conversation going on and say, yes, we can pause. However, there's going to be a cost to pausing and then coming back. That's in addition to all of this other stuff that it's going to change some of our, or sometimes it's as simple as, you know, those estimates that we put together, those may change in six months, because the last thing you want to do is be in a situation where you go and put together a bunch of pricing. And I've seen this few times they come back a year later. They're like, yep. Well, great. But we changed our rates six months ago because things go up, you know, prices go up. So here's what it's going to take. Or the technology, a lot of times has changed. So it's something where it's like, you know, we could have done that for that price then. However, because of the changes, now it's going to be very different. Or now you were working on version one of that. They're version three, we need to redo, you know, re-scope the entire project because you don't want to do a, you don't want to have a vert. We could, we could build that, but it's going to cost you more. And now you're going to almost immediately going to have to upgrade that. So if you run into issues with competitive bidding, where they come to you, they go price around and then they come back. Yeah, I've done that a lot too, where it's, you know, and that's even, you've sort of alluded to where we'll come in and do like sort of an initial, hey, I'll spend a few hours. We'll do sort of like a, either an assessment or an audit or an initial, I've even done stuff for its initial, essentially requirements gather point of an RFP. I mean, I've even put stuff together to a level of like going through an RFP process for them and saying, Hey, here's what's out here. And here's what it looks like. And they'll come back later. They'll get to the end. And they'll say, well, we'll think about it. And sometimes they'll think about it and they'll take, you know, what I put together and they'll go off, run off somewhere else and find somebody that says, Hey, we'll do it for half the price. You know, they do that. Sometimes they've come back and they'll try to, you know, sort of beat you down on your prices and say, Hey, I found this other group that said they would do it for, you know, $2 an hour less or, you know, whatever that is. And those are, those are difficult, those very difficult conversations. But a lot of times that's where I'm going to stick to my gun and say, Hey, this was priced based on what we, what our rates are and things like that. If you can find somebody can do it cheaper, then go ahead by all means, go ahead and do it cheaper. I'll usually say, Hey, but, or did they include this and this and this and this? Or sometimes it'll be, did they just look at what we, you know, what we presented you? And then they just, you know, you just talked them into a lower price. How much do they know that? How much are you confident that they're going to actually be able to produce based on that? And it's, it's not necessarily to talk bad about them. It's more to just say, Hey, make sure you've like covered, you know, you've actually covered all of your bases when you do this. And you're not just looking for the, you know, the lower price because you're going to get in the end, you usually are going to get what you pay for. If you do that, good luck. And I've had a couple back, you know, a year or two years, some time further down the road and said, Oh, you know, we went with this other group and they were great. And then it ended up not working at all. So can you help us out? And it's like, yeah. And then they usually will give you a job story. I'm like, well, we've spent all of our money. And it's like, well, I'm sorry. I, I, I w and sometimes I've had people that have come to me after, you know, after they've gone through all that. And I said, I wish I could have talked to you earlier, but you know, I can't, you know, my company can't pay for your mistakes. It's my people can't take the pay cuts because you guys, you know, a crappy company, get it out of that crappy company, get them to do stuff, but don't come to me and expect me to be able to, you know, like make you whole when it wasn't my fault. And I think that as engineers, a lot of times we feel like, Hey, we, we want to swoop in and be, you know, the hero, but you also, you have to remember you're running a business. And so you have to figure out going conversations like, what am I comfortable with? What do I need to pay my bills to be able to put food on the table to do the things that I need to do as a developer. And as, you know, so I can provide people a, you know, a good resource and a good solution as opposed to, you know, 80 hours a week to try to make all the ends meet. And it's because partially, because I'm just not charging enough for, and this is honestly, this is in any business. There's a lot of businesses, a lot of people I've talked to that they are working themselves ragged because they're not charging enough for service. So they I've run it out more than a few times thoughts. Yeah. The biggest one I've run into is I've had some people, you know, walk away, you know, take what I give them for the RFP and they say no, but I've had people come back and it has actually cost more to fix the problem. And I've had to redo the RFPs and the bids even at the current rate, but it's going to take longer to fix it. And that might be an interesting little bonus topic we can talk about afterwards, but it's something to consider when you're doing your pricing and when you're talking to your customers, leave it with them. If you want to take it somewhere else, you want to shop around, that's fine. If things don't work out, you can come back to me, but this will not be the same conversation. This will be a different conversation and possibly a different price rate. So that's one thing you can kind of set the expectations when leaving with the customer, leave on a good note, leave it open the door open for them to come back, but set the expectation that it's not, I'm not going to either a give you the same rate or B I'm not going to clean up someone else's mess for the same price. Yeah. That's a, that's always one. It's just, you know, you don't really want to set the tone and then just so bad, but you just sort of say, Hey, this is, you know, this is where now things are going to change. Things are going to move on. So we may have a different discussion and maybe it'll be the exact same conversation and same estimates, but maybe not because things change. It's just like everything else. You know, if you want to get a house built today, you're going to get a certain price and quote, but if you come back a year from now, it's possibly possibly and probably different. And you have to take those into account. They'll wrap this up from the podcast side. I think it's, we've got plenty here for you guys, as always, shoot us info, email at info at development.com. If you have recommendations, any things like that for future topics or any questions that we may actually effectively read that question out online and go ahead and make a whole discussion on that. You can always check us out on the video side as well. If you're on the video side, then, Hey, we've got a couple bonus things we're going to throw at you. But those of you out on the podcast, go ahead and make sure you keep your hands on the wheel and just keep on driving down the road. You'll catch us next episode until then go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to building better developers to develop a newer podcast. You can subscribe on Apple podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember just a little bit of effort every day ends up adding into great momentum and great success.