Price With Confidence: Estimation Made Simple

Welcome to Building Better Developers, the Develop-a-Nor Podcast, where we work on getting better step by step, professionally and personally. Let's get started. Hello and welcome back. We are continuing our season of Building Better Developers, Develop-a-Nor Podcast with AI, AI, AI. Okay, crappy sound effect things that were there. What we're doing is we're looking at a couple seasons back, we're taking the topics and we're just redoing it. It sounds lazy, but it's actually pretty cool. We're throwing it into AI and saying, AI, what would you do? And then we're talking about what AI kicks back out. And it almost always, yes, there's a few things that it covers that we already talked about, but it almost always spurs other conversation points. Now, first off, I'm going to go ahead and introduce myself. I am Rob Broadhead, one of the founders of Develop-a-Nor, also the founder of Arby Consulting, where we are like the simplest way to do this is I help businesses simplify their technology and build clear roadmaps that fuel growth. That's like one of those like AI kind of answers right there, but that's what it is. That's what you want is it's like, what do we do? We are sometimes known as a fractional CIO or things along those lines. We're also a boutique business consultancy. What we do is we sit down with our customers. We talk about their processes. Hopefully they know them. If not, we'll help you work through your process and get some of that stuff that's in your head out of your head. We also know some nice process consultants and stuff like that that can help you get that part of your house straightened out. And then once your house is straightened out, now we can talk about how to do it better, more efficiently. We can simplify, integrate, automate, innovate. We can find ways to do those steps for that process better, faster, higher quality. Now you get to work on your business instead of in your business and your customers love you because that's how the natural order of things is. Check us out at RB-SNS.com. We have a whole new website, sort of, and we've got old content. It's been around for years, but we've also updated a lot of stuff. So love to hear feedback on that. So matrix.rb-sns.com. You can go check that tool out. We're soft launching it, I guess. Maybe this is now a hard launch. However you look at it, some of the stuff that we've got to just help people out if you're wondering where you sit in your need for a technology assessment. Good thing, bad thing. Good thing is that we have downsized and we've got so many things that we don't worry about anymore. We don't worry about if the yard gets mowed because we don't have a yard, basically. Things like that. We've simplified our life down so that we are much more mobile and things like that. Bad side of that is we're an apartment. We don't have like what we used to have. You could go out to the mailbox. You had a front door. So deliveries that come to the front door, you go to the mailbox, you get your mail. We don't have to go somewhere else. When deliveries come, sometimes they don't go to the place that they should. A bad example of what can happen is we have a restaurant that is attached to where we're at and we had a delivery that got delivered to the restaurant and disappeared off the face of the earth at that point. We figured out because they sent us, which is great, we got the typical picture of here's your product being delivered. It's like a picture of this product being handed off to somebody and that's all we know. We got that. It's like what the heck? Not even close to a mailbox, but that's okay. You guys took it to the wrong place. One of those bad things. Out there in the middle of nowhere, Michael gets everything to his front door, I am sure, or one of his front doors anyways, and he's going to go introduce himself. Hey everyone. My name is Michael Moulache. I'm one of the co-founders of Devolverner. I'm also the founder and owner of Envision QA where we help startups and growing businesses build software that works the way it's supposed to. From day one, we make sure that software is what it's supposed to be and make your customers happy. You probably have heard stories of software projects going over budget, launching late, or breaking once users get their hands on it. That's where we come in. At Envision QA, we make sure that your product is tested, stable, and ready for the customer. We handle the behind the scenes quality checks and support development so that you don't have to worry about that. We help you launch faster, avoid costly mistakes, and protect your reputation. In short, we help you build software that doesn't break your business. Check us out at EnvisionQA.com. Good thing, bad thing. Good thing, we are in, I guess what's called a false fall. I think it's fall. We're cooling off. Bad thing, my wife loves her little 10-foot pool we put up every year for her to cool off after doing all the yard work since it gets so bloody hot here. Unfortunately, we have now hit that point where the pool is now staying so cold we can't get in it anymore. So we have to break it down. Yes, I was actually just in the lake the other day and it was still almost bath warm kind of thing. So it was like it was nice because it's a little breezy, but I think a little cooler would have been even better. Cooler than that is where we're going now. So we're going to talk this time around. The original topic was Estimation Essentials, How to Nail Pricing for Development Projects. Episode Flow. Oh, again, this was ChatGPT5 and it comes back. It gets like right to business. It did give me the obligatory perfect title and then it gives me this stuff. It's just like, okay, here you go. Episode Flow Hook, 1 to 2 minutes. Open with a common pain point. Ever been asked how much will this cost and your stomach drops? Estimation is one of the trickiest but most important skills in software development. Needs a payoff. Better pricing means happier clients, less stress, stronger career growth. First section here, I guess the second section after the hook. Why estimation matters 3 to 4 minutes. It's more than numbers. It builds trust and credibility, impacts timelines, client satisfaction and profitability, sets the tone for whether a project feels like a success or failure. That is it in a nutshell. That is why we estimate. That is why we need to be honest about our estimation. I spent a good deal of time today walking through a, essentially it was an RFP that somebody spent a good deal of time putting it together. There's a lot of detail to it. They're merging a couple applications and they talked about that, about, okay, here's the features from this one and this one and this is how they're going to join in and what it's going to look like. We get to some other things that we want to do and it was really good. I'm cruising along. I'm like, yep, that's going to take X amount of time. That's going to take Y amount of time and I'm just cranking through and then I get to a section that is way open ended. We want to have integrations with a bunch of payment processors like A, B and C, like that and we would like to integrate with different accounting systems like this one, but there's systems that they haven't talked about. And then there's some other things that they talk about that are like integrations and things like that. It's like, okay. And I had to take that section and that's where you just be honest with them and say, I can't give you a valid estimate on this. I have no idea what it can take. There's not enough details. Nothing is the, you know, some amount does not give me an X amount. So I don't know how many things you're going to integrate with. I cannot possibly tell you what it's going to cost to do that. I can't even tell you if you can't tell me which ones they are. I can't really give you an estimate per because some are going to be easier than others and depending on what you include and what that integration looks like, I'm not going to be able to help you out. I can't, or at least I can't at this point give it to you. Now granted, this is something that you start into that conversation. But the reason I bring this up is that I think too often we end up in it. At least I know I do run into situations where the customer really wants a hard number. They want to say it's going to cost $10 to get this bill. Okay. The problem is we can give them a number like that, but if you're, if you're smart, your number is going to be insanely big. If it costs, if you think it's going to cost $10, you're going to say it's going to cost a hundred dollars or something like that. This goes back to setting expectations. And if they balk at it and say, well, look, I don't know that it's really going to take that much, but I have to do that to be safe because it could, because you could change your mind. There could be requirements we haven't talked about. There are core requirements that you haven't actually detailed. And I can guess at this stuff, but I'm not the customer. I'm not the one that's building it. So be honest where there's things you're like, well, we need to talk about this more. And it's not don't say it can't be done or we can't estimate it or anything like it. It's just like at this time, we can't give you a valid number. We can't give you something that works because we don't have enough information. So instead of us giving you just something that we've pulled out of thin air, we're going to sit down and talk to you and then we'll give you a timeline and estimates and things like that. We'll give you the details that are needed to actually build out that pricing. And the last thing before I toss it over is make sure when you estimate that you are honestly, if you're a developer, just always overestimate. If you think you're estimating too high, you're still too low. Developers are horrible about I'm going to get it done in a month and six months later, you're still working on stuff. Part of it is our fault because we think we can do everything instantly. Part of it is the fault of the project managers and the customers because they start with something small and then things start to get added on. And the next thing you know, it's bigger and bigger takes more time. Don't fall into the trap. I know I said one more. Okay, the last one, the last one more don't fall into the trap of a customer that's like, well, you know, we could do it for that. But then they try to lowball you a little bit like, but gosh, we really had a budget at what you know, 90% of what it was. So the value is the value. The cost is a cost. It's like you don't get into a cab with somebody, get halfway through the ride and say, hey, can you shut that flag down and turn the meter off for a while? Because I don't really want to pay that much for this cab ride. It's sort of the same concept. Your thoughts on this. So you kind of touched on most of the points on this one. I don't want to beat this too much, but one of the big things is be honest. Don't lie to the customer. Don't over promise. Although that can still happen, but don't deliberately over promise and under deliver. We want to, you know, under promise and over deliver. So like Rob said, you know, if you think it's going to cost $10 charge 100. If you think there's underlining issues that could arise that could have things go off, you know, go off the rails. The best example of this was something I read about the airlines years ago. So airline satisfaction was horrible and down. People were constantly complaining about airlines never being on time, ticket prices being too high and so on. One of the biggest things I heard about how this model changed was what they did was they increased the time of the flights. They decreased the costs a little bit, but they changed the expectation. Essentially, how long is it going to take to do some? And all of a sudden, customer relations went up. Customers were more satisfied. Trips were not taking so long. Plates weren't being canceled. So it is along those same lines. Make sure that what you are looking at fits within the expectations of the project and your customers expectations. If you say it's going to be done in a week and you don't deliver within a week, you're going to have an upset customer and that is going to impact your business and your reputation. And then we'll go right into the common pitfalls because you've actually touched on a few of those over promising underestimating to win a project, then burning out, ignoring hidden costs, meetings, testing, documentation, forgetting risk buffers, unexpected issues always show up using gut feeling instead of a repeatable process. I'm going to start with the underestimating to win a project and burning out because if you're side hustling, I have seen a lot of those. I have struggled with that at times and I have been the beneficiary of that several times where somebody got into a project and then flaked out and disappeared because they just got worn out. The problem is that they screwed over their customer. They are not going to get that customer again. And a lot of times I end up winning that customer because I come in and say, okay, we're going to take this to the finish. And yeah, it's nice because they got it 80% there. So now we have a better idea of what's left. But particularly with a side hustle, I know you go into it because most of us do where you're like, I have a day job, my bills are paid, blah, blah, blah. I don't really, I'm just doing this for fun. Projects become not fun on a regular basis. There's always going to be something where you're like, I would really like to have a weekend off, but no, I'm still working on this sticking project. And so be aware of that. Make sure you're setting yourself up for success, not just them, but yourself as well. The last part I want to touch on too is the whole don't use gut feeling instead of a repeatable process. This is why we estimate. This is why we need to even in our own projects have a fear for like, what are we doing? How much time are we spending? How much time are we wasting? Because that commonly is our issues. I don't know how many times somebody's like, I was working for 10 hours today. And you figure out that, well, yeah, they were at work. They were at their desk for 10 hours, but they spent three hours like lost in listening to the news or they got caught into something. They had to go walk the dogs a much time or whatever. It's like find ways to figure out exactly when you're working. I can go back to my favorite Pomodoro and things like that. Because those things really, really will help you like know when you're focusing and when you're not. Because that's a whole focus. I mean, that's a whole reason for those is focus, do your stuff, and then move on. And you're going to realize that you're not going to work eight hours a day. That eight hours or 10 hours or 24 hours that you thought you were working. If you're doing a focus method like that, you're going to realize one, you're going to realize that that's not how much you're working, but two, you're going to get more done when you do it because you're not going to have all of those distractions. You already started, so I'll let you just sort of carry on with some of the common pitfalls and what you see. Yeah. So the one I'll touch on is the hitting costs because you and I have talked about this often on the side quite a bit because a lot of times we forget there are meetings. You have to do testing. There's documentation. And when you plan out a project, especially if you're doing this as a side hustle, you're not going to think about these at all. You're just thinking about how long does it take to get this done? The problem is if you go in with that mindset and you don't think of this as a full project. Now, if you're building a website, okay, maybe not as much, but you still have to think about documentation. But testing and meetings when you have larger teams is critical. You need to make sure you plan for this because if you have, say, 20 hours a week for a budget and you have a team of four, you want to make sure that you're optimizing as much time for development as you can. But you still need to account for those meetings. If you schedule two hour meetings into that time frame, that's two times four. You've lost time. So either you attack that early, add it to the estimation to your budget, and then you plan for that ahead of time. And it adds up. Time adds up really quick. Meetings in particular. One of the just to add to that, one of the things I find most often gets lost is once you get to a team is project management kind of stuff, which is meeting with the team, but also meeting with the customer and doing like statuses and things like that. If you meet every day during the week for a half hour, that's two and a half hours a week. And if you're saying that we're going to just tack 10% on to the end of the total, that's only 10% for project management. Basically means 10% of your week, four hours. That basically means you're budgeting four hours of project management stuff. If you spend two and a half hours just managing the team, then there's not much else you're going to do. If that project manager is also looking at creating tickets and chasing down tasks and doing statuses and things like that, you can burn through that very quickly. Testing is another one that don't think there's going to get away with a 5% upcharge or whatever on top of it for testing. And it does. It gets scary, but it gets real because you're going to go do your, I've got a 200 hour development estimation I put together. And then when you add on maybe another 5% on top of that for documentation and 20% on top of that for testing and 10%, 15% for project management, depending on your size, those things add up because those percentages, that's another 40 or 50%. Sometimes it goes on top of it, but that's where we get hosed because we get to the end of the 200 hours and we still have a hundred hours of work to do because we didn't figure it out from the start. We didn't set the standards. We didn't set expectations. And now we're begging for money or saying, ah, I'm sorry. Or working for free. None of that is beneficial. None of that is fun approaches to estimation bottom up, break work into task, estimate each piece top down, use similar past projects to guide estimates. Three point estimation PRP, ERT, optimistic, pessimistic, most likely time and materials versus fixed price, the pros and cons of each. I will briefly touch on time and materials is almost always the way to go. Fixed price, you can do it, but oh my gosh, you better know exactly what you better have done this a lot of times. You better know exactly what you're talking about and don't let yourself get caught in the time and materials, but it's actually a fixed price because I have seen that has been used a couple of times and say, look, we'll pay you X, you know, we'll pay you by the hour, but we're going to limit the number of hours per week or month or whatever the time, you know, there's going to be a limit to those. There's going to be a cap and then somewhere down the road, there's a cap to the whole project. So effectively, they're trying to win on either end of it. If it gets done faster, they don't pay as much for hours, but if it goes beyond, they're not paying for the beyond. It's one or the other. If you're doing, if it's time and materials, more of the risk goes on the customer because they want it to get done because the longer it goes, the more you're getting paid. If it is fixed bid, then it is you're holding onto the risk. So if it's time and material, it should be more aggressive pricing and things like that. They should be getting their money's worth and then some if it is fixed, then you should be getting a premium on that. And it's, you know, if you want to do something where there's early bonuses or there's going to be penalties if they're late, that's all great. I mean, that that kind of stuff works. I've found it several times that one of the best ways to do it is say, here's what our rate's going to be. You know, we're going to do $5 an hour. But once it gets past a certain point, because we're, you know, we're sure, pretty sure we're going to get it done by this time. If we don't, then we're going to cut it in half or we're going to go to $4 an hour or whatever it is, is to say, okay, you're getting discounts as a customer because we didn't give you the proper estimate. That means we both hurt and hopefully means that everybody's going to get the stuff done as fast as possible. The other methods you end up working against your customer way too often. I spent enough on that that I'm just going to throw it back over to you. Yeah. So you touched on the one I was going to hit, but I'll start with this one. You know, the three point estimations, the perk, optimistic pessimistic and most likely be careful with this one. Well, it is beneficial to what's the best case scenario, what's the worst case scenario, and try to take something in the middle. Sometimes that's not always possible because there are always external or, you know, additional factors that you just don't account for. You know, it could be COVID, it could be, oh, you know, the current version of Windows is now obsolete, you know, things like that. You just have to deal with it as they come along. But that could be the pessimistic approach. However, when you're doing the pessimistic approach, you're probably not thinking that pessimistic, you're probably not thinking that worst case disaster. So you have to balance the good with the bad. But this goes kind of back to what we talked about before, where you need to make sure that you've broken down the requirements for what this project is going to be clearly enough that you can define, okay, this is what this should take. This is if we can't complete this, this is what it should take. If you get to those sections, like Rob said, where he had like, oh, it could go to this accounting system, it could go to this payer. Those things you can't touch because you don't have enough information. So if you follow this and you get to that point and you're like, wait, optimistically, yeah, if we know who this is, we could possibly do it. If you have a lot of those questions, that's when you need to go back and solidify that. Nail down some of those requirements before you get too far. And if you can't, because I've had a customer, this reminds me of a customer I had a while back and we ended up sideways with each other basically because I gave, I did it that approach. I said, okay, here's the option. And he wanted the optimistic. He really was like, I need the optimistic. And I was like, okay, well, that's very optimistic. And sure, that would work if everything falls into place. I said, but these are the things that can go wrong. And this is what can, any one of them can take us off track. And as we did them, as we were going through almost everything that he said was like, well, this is great. And this is working and this will be fine. And all these optimistic assumptions he made were wrong. They true. They turned out to be untrue. And so as we got through them, I was steadily communicating to him that, okay, we thought this would happen. It didn't. It's going to cost us X amount of time. It's like, we thought this was going to take a week. We can't do it in a week because the things that we assumed are wrong. So now we got to go back and fix those. And now it's going to take a month instead of a week. And even though, and this is like part of the part of why I'm not a real fan of this anyways, is that he got stuck in his head, the original optimistic stuff. He kept going back to that and be like, we should be here. We should be here. We should be here. Even though there was a steady stream of communication. Usually people are going to be more realistic and you're going to have that steady stream as communication. They're going to see what's going on. They're going to say, okay, we're falling into the problems. And they're either going to like, you know, they may cut the project short or they may change gears or whatever, but that's don't hide it from them because you're worried it's going to get cut short because then your butt should get cut short at the end. And when they find out that, you know, you hosed them, give them that information as soon as possible so that your customer can make a intelligent decision. And one that's, you know, now it's setting the proper expectations. And sometimes it's going to be stuff was like, well, can you help us with that? How can we find a way? We can't really afford that pessimistic, but what can we do? And there should be options is fine. Like MVPs and things like that to save your customer from the reality of life, essentially practical steps to improve estimates requirements. First, clarify what's in scope and what's not ask questions before giving numbers, break it down. Smaller tasks equals more accurate estimates at buffers, typically 20 to 30% for risks, unknowns, and scope creep, validate with data, track actuals versus estimates, learn from past projects, your estimates should improve over time, communicate clearly, share not just a number but assumptions behind it. Example, two weeks, assuming APIs are stable and no new features are added. Definitely that that's exactly what I was talking about is like, wherever you're giving the optimistic, the pessimistic or the mid range kind of estimate, talk about not only what it is, but what are the unknowns? What are the risk factors? Ideally, this is like, pro tip or whatever, when you're getting into a project, the high risk items are the first things you should tackle. Those are the first things that you should start looking into, because then you're going to know as soon as possible that yeah, that's going to work out or no, it's not, and start finding ways to be able to work around it. If you wait to the end, then you're going to have a lot less way fewer options to do work around. Just trust me, it's always given yourself that time, it gives you more time to redesign, to replan, to adjust and do the things that you need to. I would say the curfew, what's in scope and what's not. That reminds me of like MVPs is saying, okay, well, what is really the minimum viable product? What is it that we like the minimal amount of work that we need to get this done? I am starting to have that conversation with my customers from the very get go, because it is way too easy for things to get added, for things to get moved. As we're going through the project and we're adding things in and they're like, can we do this early on? It's like, yeah, okay, we'll tack that on and we'll tack that on, especially if it's not fixed bid and it's just like, okay, we'll tack it on, but it's going to take another week. We'll tack it on, it's going to take another week, it's going to take another week. The next thing you know, it's six months beyond what the original target date is. They're frustrated. They realize that they've got to get it done faster or market changes or there's so many things that can happen that can cause you to get to a point where suddenly the project goes into like critical mode where we got to get just the things we need and get this thing shipped out the door and maybe they run out of funding. There's so many things that can happen. I have found that it is much more valuable from the start to have those critical, we'll call them those critical things that are part of an MVP because that provides you your second round of stuff is you get the high risk stuff. So you right away just go after those things and figure out, are those risks real? Are they imaginary? What are they? And then you go right into this is what we have to have. These are the features that have got to, got to, got to be there because that's going to protect your customer and the project so that if things do go squirrely, if they do start to, you have all kinds of issues and overruns. You do have like a fallback basically. So you can get something out the door that still gets them a win and allows you to, you know, push off some of those bigger issues. Thoughts from you? So I'm going to go with the break it down and add buffers. So because I like the test driven approach, you can almost apply that to your estimation. If you can break down requirements in such a way that you understand what needs to be done in such a way where if A then B, then it's a small enough task that you should fairly easily be able to say, okay, that's been our task. Then tack on 20 to 30% on top of that for any unknowns. If you can't quite get it to that, again, get it to the P to a point where you have at least broken it down to where you have specific enough requirements to where you know what the task needs to be to get it done. If you have those tasks where, hey, we want to integrate with accountants or we want to integrate with payers, that's not small. That is too open-ended, too vague. And at that point, you can't even track it. You can't even really estimate. So if you can break it down to small enough tasks, you're going to be more accurate with your estimations. And again, always tack on that additional 20 to 30% from the unknown. Well, we have once again run into time constraints and such because these are really good topics that they come up with. Who knows? We may have to come back around to this at some point just because, or we'll just keep doing these kinds of things and just retread some of our past episodes and continually have new content and such. However, I would love for you to send us an email at info at developernerd.com and let us know what you think. What do you like? What don't you like? What would you like us to address? How would you like us to change stuff around? How would you like us to add, delete all of that kind of stuff? All of the crud options that are out there for developer itself. You can also leave us feedback wherever you listen to podcasts. You can give us any kind of rating, one to five, like it, love it, whatever their different rating scales are. More importantly, then your rating is your actual word feedback, like what did you like? What don't you like? What can we do better? What can we do to help you become a better developer? Check us out at developernerd.com. We've got feedback forms and everything there. We've got tons and tons of comments. That is probably going to be going through a revamp. I've promised that for a while, but I'm actually finally getting to that point. It's like working my way down to that on my to-do list. Also, you can check us out on Facebook. You can check it. Follow us on x at developer dot com. And you can find us there. Also, you can find us here wherever you're watching us or listening to us right now, come back because subscribe, do all that good stuff because we're not done yet. We are marching on towards 1000 episodes. We are like 900s in the rear view mirror and we're moving on talking to somebody today. And he was like, wow, I remember when you first started it. It was like weird that it's already there. And I was like, I actually remember when I first started it too, because I was there, but also, and I think he may have been the only person that's like been subscribed all the way through. That being said, all of you, whether you started at episode one or episode 901, appreciate all that you do. Appreciate you coming out and spending some time with us. 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, the Develop-a-Noor 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.