Sent by Jonathan Stark on July 28th, 2019
Fellow list member, Jeff Angelini sent in the following question about how price determines cost (shared with permission):
Hi Jonathan, I don’t really get this. Isn’t our cost (our time?) determined by what needs to be done to accomplish the client’s desired outcome? How can we say, “well, it’s worth $X to them, so I’m only going to do Y”, if Y won’t accomplish their objective? Shouldn’t we always be minimizing Y anyway (as long as it accomplishes their objective)? I imagine others are having similar questions, so no need to respond back to me directly if a mass email is coming on it. I look forward to hearing what other thoughts you have on this. Thanks so much for all your emails! They’re always enlightening. Jeff
As Jeff predicted, lots of people are confused by this concept of setting a cost after setting a price. And yes, as Jeff points out, virtually all of our cost comes from the time it takes us to deliver the outcome. The variable is “what needs to be done,” as Jeff puts it in his message. We get to pick what needs to be done (i.e., the scope, and by extension, our time commitment) after we decide on a price.
This is a hard concept to explain without specifics, so I’m going to get kinda technical here. Apologies to the non-devs in the audience.
Let’s say you have been developing web sites for a long time, and for the past few years have specialized in mobile iOS and Android apps. Some of your apps are pure web apps that run only in the mobile browser, some are pure native apps that are written in Swift or Kotlin and distributed through platform app stores, and some hybrid apps using various different approaches like PhoneGap, Ionic, and React Native.
A client comes to you looking for a React Native version of their browser-based web app. Their exact request is that they want you to “rebuild our web app in React Native”. Their budget is $25,000 and they’re under some non-trivial time pressure.
You know from a cursory review of their web app that it is pretty complex. For you to rebuild it from scratch would probably end up costing them double or triple what they are hoping to spend.
You also noticed while reviewing the web app, that it is responsive and it works quite well on mobile devices. Rewriting an app like this that was already designed, built, tested, and pushed live seems like a lot of “wheel reinvention”, so you ask, “Why do you want to rewrite this in React Native?”
The client replies, “We need to demonstrate the app store discovery and installation process for a couple of big potential partners. They just don’t believe in the web app concept. We heard that React Native would get us both iOS and Android with a single code base, so we figured that would save us some money.”
So you ask, “Are they happy with the current user experience of the web app?” and the client tells you, “Yes, they love it. And they understand that it’s an MVP. They just need to see it in the app store in order to sell the experience to their investors.”
You wrap up with, “So, would you consider it a home run if we could just put the existing web app in the app stores?” and the client says, “That would be amazing!”
Based on this information, you write a proposal for them with three options:
FYI - In case you don’t have a calculator in front of you, options 1 and 2 are significantly more profitable (and less risky) than option 3.
Each of these options result in the same desired outcome: a version of the client’s web app in the iOS and Android app stores so their potential partners have something to sell to investors.
Would the native version be nicer than wrapping the web app in a WebView? Of course. But the client doesn’t need nicer right now! They need something in the app stores, and fast.
If you are laser focused on discovering the client’s desired outcome, you can get pretty creative when it comes proposing engagements that consist of very different levels of effort on your part (i.e., different costs). Assuming you’re not charging for your time, this can result in very profitable engagements.