No Compromises

So someone has asked you to build an app, or add a feature to an app. How do you decide exactly what to build and how much to charge? We share our approach to these important questions in this episode.

Show Notes

Check out our new website: MasteringLaravel.io

Creators & Guests

Host
Aaron Saray
Host
Joel Clermont

What is No Compromises?

Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.

Joel Clermont (00:00):
Welcome to No Compromises, a peek into the mind of two old web devs who have seen some things. This is Joel.

Aaron Saray (00:08):
And this is Aaron.

Joel Clermont (00:15):
A couple episodes back we tried a different format, maybe a less 100% developer-focused, but kind of how we do work, how we work with clients, how we work on projects because there is some overlap. Last time, we talked about qualifying and today I thought we could talk a little bit more about scope, budget, things around that. Like, still before the work begins but after you've figured out you want to work with this client. Let's start with scope. This is a client we've qualified, we kind of feel like there's a good chance we'll work well together, they pass that first hurdle so to speak. But when you're talking to a client in this context, they have a project in mind. So for sake of our discussion today, let's assume this isn't a totally green field, brand-new project that's being created out of thin air, although the principles would apply. But let's say they have an established application and they will-

Aaron Saray (01:21):
A web application?

Joel Clermont (01:22):
A web application, yeah. Just assume if I say app, I'm not talking about an iOS app, a web app. That they want they want to add a feature to it or maybe a couple features. Let's take as a specific example, a client that runs trivia events, right? They typically do this in-person and now they want to be able to run these events online or remotely, so they come to you with this feature request and the thing they're asking for is a mobile app. We took that feature request but instead of just drilling right into the technical details, like, "Oh, do you want this to run on iOS?" Like all those specific things. Where we like to start is to kind of back up and figure out what's driving this feature request. What is the business problem that's being solved? Because a business isn't going to pay you money to develop a feature unless it's actually doing something productive for them.

Aaron Saray (02:22):
Yeah, I think that's important that we kind of stop right there and talk about the fact that it does take a little bit of an exercising of a particular muscle to hear the customer ask for something and then to just not start building that thing too. It's not that we don't respect that they've done their due diligence, it's just that their due diligence revolves usually around their business needs and then an idea that they have heard of that could probably solve it. Whereas, as technical people we know probably more solutions than they do so when we understand and take that moment, we're not saying that no, they haven't thought it out or they don't know what they're doing. We just want to make sure that we've helped them or kind of like... It sounds bad, I don't want to say we blessed their decision to get that solution. But that we agree that that is the best thing so that we can own it too and we're building it. Because there's something worse than trying to build something when you're like, "This is not the right thing to do."

Joel Clermont (03:25):
Yeah, that's a good clarification. We're not second guessing or saying we know better, but just understanding how that decision was arrived at is beneficial. Even if it ends up being the decision, even if we don't change the direction they want to go.

Aaron Saray (03:41):
This client says, "I want this this mobile app to do X, Y and Z." And then we kind of think about those X, Y and Z that they're trying to accomplish, is this the best way to accomplish that or are there other ways? How does that fit into some sort of scope? Also we'll talk about it a little bit, but also their budget constraints too. And is the mobile app always the best solution in this particular concrete example? Is the solution they want something that they can afford now? Something that they need now or are there intermediate steps? Because one of the things we want to talk about too is sometimes those solutions they come up with, they don't understand how much effort and how long it's going to take to implement that. For a business, maybe they need the solution that this provides in three months and it's going to take us nine months to build it. They could go out of business maybe, it depends on like what the need is. So it's in our due diligence of working with this client, we're going to say, "What are some of the reasons why you need this?" so that we can make sure that we give them all the different options.

Joel Clermont (04:49):
Yeah. This particular example was somewhat time sensitive so that was a huge driving factor in us exploring possible solutions, was to find one that not only met the business goals but in time for the business need. I've had clients comment almost a little surprised that we take an interest in the business side of things because this isn't very typical. But where I really feel that it benefits not only us but the customer, is when we get to the point of submitting a proposal. Now it's not all nerdy technical details but we tie those things back to those business goals. Because generally a person we're giving the proposal to, there's other people that are going to look at it and maybe even other people that are involved in the decision. So having them see this particular way of doing this project connects with these two business goals is a lot more concrete than just a bullet points of a tech stack and what version of this or even a list of features. It goes beyond that and it really shows that we're kind of invested in the business succeeding, not just this project being built and being technically good but also actually serving a purpose.

Aaron Saray (06:09):
I think it's important to bring up again too, something I've learned earlier in my career with this whole process is, it can be enticing to learn more about the business and go too far down that route-

Joel Clermont (06:22):
Oh, sure. Yeah.

Aaron Saray (06:23):
... or to develop opinions based off your small bit of context. When you hear from a customer that they've made XYZ decisions and maybe your gut reaction is, "Oh, that doesn't seem right." Or, "What's wrong with them?" You have to learn to swallow that and just list that as, "Maybe there's something here I need to understand more." Or, "Maybe this is a common mistake that maybe this company does over and over. I'm not going to change that, but I can build in functionality to protect against that for the next time." Again, when we talk about understanding the business it's not about going down that rabbit hole and trying to understand too much. But it's understanding enough to make sure that you understand why they asked for this thing, not dissecting their entire business for them.

Joel Clermont (07:08):
Yeah, you're so reasonable Aaron. Like, a lot.

Aaron Saray (07:12):
I've made a lot of mistakes in the past. Sometimes you learn by making mistakes and I've come across arrogant too and learned from that. And that's why I wanted to share that side of it, so.

Joel Clermont (07:26):
Good to keep in mind. Let's shift a little bit to budget, because scope and budget go in hand. But obviously we're not going to talk specific prices here, that's not the interesting bit. But I thought it'd be interesting to talk about just how we calculate a budget, because I've seen this done a few different ways. I've done it over my career a few different ways. But really our approach is to give a flat fixed project price. I can already feel some shutters going through developers out there because software estimation is a very tricky thing. Like, "Well, how could I possibly give a fixed price when maybe it'll take 10 times longer than I thought?" Well okay, that is a valid concern. But let's talk about why we do it. And this is something that I had to learn myself and it took a few tries of doing this to really get good at it. But think of it from the customer's perspective. They don't want to also write you a blank check, right?
So there's risk in how long is this going to take in the example where you're just billing hourly. You're essentially putting all of the risk onto the client, right? They're going to hope that your estimate was accurate. You might think, "Well, if you're doing fixed bid, is that then shifting all of the risk back to the developer?" and I don't think it has to. When we write these proposals, the reason we drill into the scope and that's why we started with that as the discussion, is because it's focused on a business outcome and the proposal lists the steps we're going to take to reach that business outcome. All the minutia of what color should this button be or how does this exact feature work? Those can be settled by answering one question. Well, does it contribute to the business outcome? Or is it just, you know, a nice to have thing? With a fixed bid and a well-defined scope that's outcome-oriented you have a lever to push back. If things are taking way longer than they should it's likely because the scope is trying to increase or things are being thrown in that don't have to do with the actual business outcome you're trying to reach.

Aaron Saray (09:50):
I think one of the reasons why some customers might want hourly billing, is they feel like it's a way to kind of control their budget. You say it puts a risk on them but they may say that, "We might have flexible budgets and so this month, you can only work 20 hours, so I know for a maximum this month I'm only going to spend an X amount of dollars." I think they also look at it as a way to reduce their risk. Meaning that if they've worked with you for 20 hours and things aren't working as they expect, they just say, "Well then let's wrap it up, we've only wasted 20 hours."

Joel Clermont (10:27):
Sure, yeah.

Aaron Saray (10:27):
Versus giving someone a check and then realizing halfway through it's not going to work out. So there's a number of different ways to combat stuff like that. But I wanted to kind of still continue to tie this back to scope. A lot of the idea of a flat rate too has to do with understanding that their rate can be flat per scope item. So you can kind of start to look at these things and start to break them down into phases and things like that as well. Because on the flip side, with a flat rate then people wonder how long is this going to take and can you give that answer and stuff like that. So customers have their own needs, that's why we come back to the scope and understanding the business because there's been many times when we've changed scope because we understood that one of their needs had to do with a date. In order to hit a deliverable of that date, we had to change the output that we gave them. There was no way we could do all the things that they wanted in that timeframe, we explained to them and then we helped them understand what we could do and then figured out what was the most important business goal to achieve by that date.

Joel Clermont (11:36):
Yeah. One thing I thought of as you were saying that is it kind of shifts the dynamic to be more of a partnership too. Because you and the client are invested in a successful outcome and you're not quibbling over, "Well, why did you spend 30 hours writing unit tests?" You know what I mean?

Aaron Saray (11:54):
Right.

Joel Clermont (11:54):
If you were going to bill by the hour and account for every minute you spent, it frees us up to do work in a professional manner as we see fit, but it also locks the client in to know like, "Well, it's going to cost this much, so let�s just to give some round numbers." If this feature is going to generate $200,000 in revenue this year, yeah, I'll happily pay some developers $50,000 as a flat rate to do that. It makes perfect sense." So everything is aligned that way but it makes it less adversarial because you're kind of both trying to reach the same goal. Whereas if you're billing hourly, like, "Well, do it faster." Like, "Okay." "But don't cut corners." You know what I mean?

Aaron Saray (12:34):
Right.

Joel Clermont (12:34):
It's kind of like this weird spot to be in.

Aaron Saray (12:37):
But what would you say to people though that want to give that flat rate. They think they've done the scoping and then they found out that they just missed something and there's no way this flat rate covers their time?

Joel Clermont (12:48):
Yeah, sometimes things are missed, mistakes are made. And really, in the development world sometimes things just take way longer than you expect and to nobody's fault. How I personally handle that is I kind of try to gauge, "Is this something I missed? In the grand scope of the project, is this a small percentage?" Sometimes I'll just do it. But other times when it's not something I feel like I can absorb or if I feel like it's something that was only revealed later, you just have to have an honest conversation and go to the client and explain what the situation is and present some options. You're not just saying, "No, I'm not doing this," or, "Give me more money," or things like that. But, "Well, here's the situation, here's some ways we could deal with it. Maybe we could deliver that specific thing later in a separate project or we could drop this other thing over here that wasn't as important in order to accommodate this. Or maybe increasing budget and the timeline of the project is a viable option." But just to have that honest conversation and talk it through, again, in the mindset of a partnership.

Aaron Saray (13:57):
I think to wrap it up for the second kind of step along the process is, first we kind of qualified the project and customer. Do we want to work with them? Are they going to fit our model? Second is, we go and dig in and understand the scope, the business needs. What business problems this is solving, so we can kind of give some sort of idea of flat rate of something that we can apply to this and break it up and understand what the deliverables really are, and if what they are asking for is the right deliverable. And then how much that would kind of cost. Then I think what we've kind of said in the meantime is, also part of that qualification process was determining if this is a customer that would be open to having a conversation should something go wrong. You can kind of feel that out during that first step too, is are they just very not understanding? Then there's a tremendous amount of risk for many reasons and maybe they're not a good fit.
There's a lot of things that we don't necessarily treat equally with how we consider or think about them. For example, people are amazed by the fact that every snowflake seems unique and different, but nobody really cares that every potato is unique, you know? So what's the difference here? Why do we make decisions on some things are amazing and beautiful, and then other things are, "Well, that's just a potato."

Joel Clermont (15:32):
First of all, I thought the thing about snowflakes was a myth.

Aaron Saray (15:35):
Yeah. Well, that's why I said, "They seem to think they're all different."

Joel Clermont (15:38):
Okay. Well, I don't know if anybody has ever done one of those assignments in kindergarten where you fold the paper and you cut it and it produced [inaudible 00:15:50] unfold it and then it's a potato, Like, you've never...

Aaron Saray (15:52):
Oh, yes.

Joel Clermont (15:52):
It just doesn't have the same beauty in the eye, I think. But, yes, that's a good point.

Aaron Saray (16:03):
Yeah. And I guess you really can't send a snowflake through the mail. But they have that service where you can send a potato through the mail with someone's face on it or something. You know the post office was just super angry when that trend kicked off. They're like, "Don't we have enough to deal with and now there's potatoes coming through?" That reminds me though, I was on Amazon and I found there's a lot of... If you're on Amazon, there's a lot of things you can find randomly. I'm not sure if I ever shared this with you, Joel, but my brother had bought a house and I decided that I wanted to send him a housewarming gift. There was a couple different options. There was like a cardboard cutout and I thought, "That'd be cool." Get a cardboard cutout of a person just standing, have my sister just sneaking out of his house in the middle of the night and then put it up on his little house or something. When you wake up in the morning, you're walking and then all of a sudden there's a random dude?

Joel Clermont (16:56):
Yeah. I bet it'd get the blood pumping in the morning.

Aaron Saray (16:59):
But instead I decided that I would send him 1,500 of something. It's 1,500 of these things, they came in a bag and I did not understand that this is a thing you could send to people.

Joel Clermont (17:12):
I'm scared.

Aaron Saray (17:12):
But I sent him 1,500 live ladybugs.

Joel Clermont (17:16):
What?

Aaron Saray (17:17):
Yeah. And he was like, "What?" Basically, they come in a bag and they're kind of sleeping, I guess. He opens up this bag and finds a mass of lady bugs.

Joel Clermont (17:28):
Oh boy.

Aaron Saray (17:29):
He's like, "What's wrong with you?" But everything ended up turning out okay because my mom has a garden and a farm, so he just took the bag over to her. He thought that he was going to like, "Oh, mom bugs." But she was like, "Oh, this is awesome." She went and put them all in her garden which I guess is helpful for some reason. I don't know.

Joel Clermont (17:49):
Yeah, they eat little bugs. They eat aphids or something that are bad for your plants.

Aaron Saray (17:54):
But, yeah, I guess I didn't understand that you could get those.

Joel Clermont (17:59):
Well, you should have got him a bag of aphids to go with it, then it would've been like a whole ecosystem.

Aaron Saray (18:08):
Hey, if you like our podcast and you want more of this type of content.

Joel Clermont (18:12):
Then go to our website masteringlaravel.io.